Manter clusters do Kubernetes

Compartilhado Standard

Com o isolamento físico do Google Distributed Cloud (GDC), é possível gerenciar seus clusters do Kubernetes após a criação usando o GKE no GDC. Com esse serviço, você se adapta aos requisitos de carga de trabalho de contêiner em evolução e mantém os nós de cluster atuais com os seguintes fluxos de trabalho:

Anexar e separar clusters compartilhados de projetos: anexe e separe seu cluster compartilhado de vários projetos após a criação do cluster para mudar o escopo das cargas de trabalho do cluster compartilhado.
Ver clusters na sua organização: liste os clusters na sua organização para acompanhar o que está disponível para suas cargas de trabalho de contêiner.
Listar versões do Kubernetes: confira a versão do Kubernetes do seu cluster para conhecer os recursos dele correspondentes aos lançamentos mais recentes do Kubernetes.
Ver propriedades atualizáveis do cluster: confira as propriedades disponíveis para mudança na definição do recurso personalizado Cluster.

Este documento é destinado a administradores de TI no grupo de administradores de plataforma que gerenciam cargas de trabalho de contêineres hospedadas em clusters que abrangem vários projetos, e desenvolvedores no grupo de operadores de aplicativos que são responsáveis por criar cargas de trabalho de aplicativos em um único projeto. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Antes de começar

Para concluir as tarefas neste documento, você precisa dos seguintes recursos e papéis:

Para visualizar e gerenciar pools de nós em um cluster compartilhado do Kubernetes, peça ao administrador do IAM da organização para conceder a você os seguintes papéis:
- Administrador do cluster de usuários (user-cluster-admin)
- Leitor de nós do cluster de usuário (user-cluster-node-viewer)
Essas funções não estão vinculadas a um namespace de projeto.
Para ver e gerenciar pools de nós em um cluster padrão do Kubernetes, peça ao administrador do IAM da organização para conceder a você o papel de Administrador de cluster padrão (standard-cluster-admin). Essa função está vinculada ao namespace do projeto.
Para executar comandos em um cluster do Kubernetes, verifique se você tem os seguintes recursos:
- Localize o nome do cluster do Kubernetes ou pergunte a um membro do grupo de administradores da plataforma.
- Faça login e gere o arquivo kubeconfig para o cluster do Kubernetes se você não tiver um.
- Use o caminho kubeconfig do cluster do Kubernetes para substituir KUBERNETES_CLUSTER_KUBECONFIG nestas instruções.
Para executar comandos no servidor de API zonal, gere o arquivo kubeconfig do servidor de API zonal que hospeda seu cluster. Para mais informações, consulte Fazer login. Defina a variável de ambiente MANAGEMENT_API_SERVER como o caminho do kubeconfig.

Mover clusters na hierarquia do projeto

Os projetos oferecem um agrupamento lógico de instâncias de serviço. É possível adicionar e remover clusters compartilhados do Kubernetes da hierarquia de projetos do GDC para agrupar seus serviços adequadamente. Não é possível mover clusters padrão na hierarquia de projetos porque eles são limitados a um único projeto.

Anexar projeto a um cluster compartilhado

Ao criar um cluster compartilhado no console do GDC, é necessário anexar pelo menos um projeto antes de implantar cargas de trabalho de contêiner nele. Se você precisar adicionar mais projetos a um cluster, siga estas etapas:

Console

No menu de navegação, selecione Kubernetes Engine > Clusters.
Na lista de clusters, clique no nome do cluster para abrir a página Detalhes do cluster.
Selecione Anexar projeto.
Na lista de projetos disponíveis, clique no nome do projeto para anexar ao cluster.
Clique em Salvar.

API

Crie um novo recurso personalizado ProjectBinding para seu cluster:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: resourcemanager.gdc.goog/v1
kind: ProjectBinding
metadata:
  name: CLUSTER_NAME-PROJECT_NAME
  namespace: platform
  labels:
    resourcemanager.gdc.goog/projectbinding-for-user-project: "true"
spec:
  clusterRef:
   name: CLUSTER_NAME
  selector:
    nameSelector:
      matchNames:
      - PROJECT_NAME
EOF

Substitua:

MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
CLUSTER_NAME: o nome do cluster.
PROJECT_NAME: o nome do projeto a que o cluster será vinculado. Cada recurso ProjectBinding só pode ser mapeado para um cluster. Se um projeto precisar de acesso a vários clusters, um ProjectBinding exclusivo precisará ser criado para cada um deles.

Terraform

Em um arquivo de configuração do Terraform, insira o seguinte snippet de código para criar o recurso personalizado ProjectBinding:
```
provider "kubernetes" {
  config_path = "MANAGEMENT_API_SERVER"
}

resource "kubernetes_manifest" "PROJECT_BINDING_RESOURCE_NAME" {
  manifest = {
    "apiVersion" = "resourcemanager.gdc.goog/v1"
    "kind" = "ProjectBinding"
    "metadata" = {
      "name" = "CLUSTER_NAME-PROJECT_NAME"
      "namespace" = "platform"
      "labels" = {
        "resourcemanager.gdc.goog/projectbinding-for-user-project" = "true"
      }
    }
    "spec" = {
      "clusterRef" = {
        "name" = "CLUSTER_NAME"
      }
      "selector" = {
        "nameSelector" = {
          "matchNames" = [
            "PROJECT_NAME",
          ]
        }
      }
    }
  }
}
```
Substitua:
- MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
- PROJECT_BINDING_RESOURCE_NAME: o nome do recurso do Terraform da vinculação do projeto, como CLUSTER_NAME-PROJECT_NAME-binding. Esse nome é usado pelo Terraform para identificar a vinculação do projeto e não é usado pelo GDC.
- CLUSTER_NAME: o nome do cluster. Cada recurso ProjectBinding só pode ser mapeado para um cluster. Se um projeto precisar de acesso a vários clusters, um ProjectBinding exclusivo precisará ser criado para cada cluster.
- PROJECT_NAME: o nome do projeto a ser vinculado. Cada recurso ProjectBinding só pode ser mapeado para um cluster. Se um projeto precisar de acesso a vários clusters, um ProjectBinding exclusivo precisará ser criado para cada um deles.
Aplique a nova vinculação de projeto:
```
terraform apply
```

Desvincular um projeto de um cluster compartilhado

Desvincular um projeto de um cluster compartilhado pode causar mudanças significativas, como a exclusão de cargas de trabalho em execução no cluster. Entenda as consequências antes de desanexar um projeto de um cluster compartilhado.

Para separar um projeto de um cluster compartilhado, siga estas etapas:

Console

No menu de navegação, selecione Kubernetes Engine > Clusters.
Clique no cluster na lista para abrir a página Detalhes do cluster.
Clique em Desanexar para o projeto que você quer desanexar do cluster.

API

Exclua o recurso ProjectBinding que vincula o projeto e o cluster:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER delete projectbinding \
    CLUSTER_NAME-PROJECT_NAME -n platform
```
Substitua:
- MANAGEMENT_API_SERVER: o caminho kubeconfig do servidor da API zonal.
- CLUSTER_NAME: o nome do cluster.
- PROJECT_NAME: o nome do projeto a ser desvinculado do cluster.

Terraform

Exclua o recurso de vinculação do projeto:
```
terraform destroy -target kubernetes_manifest.PROJECT_BINDING_RESOURCE_NAME
```
Substitua PROJECT_BINDING_RESOURCE_NAME pelo nome do recurso do Terraform da vinculação do projeto a ser excluída, como CLUSTER_NAME-PROJECT_NAME-binding. Esse nome é usado pelo Terraform para identificar a vinculação do projeto e não é usado pelo GDC.

Ver todos os clusters em uma organização

É possível conferir todos os clusters do Kubernetes disponíveis em uma organização, incluindo status, versões do Kubernetes e outros detalhes.

Como os clusters do Kubernetes são um recurso zonal, só é possível listar clusters por zona.

Console

No menu de navegação, selecione Kubernetes Engine > Clusters.

Todos os clusters compartilhados disponíveis na organização com os respectivos status e outras informações são mostrados:

gdcloud

Liste os clusters compartilhados disponíveis da zona em uma organização:

gdcloud clusters list

O resultado será o seguinte:

CLUSTERREF.NAME   READINESS.STATE   TYPE   CURRENTVERSION.USERCLUSTERVERSION     CURRENTVERSION.SUPPORT.STATUS
user-vm-1         Ready             user   1.15.0-gdch.394225-1.28.15-gke.1200   In Support
user-vm-2         Ready             user   1.15.0-gdch.394225-1.29.12-gke.800    In Support

API

Liste os clusters do Kubernetes disponíveis de uma organização em uma zona:
```
kubectl get clusters.cluster.gdc.goog -n KUBERNETES_CLUSTER_NAMESPACE \
    --kubeconfig MANAGEMENT_API_SERVER
```
Substitua:
- MANAGEMENT_API_SERVER: o caminho do kubeconfig do servidor de API zonal.
- KUBERNETES_CLUSTER_NAMESPACE: o namespace do cluster. Para clusters compartilhados, use o namespace platform. Para clusters padrão, use o namespace do projeto do cluster.
O resultado será o seguinte:
```
NAME        STATE     K8S VERSION
user-vm-1   Running   1.25.10-gke.2100
user-test   Running   1.26.5-gke.2100
```

Listar as versões disponíveis do Kubernetes para um cluster

É possível listar as versões disponíveis do Kubernetes na sua zona do GDC para verificar os recursos do Kubernetes que podem ser acessados no cluster.

Liste as versões disponíveis do Kubernetes na sua zona:

kubectl get userclustermetadata.upgrade.private.gdc.goog \
    -o=custom-columns=K8S-VERSION:.spec.kubernetesVersion \
    --kubeconfig MANAGEMENT_API_SERVER

Substitua MANAGEMENT_API_SERVER pelo arquivo kubeconfig do servidor da API zonal do cluster.

A saída será assim:

K8S-VERSION
1.25.10-gke.2100
1.26.5-gke.2100
1.27.4-gke.500

Ver propriedades atualizáveis

Para cada cluster do Kubernetes, um conjunto de propriedades está disponível para mudança após a criação. Só é possível mudar as propriedades mutáveis que estão no spec do recurso personalizado Cluster. Nem todas as propriedades em spec podem ser atualizadas depois que o cluster é provisionado. Para conferir essas propriedades atualizáveis, siga estas etapas:

Console

No menu de navegação, selecione Kubernetes Engine > Clusters.
Na lista de clusters do Kubernetes, clique no nome de um cluster para conferir as propriedades dele.
As propriedades editáveis têm um ícone Editar.

API

Confira a lista de propriedades da especificação Cluster e os valores válidos correspondentes a cada propriedade:

kubectl explain clusters.cluster.gdc.goog.spec \
    --kubeconfig MANAGEMENT_API_SERVER

Substitua MANAGEMENT_API_SERVER pelo caminho do kubeconfig do servidor de API zonal.

O resultado será o seguinte:

KIND:     Cluster
VERSION:  cluster.gdc.goog/v1

RESOURCE: spec <Object>

DESCRIPTION:
    <empty>

FIELDS:
  clusterNetwork    <Object>
    The cluster network configuration. If unset, the default configurations
    with pod and service CIDR sizes are used. Optional. Mutable.

  initialVersion    <Object>
    The GDC air-gapped version information of the user cluster during cluster creation.
    Optional. Default to use the latest applicable version. Immutable.

  loadBalancer  <Object>
    The load balancer configuration. If unset, the default configuration with
    the ingress service IP address size is used. Optional. Mutable.

  nodePools <[]Object>
    The list of node pools for the cluster worker nodes. Optional. Mutable.

  releaseChannel    <Object>
    The release channel a cluster is subscribed to. When a cluster is
    subscribed to a release channel, GDC maintains the cluster versions for
    users. Optional. Mutable.

Atualize essas configurações usando o console do GDC ou a CLI kubectl. Por exemplo, é possível redimensionar um pool de nós.

Manter clusters do Kubernetes Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Antes de começar

Mover clusters na hierarquia do projeto

Anexar projeto a um cluster compartilhado

Console

API

Terraform

Desvincular um projeto de um cluster compartilhado

Console

API

Terraform

Ver todos os clusters em uma organização

Console

gdcloud

API

Listar as versões disponíveis do Kubernetes para um cluster

Ver propriedades atualizáveis

Console

API

A seguir

Manter clusters do Kubernetes