Esta página foi traduzida pela API Cloud Translation.

Atualize clusters

Depois de criar um cluster, pode alterar alguns aspetos da configuração do cluster. Por exemplo, pode:

Adicione, remova ou substitua nós.
Adicione ou remova anotações do cluster.
Modifique os valores dos campos mutáveis nos recursos do cluster e do node pool.
Modificar outros recursos personalizados.

Pode usar o bmctl ou a Google Cloud CLI para fazer atualizações a um cluster. Se criou um cluster de administrador ou de utilizador com o Terraform, pode usar o Terraform para atualizar o cluster. Tenha em conta o seguinte:

Muitos aspetos da configuração do cluster são imutáveis e não podem ser atualizados depois de criar o cluster. Para ver uma lista abrangente de campos mutáveis e imutáveis, consulte a referência de campos de configuração de clusters. A referência do campo é uma tabela ordenável. Clique nos cabeçalhos das colunas para alterar a ordem de ordenação. Clique no nome de um campo para ver a respetiva descrição.
A CLI gcloud e o Terraform só suportam a atualização de clusters de administrador e de utilizador. Tem de usar bmctl para atualizar outros tipos de clusters.
A CLI gcloud e o Terraform só suportam alterações aos recursos do cluster e do conjunto de nós. Tem de usar kubectl ou bmctl para atualizar outros recursos personalizados que afetam o cluster.

A modificação do espaço de nomes de um cluster existente no ficheiro de configuração do cluster é not a supported operation e pode levar à instabilidade do cluster e a potenciais falhas. Para evitar estes problemas, não tente modificar o espaço de nomes do cluster após a respetiva criação.

Esta página destina-se a administradores, arquitetos e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e exemplos de tarefas que referimos no conteúdo, consulte o artigo Funções de utilizador e tarefas comuns do GKE Enterprise. Google Cloud

Como atualizar clusters

Geralmente, segue a seguinte sequência de ações para atualizar um cluster:

`bmctl`

Altere os valores dos campos aplicáveis no ficheiro de configuração do cluster, que, por predefinição, se encontra aqui:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Atualize o cluster executando o comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
Substitua o seguinte:
- CLUSTER_NAME: o nome do cluster que quer atualizar.
- KUBECONFIG: para clusters de administrador, híbridos ou autónomos, introduza o caminho para o ficheiro kubeconfig do cluster. Para um cluster de utilizadores, introduza o caminho para o ficheiro kubeconfig do cluster admin.

Não use bmctl update e kubectl apply -f de forma intercambiável quando editar o ficheiro de configuração do cluster. Quando estes comandos são usados de forma intercambiável, o conteúdo preenchido pelo cabeçalho da especificação do cluster pode ser removido involuntariamente. Por exemplo, pode usar bmctl update para atualizar o ficheiro de configuração do cluster para configurar uma réplica do registo. O cluster é spec.nodeConfig.registryMirrorspreenchido após a conciliação.

Se tentar fazer alterações ao cluster usando a configuração do cluster com o comando kubectl apply -f, o spec.nodeConfig.registryMirrors preenchido pelo reconciliador no cluster é removido. Este comportamento ocorre porque a configuração não existe na especificação de configuração do cluster, mas existe no cluster.

CLI gcloud

Especifique apenas os indicadores da configuração que quer modificar.
Execute o comando de atualização aplicável:
- Clusters de administrador: gcloud container bare-metal admin-clusters update
- Clusters de utilizadores: gcloud container bare-metal clusters update.
- Node pools num cluster de utilizador: gcloud container bare-metal node-pools update

Terraform

Altere os valores dos campos aplicáveis no ficheiro de configuração do Terraform que usou para criar o cluster ou o conjunto de nós. Consulte a documentação de referência do Terraform para ver descrições detalhadas dos campos:
Atualize a configuração executando o comando terraform apply.

As secções seguintes descrevem alguns exemplos comuns para atualizar um cluster existente.

Adicione ou remova nós num cluster

Um conjunto de nós é um grupo de nós num cluster que têm a mesma configuração. Tenha em atenção que um nó pertence sempre a um conjunto de nós. Para adicionar um novo nó a um cluster, tem de o adicionar a um conjunto de nós específico. A remoção de um nó de um conjunto de nós equivale à remoção do nó do cluster por completo.

Existem três tipos de node pools no Google Distributed Cloud: plano de controlo, equilibrador de carga e node pools de trabalho. As secções seguintes descrevem como adicionar ou remover nós de cada tipo de conjunto de nós.

`bmctl`

Adiciona ou remove um nó de um conjunto de nós adicionando ou removendo o endereço IP do nó numa secção específica do ficheiro de configuração do cluster. A lista seguinte mostra que secção editar para um determinado conjunto de nós:

Conjunto de nós de trabalho: adicione ou remova o endereço IP do nó na secção spec.nodes da especificação NodePool.
Pool de nós do plano de controlo: adicione ou remova o endereço IP do nó na secção spec.controlPlane.nodePoolSpec.nodes da especificação Cluster.
Pool de nós do balanceador de carga: adicione ou remova o endereço IP do nó na secção spec.loadBalancer.nodePoolSpec.nodes da especificação Cluster.

Exemplo: remover um nó de trabalho

Segue-se um ficheiro de configuração de cluster de exemplo que mostra as especificações de dois nós de trabalho:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: nodepool1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: 192.0.2.1
  - address: 192.0.2.2

Para remover um nó:

(Opcional) Se o nó que está a remover estiver a executar pods críticos, comece por colocar o nó no modo de manutenção.

Pode monitorizar o processo de esgotamento de nós para nós de trabalho vendo os campos status.nodesDrained e status.nodesDraining no recurso NodePool.
Edite o ficheiro de configuração do cluster para eliminar a entrada do endereço IP do nó.

Atualize o cluster:

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

CLI gcloud

Usa um comando update para adicionar ou remover nós. O comando update que usa e a flag na qual especifica o endereço IP dependem do tipo de conjunto de nós que quer atualizar:

Worker node pool: execute gcloud container bare-metal node-pools update e especifique o endereço IP no parâmetro --node-configs 'node-ip=IP_ADDRESS'.
Node pool do plano de controlo num cluster de administrador: execute o comando gcloud container bare-metal admin-clusters update e especifique o endereço IP no parâmetro --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nós do plano de controlo num cluster de utilizador: execute gcloud container bare-metal clusters update e especifique o endereço IP no parâmetro --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nós do equilibrador de carga: execute gcloud container bare-metal clusters update e especifique o endereço IP no parâmetro --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' ou
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

O parâmetro no qual especifica o endereço IP só aceita um node-ip. Inclui a flag para cada endereço IP no conjunto de nós.

Os comandos update substituem todos os endereços IP pelos endereços IP que especificar. Para adicionar um nó, inclua os endereços IP dos nós existentes e o endereço IP do novo nó no comando update. Da mesma forma, só inclui os endereços IP dos nós que quer manter para remover nós.

Exemplo: remover um nó de trabalho

Esta secção mostra como remover um nó de trabalho de um conjunto de nós através de dados de exemplo. Os passos seguintes também incluem comandos adicionais da gcloud CLI que podem ser úteis.

(Opcional) Se o nó que está a remover estiver a executar pods críticos, comece por colocar o nó no modo de manutenção.

Pode monitorizar o processo de esgotamento de nós para nós de trabalho vendo os campos status.nodesDrained e status.nodesDraining no recurso NodePool.

Execute o comando list para apresentar uma lista de todos os conjuntos de nós no cluster:

gcloud container bare-metal node-pools list \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1

O resultado é semelhante ao seguinte:

NAME         LOCATION     STATE
node-pool-1  us-central1  RUNNING
node-pool-2  asia-east1   RUNNING

Execute o comando describe para listar todos os endereços IP no conjunto de nós:
```
gcloud container bare-metal node-pools describe node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1
```
O exemplo de resultado seguinte está truncado para facilitar a leitura:
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.33
...
name: projects/example-project-12345/locations/us-central1/bareMetalClusters/abm-user-cluster1/bareMetalNodePools/node-pool-1
nodePoolConfig:
  nodeConfigs:
  - nodeIp: 192.0.2.1
  - nodeIp: 192.0.2.2
  operatingSystem: LINUX
state: RUNNING
...
```
Tenha em atenção o seguinte no exemplo de saída:
- O campo name contém o nome totalmente qualificado do conjunto de nós. Quando especificar o nome do conjunto de nós num comando, pode especificar o nome totalmente qualificado ou o nome do conjunto de nós, por exemplo, node-pool-1, juntamente com os flags --cluster, --project e --location.
- A secção nodeConfigs contém dois campos nodeIp com os endereços IP dos nós.
Execute o seguinte comando para remover o nó com o endereço IP 192.0.2.1:
```
gcloud container bare-metal node-pools update node-pool-1 \
    --cluster=abm-user-cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --node-configs='node-ip=192.0.2.2'
```
O comando update substitui todos os endereços IP pelos endereços IP que especificar. Uma vez que 192.0.2.1 não está incluído, o nó é removido.

O resultado do comando é semelhante ao seguinte:
```
Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9] to complete
```
No exemplo de saída, a string operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 é o OPERATION_ID da operação de longa duração. Pode saber o estado da operação executando o seguinte comando noutra janela do terminal:
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
Pode executar o comando com frequência para verificar o estado.

Se a remoção do nó falhar, pode forçar a respetiva remoção do cluster. Para ver detalhes, consulte o artigo Reponha um nó com falhas no Google Distributed Cloud.

Substitua os nós do plano de controlo de HA

`bmctl`

Pode usar bmctl para substituir nós do plano de controlo de alta disponibilidade (HA) em todos os tipos de clusters.

Substitui um nó num cluster seguindo estes passos:

Remova o endereço IP do nó do ficheiro de configuração do cluster.
Atualize o cluster.
Verifique o estado dos nós no cluster.
Adicione o endereço IP de um novo nó ao mesmo ficheiro de configuração do cluster.
Atualize o cluster.

Exemplo: substituir um nó do plano de controlo de HA

Segue-se um ficheiro de configuração de cluster de exemplo que mostra três nós do plano de controlo num cluster de utilizador:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.13

Para substituir o último nó apresentado na secção spec.controlPlane.nodePoolSpec.nodes, siga estes passos:

Remova o nó eliminando a respetiva entrada de endereço IP no ficheiro de configuração do cluster. Depois de fazer esta alteração, o ficheiro de configuração do cluster deve ter um aspeto semelhante ao seguinte:

---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12

Atualize o cluster executando o seguinte comando:
```
bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG
```
Faça as seguintes alterações:
- Substitua CLUSTER_NAME pelo nome do cluster que quer atualizar.
- Se o cluster for um cluster de gestão autónoma (como um cluster de administrador ou autónomo), substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster. Se o cluster for um cluster de utilizadores, como neste exemplo, substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster admin.
Depois de o comando bmctl update ser executado com êxito, demora algum tempo a concluir as tarefas machine-preflight e machine-init. Pode ver o estado dos nós e dos respetivos conjuntos de nós executando os comandos descritos na secção Verifique as suas atualizações deste documento. Depois de o conjunto de nós e os nós estarem no estado pronto, pode avançar para o passo seguinte.
Adicione um novo nó do plano de controlo ao conjunto de nós adicionando o endereço IP do novo nó do plano de controlo à secção spec.controlPlane.nodePoolSpec.nodes do ficheiro de configuração do cluster. Após fazer esta alteração, o ficheiro de configuração do cluster deve ter um aspeto semelhante ao seguinte:
```
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: user-cluster
namespace: cluster-user-cluster
spec:
  controlPlane:
  nodePoolSpec:
    nodes:
    - address: 192.0.2.11
    - address: 192.0.2.12
    - address: 192.0.2.14
```

Atualize o cluster executando o seguinte comando:

bmctl update cluster -c CLUSTER_NAME \
  --kubeconfig=KUBECONFIG

CLI gcloud

Pode usar a CLI gcloud para substituir os nós do plano de controlo de alta disponibilidade (HA) em clusters de administrador e de utilizador.

Substitui um nó num cluster seguindo estes passos:

Remova o endereço IP do nó executando o comando update aplicável:
- Cluster de utilizadores: gcloud container bare-metal clusters update
- Cluster de administrador: gcloud container bare-metal admin-clusters update
Verifique o estado da remoção do nó no cluster executando o comando gcloud container bare-metal operations describe OPERATION_ID.
Adicione o endereço IP do novo nó executando o comando update aplicável.

Exemplo: substituir um nó do plano de controlo de HA

Esta secção mostra como substituir um plano de controlo de um cluster usando dados de exemplo. Os passos seguintes também incluem comandos adicionais da gcloud CLI que podem ser úteis.

Execute o comando list para apresentar uma lista de todos os clusters de utilizadores num projeto:Google Cloud

gcloud container bare-metal clusters list \
    --project=example-project-12345 \
    --location=-

Quando define --location=-, significa que quer listar todos os clusters em todas as regiões. Se precisar de restringir a lista, defina --location para uma região específica.

O resultado é semelhante ao seguinte:

NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.33      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.33      abm-admin-cluster1   RUNNING

Execute o comando describe no cluster:
```
gcloud container bare-metal clusters describe abm-user-cluster1  \
    --project=example-project-12345 \
    --location=us-central1
```
O exemplo de resultado está truncado para facilitar a leitura:
```
...
controlPlane:
  controlPlaneNodePoolConfig:
    nodePoolConfig:
      nodeConfigs:
      - nodeIp: 192.0.2.11
      - nodeIp: 192.0.2.12
      - nodeIp: 192.0.2.13
      operatingSystem: LINUX
...
name: projects/example-project-1234567/locations/us-central1/bareMetalClusters/abm-user-cluster1a
...
```
Tenha em atenção o seguinte no exemplo de saída:
- O campo name contém o nome totalmente qualificado do cluster. Quando especificar o nome do cluster num comando, pode especificar o nome totalmente qualificado ou o nome do cluster, por exemplo, abm-user-cluster1a, juntamente com o --project e o --location flags.
- A secção nodeConfigs contém três campos nodeIp com os endereços IP dos nós do plano de controlo.

Remova o nó com o endereço IP 192.0.2.13:

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'

O resultado do comando é semelhante ao seguinte:

Waiting for operation [projects/example-project-12345/locations/us-central1/operations/operation-1956154681749-6078d9def4030-76686d6e-9fcb1d7] to complete

No exemplo de saída, a string operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 é o OPERATION_ID da operação de longa duração. Pode saber o estado da operação executando o seguinte comando noutra janela do terminal:

gcloud container bare-metal operations describe operation-1956154681749-6078d9def4030-76686d6e-9fcb1de7 \
    --project= example-project-12345 \
    --location=us-central1

Pode executar o comando com frequência para verificar o estado.

Adicione o novo nó com o endereço IP 192.0.2.14:

gcloud container bare-metal cluster update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --control-plane-node-configs 'node-ip=192.0.2.11'
    --control-plane-node-configs 'node-ip=192.0.2.12'
    --control-plane-node-configs 'node-ip=192.0.2.14'

Valide as suas atualizações

`kubectl`

Pode ver o estado dos nós e dos respetivos conjuntos de nós com o comando kubectl get.

Por exemplo, o seguinte comando mostra o estado dos conjuntos de nós no espaço de nomes do cluster cluster-my-cluster:

kubectl -n cluster-my-cluster get nodepools.baremetal.cluster.gke.io

O sistema devolve resultados semelhantes aos seguintes:

NAME                    READY   RECONCILING   STALLED   UNDERMAINTENANCE   UNKNOWN
cluster-my-cluster      3       0             0         0                  0
cluster-my-cluster-lb   2       0             0         0                  0
np1                     3       0             0         0                  0

Reconciling=1 significa que o passo de conciliação ainda está em curso. Deve aguardar até que o estado mude para Reconciling=0.

Também pode verificar o estado dos nós num cluster executando o seguinte comando:

kubectl get nodes --kubeconfig=KUBECONFIG

CLI gcloud

Conforme descrito anteriormente, depois de executar um comando update, pode verificar o estado da operação através do comando gcloud container bare-metal operations describe OPERATIONS_ID. O resultado do comando dá o estado dos nós, por exemplo:

  ...
  metrics:
  - intValue: '1'
    metric: NODES_RECONCILING
  - intValue: '2'
    metric: NODES_HEALTHY
  - intValue: '0'
    metric: NODES_FAILED
  - intValue: '0'
    metric: NODES_IN_MAINTENANCE
  - intValue: '3'
    metric: NODES_TOTAL
  stage: HEALTH_CHECK
...

Independentemente da ferramenta que usar para atualizar um node pool, pode obter o estado atual de um node pool executando o comando describe aplicável, conforme mostrado anteriormente.

Se precisar de mais informações sobre como diagnosticar os seus clusters, consulte o artigo Crie capturas de ecrã para diagnosticar clusters.

Pools de endereços do balanceador de carga

bmctl

A secção addressPools contém campos para especificar pools de balanceamento de carga para os balanceadores de carga agrupados do MetalLB e do Border Gateway Protocol (BGP). Pode adicionar mais conjuntos de endereços de balanceamento de carga em qualquer altura, mas não pode remover conjuntos de endereços existentes. A partir da versão 1.16.0 do Google Distributed Cloud, pode modificar os valores de addressPools.avoidBuggyIPs e addressPools.manualAssign em qualquer altura.

addressPools:
- name: pool1
  addresses:
  - 198.51.100.0-198.51.100.4
  - 198.51.100.240/28
- name: pool2
  addresses:
  - 198.51.100.224/28

CLI gcloud

Pode adicionar mais conjuntos de endereços de balanceamento de carga em qualquer altura para os balanceadores de carga agrupados, mas não pode remover conjuntos de endereços existentes. A flag que especifica em gcloud container bare-metal clusters update para adicionar um conjunto de endereços depende do tipo de balanceador de carga incluído:

MetalLB (camada 2): use a flag --metal-lb-address-pools.
Border Gateway Protocol (BGP): use a flag --bgp-address-pools.

O valor das flags tem o seguinte formato:

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

O valor tem segmentos que começam com as palavras-chave pool, avoid-buggy-ip, manual-assign e addresses. Separe cada segmento com uma vírgula.

pool: um nome à sua escolha para o grupo.
avoid-buggy-ips: se definir esta opção como True, o controlador de gestão de endereços IP (IPAM) não atribui endereços IP que terminem em .0 ou .255 aos serviços. Isto evita o problema de dispositivos de consumo com erros que interrompem por engano o tráfego enviado para esses endereços IP especiais. Se não for especificado, o fuso horário predefinido é False. A partir da versão 1.16.0 do Google Distributed Cloud, pode modificar este valor num conjunto de endereços existente.
manual-assign: se não quiser que o controlador IPAM atribua automaticamente endereços IP deste conjunto a serviços, defina esta opção como True. Em seguida, um programador pode criar um serviço do tipo LoadBalancer e especificar manualmente um dos endereços do conjunto. Se não for especificado, manual-assign é definido como False. A partir da versão 1.16.0 do Google Distributed Cloud, pode modificar este valor num conjunto de endereços existente.
Na lista de addresses: cada endereço tem de ser um intervalo no formato CIDR ou com hífen. Para especificar um único endereço IP num conjunto (como para o VIP de entrada), use /32 na notação CIDR (por exemplo, 192.0.2.1/32).

Tenha em atenção as seguintes regras de sintaxe:

Coloque todo o valor entre aspas simples.
Não são permitidos espaços em branco.
Separe cada intervalo de endereços IP com um ponto e vírgula.

Pode especificar mais do que uma instância da flag, conforme mostrado no exemplo seguinte:

--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=False,manual-assign=True,addresses=198.51.100.0/30;198.51.100.64-198.51.100.72'
--metal-lb-address-pools='pool=pool3,avoid-buggy-ips=True,manual-assign=True,addresses=203.0.113.0/28'

Para mais informações sobre os conjuntos de endereços do balanceador de carga, consulte loadBalancer.addressPools em Configure o balanceamento de carga agrupado.

Evite a eliminação inadvertida de clusters

`bmctl`

Se adicionar a anotação baremetal.cluster.gke.io/prevent-deletion: "true" ao ficheiro de configuração do cluster, não pode eliminar o cluster. Por exemplo, a execução de kubectl delete cluster ou bmctl reset cluster produz um erro.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: ci-10c3c6f4d9c698e
  namespace: cluster-ci-10c3c6f4d9c698e
  annotations:
    baremetal.cluster.gke.io/prevent-deletion: "true"
spec:
  clusterNetwork:

CLI gcloud

Se especificar a flag --add-annotations com o valor baremetal.cluster.gke.io/prevent-deletion="true", não pode eliminar o cluster. Por exemplo:

Adicione a anotação para evitar a eliminação acidental de clusters:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --add-annotations=baremetal.cluster.gke.io/prevent-deletion="true"

Tente eliminar o cluster de utilizadores:

gcloud container bare-metal clusters delete abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --force \
    --allow-missing

A resposta do comando é semelhante à seguinte:

ERROR: (gcloud.container.bare-metal.clusters.delete) INVALID_ARGUMENT:
invalid request: admission webhook "vcluster.kb.io" denied the request:
annotations[baremetal.cluster.gke.io/prevent-deletion]: Invalid value:
"true": Annotation "baremetal.cluster.gke.io/prevent-deletion" should be
removed in order to delete this cluster

Para remover a anotação, especifique --remove-annotations=baremetal.cluster.gke.io/prevent-deletion="true" no comando update.

Ignore as verificações prévias

Esta funcionalidade só está disponível com o bmctl update.

O valor predefinido do campo bypassPreflightCheck é false. Se definir este campo como true no ficheiro de configuração do cluster, as verificações prévias internas são ignoradas quando aplica recursos a clusters existentes.

  apiVersion: baremetal.cluster.gke.io/v1
  kind: Cluster
  metadata:
    name: cluster1
    namespace: cluster-cluster1
    annotations:
      baremetal.cluster.gke.io/private-mode: "true"
  spec:
    bypassPreflightCheck: true

Adicione ou remova administradores de clusters

`bmctl`

Pode adicionar ou remover um utilizador ou uma conta de serviço como administrador do cluster para um cluster de utilizadores especificando endereços de email na secção clusterSecurity.authorization.clusterAdmin.gcpAccounts do ficheiro de configuração do cluster. As contas recebem a função de administrador do cluster no cluster, o que lhes dá acesso total ao cluster.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterSecurity:
    authorization:
      clusterAdmin:
        gcpAccounts:
        - alex@example.com
        - hao@example.com
        - my-sa@example-project-12345.iam.gserviceaccount.com

Quando atualiza um cluster de utilizadores para adicionar uma conta, certifique-se de que inclui todas as contas na lista (contas existentes e novas), porque bmctl updatesubstitui a lista pelo que especificar no ficheiro de configuração. Para remover uma conta, remova-a do ficheiro de configuração do cluster e execute o comando bmctl update.

CLI gcloud

Pode adicionar ou remover um utilizador ou uma conta de serviço como administrador do cluster especificando um endereço de email na flag --admin-users. A flag aceita apenas um endereço de email. Para adicionar vários utilizadores, especifique uma conta em cada flag, por exemplo:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --admin-users=alex@example.com \
    --admin-users=hao@example.com
    --admin-users=my-sa@example-project-12345.iam.gserviceaccount.com

O comando update substitui toda a lista de concessões. Especifique todos os utilizadores existentes e novos que quer que sejam administradores do cluster.

Defina um utilizador de início de sessão

Pode especificar um nome de utilizador não raiz que quer usar para o acesso sem palavra-passe sudo às máquinas de nós no seu cluster. A sua chave SSH, sshPrivateKeyPath, tem de funcionar para o utilizador especificado. As operações de criação e atualização de clusters verificam se é possível aceder às máquinas dos nós com o utilizador e a chave SSH especificados.

`bmctl`

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    baremetal.cluster.gke.io/private-mode: "true"
spec:
  nodeAccess:
    loginUser: abm

CLI gcloud

Especifique o utilizador que quer usar para aceder a máquinas de nós na flag --login-user, por exemplo:

gcloud container bare-metal clusters update abm-user-cluster1a \
    --project=example-project-12345 \
    --location=us-central1 \
    --login-user=abm

Para ativar o acesso sudo sem palavra-passe para um utilizador, siga estes passos em cada máquina de nó do cluster:

Use sudo visudo para abrir o ficheiro sudoers para edição:
```
sudo visudo -f /etc/sudoers
```
O comando visudo bloqueia o ficheiro sudoers para impedir edições simultâneas e valida a sintaxe do ficheiro após a gravação.
Para o utilizador de início de sessão, adicione uma entrada ao ficheiro sudoers da seguinte forma:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Feche e guarde o ficheiro.
Para executar comandos com os privilégios do utilizador de início de sessão, execute o seguinte comando:
```
su - USERNAME
```
Para verificar se não é necessária uma palavra-passe para o utilizador de início de sessão executar comandos sudo, execute o seguinte comando sudo:
```
sudo ip a
```

Redes avançadas

Configura funcionalidades de rede avançadas em vários recursos personalizados depois de o cluster ser criado. Para usar os recursos personalizados e as funcionalidades de rede relacionadas, tem de ativar a rede avançada quando criar o cluster.

`bmctl`

Defina clusterNetwork.advancedNetworking para truena configuração do cluster quando criar o cluster:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

CLI gcloud

Inclua a flag --enable-advanced-networking no comando gcloud container bare-metal clusters create quando criar o cluster.

Depois de criar o cluster com a rede avançada ativada, pode configurar os recursos personalizados descritos nesta secção através do kubectl apply.

`NetworkGatewayGroup`

O recurso personalizado NetworkGatewayGroup é usado para fornecer endereços IP flutuantes para funcionalidades de rede avançadas, como o gateway NAT de saída ou a funcionalidade de equilíbrio de carga integrada com BGP.

apiVersion: networking.gke.io/v1
kind: NetworkGatewayGroup
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100

Balanceamento de carga de BGP

Configura o equilíbrio de carga do Border Gateway Protocol (BGP) no recurso do cluster e noutros recursos personalizados. Os comandos gcloud container bare-metal clusters create e update suportam a configuração do BGP no recurso do cluster, mas não nos recursos personalizados.

Quando configura equilibradores de carga agrupados com BGP, o equilíbrio de carga do plano de dados usa, por predefinição, os mesmos pares externos que foram especificados para o peering do plano de controlo. Em alternativa, pode configurar o equilíbrio de carga do plano de dados separadamente, usando o recurso personalizado BGPLoadBalancer e o recurso personalizado BGPPeer. Para mais informações, consulte o artigo Configure equilibradores de carga agrupados com BGP.

`BGPLoadBalancer`

apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
  name: default
  namespace: cluster-bm
spec:
  peerSelector:
    cluster.baremetal.gke.io/default-peer: "true"

`BGPPeer`

apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
  name: bgppeer1
  namespace: cluster-bm
  labels:
    cluster.baremetal.gke.io/default-peer: "true"
spec:
  localASN: 65001
  peerASN: 65002
  peerIP: 10.0.3.254
  sessions: 2

Aumente o intervalo da rede de serviços

Para criar mais serviços do que o limite inicial, pode reduzir a máscara CIDR do serviço IPv4 para aumentar a rede de serviços do cluster. Reduzir a máscara (o valor após "/") resulta num intervalo de rede maior. Só pode aumentar o intervalo do CIDR do serviço IPv4. Não é possível reduzir o intervalo de rede, o que significa que não é possível aumentar a máscara (o valor após "/").

`bmctl`

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  ...
  clusterNetwork:
    services:
      cidrBlocks:
        - 192.0.2.0/14
  ...

CLI gcloud

Para aumentar o intervalo do CIDR do serviço IPv4 num cluster de utilizadores, especifique o novo intervalo no comando --island-mode-service-address-cidr-blocks.

gcloud container bare-metal clusters update cluster1 \
    --project=example-project-12345 \
    --location=us-central1 \
    --island-mode-service-address-cidr-blocks=192.0.2.0/14

Configure as definições de obtenção de imagens do kubelet

O kubelet é executado em cada nó do cluster. O kubelet é responsável por monitorizar os contentores num nó e garantir que estão em bom estado. Quando necessário, o kubelet consulta e extrai imagens do Artifact Registry.

A atualização manual das configurações do kubelet e a respetiva sincronização em todos os nós do cluster pode ser difícil. Para piorar a situação, as alterações manuais de configuração do kubelet nos seus nós são perdidas quando atualiza o cluster.

Para ajudar a tornar as atualizações sincronizadas mais fáceis e persistentes, o Google Distributed Cloud permite-lhe especificar algumas definições do kubelet para cada um dos seus conjuntos de nós do cluster: nós do plano de controlo, nós do balanceador de carga e nós de trabalho. As definições aplicam-se a todos os nós num determinado conjunto e persistem nas atualizações do cluster. Os campos destas definições são mutáveis, pelo que pode atualizá-los em qualquer altura e não apenas durante a criação do cluster.

`bmctl`

Os seguintes campos suportados controlam as operações de obtenção do Artifact Registry para o kubelet:

registryBurst (predefinição: 10)
registryPullQPS (predefinição: 5)
serializeImagePulls (predefinição: verdadeiro)

Para mais informações sobre cada um dos campos de configuração do kubelet, consulte a Referência de campos de configuração do cluster.

Pode especificar estes campos nas secções kubeletConfig da especificação do cluster e da especificação do node pool para os seguintes pools de nós:

Especificação do cluster:
Nós do plano de controlo spec.controlPlane.nodePoolSpec.kubeletConfig
Nós do balanceador de carga spec.loadBalancer.nodePoolSpec.kubeletConfig
Especificação do NodePool:
Nós trabalhadores spec.kubeletConfig

O exemplo seguinte mostra os campos adicionados com os respetivos valores predefinidos no ficheiro de configuração do cluster. Tenha em atenção que a anotação preview.baremetal.cluster.gke.io/custom-kubelet: "enable" é obrigatória.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/custom-kubelet: "enable"
spec:
  ...
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
  loadBalancer:
    nodePoolSpec:
      kubeletConfig:
        registryBurst: 10
        registryPullQPS: 5
        serializeImagePulls: true
  ...
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-new
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  ...
  kubeletConfig:
    registryBurst: 10
    registryPullQPS: 5
    serializeImagePulls: true

Em cada caso, a definição aplica-se a todos os nós no conjunto.

CLI gcloud

Os seguintes sinalizadores controlam as operações de obtenção do Artifact Registry para o kubelet:

Como usar

Seguem-se algumas considerações para ajustar as obtenções de imagens:

Uma vez que as imagens são extraídas em série por predefinição, uma extração de imagens que demore muito tempo pode atrasar todas as outras extrações de imagens agendadas num nó. A obtenção de imagens atrasada pode bloquear o processo de atualização (especialmente quando é necessário implementar novas imagens do Google Distributed Cloud num nó). Se for afetado por atrasos na obtenção de imagens, pode desativar a serialização da obtenção de imagens para permitir a obtenção de imagens em paralelo.
Se estiver a ter erros de limitação de obtenção de imagens, como pull QPS exceeded, é recomendável aumentar *-registry-pull-qps e *-registry-burst para aumentar a taxa de transferência de obtenção de imagens. Estes dois campos ajustam a taxa de obtenção e o tamanho da fila, e podem ajudar a resolver outros problemas relacionados com a limitação. Não são permitidos valores negativos.

Personalização do Keepalived

A partir da versão 1.32, o Google Distributed Cloud oferece alguma personalização da configuração do Keepalived. Com o balanceamento de carga integrado, o balanceador de carga do plano de controlo publica o endereço IP virtual (VIP) do plano de controlo. O Google Distributed Cloud executa o Keepalived e o HAProxy como pods estáticos do Kubernetes nos nós do balanceador de carga para anunciar o VIP do plano de controlo. O Keepalived usa o Protocolo de redundância do router virtual (VRRP) nos nós do balanceador de carga para alta disponibilidade.

Os clusters da versão 1.32 e posteriores têm as seguintes personalizações do Keepalived:

Para planos de controlo de alta disponibilidade, o Google Distributed Cloud configura automaticamente a configuração VRRP do Keepalived para tornar o comportamento de comutação por falha determinístico e evitar a intercalação de respostas ARP com diferentes endereços MAC:
- Cada instância do Keepalived é configurada automaticamente com um valor priority diferente no router VRRP.
- Cada instância do Keepalived é configurada automaticamente com nopreempt para evitar eleições quando uma instância não principal é reiniciada.
O Google Distributed Cloud permite-lhe especificar o número de mensagens ARP gratuitas (GARP) a enviar de cada vez após um nó do plano de controlo transitar para a função de servidor principal. Para alterar o número de mensagens GARP a enviar, adicione o campo controlPlane.loadBalancer.keepalivedVRRPGARPMasterRepeat ao ficheiro de configuração do cluster, defina-o para o novo valor e atualize o cluster. Este valor é mapeado para a definição vrrp_garp_master_repeat para o Keepalived. O valor predefinido é 5.

O exemplo seguinte mostra como especificar keepalivedVRRPGARPMasterRepeat no ficheiro de configuração do cluster:
```
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: hybrid-ha-lb
  namespace: cluster-hybrid-ha-lb
spec:
  type: hybrid
  profile: default
  anthosBareMetalVersion: 1.33
  gkeConnect:
    projectID: project-fleet
  controlPlane:
    loadBalancer:
      keepalivedVRRPGARPMasterRepeat: 1
    nodePoolSpec:
      nodes:
      - address: 10.200.0.2
      - address: 10.200.0.3
      - address: 10.200.0.4
  ...
```

Instale ou desinstale o operador de GPU da NVIDIA incluído

O operador de GPU da NVIDIA permite-lhe executar cargas de trabalho relacionadas com a GPU nos seus clusters. A partir da versão 1.33.0 do Google Distributed Cloud, os clusters são fornecidos com uma pilha do operador de GPU da NVIDIA completa para oferecer uma solução gerida para processar os componentes de software da NVIDIA necessários para aprovisionar GPUs nos nós de trabalho do cluster.

Pré-requisitos

Antes de instalar o operador de GPU da NVIDIA incluído, certifique-se de que o seu ambiente cumpre os seguintes requisitos:

Cluster operacional: tem um cluster bare metal funcional criado com o Google Distributed Cloud.
GPUs NVIDIA: as GPUs NVIDIA estão instaladas nos nós de trabalho do cluster. A secção seguinte para instalar o operador de GPU da NVIDIA inclui passos para verificar se as GPUs estão instaladas corretamente e são reconhecidas pelo seu sistema operativo.
Versão do controlador da NVIDIA compatível: a versão do controlador da NVIDIA que usa tem de ser compatível com a sua GPU, o seu sistema operativo e a versão do CUDA que as suas aplicações usam. Para mais informações, consulte as informações de versão.

Tem as seguintes opções de instalação de controladores NVIDIA:
- Use o controlador da NVIDIA pré-instalado na imagem do sistema operativo.
- Use as instruções no guia de início rápido de instalação do controlador da NVIDIA para instalar manualmente o controlador da NVIDIA.
O controlador da GPU NVIDIA tem de estar instalado e pronto antes de ativar o operador da GPU NVIDIA incluído.

Informações da versão

Esta secção contém informações da versão do software para o operador de GPU da NVIDIA incluído.

Versões dos componentes de software

A versão 1.33 do Google Distributed Cloud inclui a versão 25.3.1 do NVIDIA GPU Operator. No Google Distributed Cloud, o pacote contém as seguintes imagens:

Versão v1.17.8 do NVIDIA Container Toolkit
NVIDIA DCGM Exporter v3.3.9-3.6.1
NVIDIA Kubernetes Device Plugin v0.17.1
Node Feature Discovery v0.17.2

As versões de imagens incluídas na versão 1.33 do Google Distributed Cloud podem não corresponder exatamente às versões dos componentes de software indicadas nas notas de lançamento 25.3.1.

Compatibilidade de controladores

Consulte o suporte de plataformas para a versão 25.3.1 no NVIDIA Docs Hub para obter informações de compatibilidade de controladores.

Atualizar o operador de GPU da NVIDIA incluído

Se tiver instalado o operador de GPU da NVIDIA no seu cluster, quando fizer a atualização para uma nova versão secundária, é instalada a versão mais recente incluída do operador de GPU da NVIDIA.

Instale o operador incluído

Enquanto o operador de GPU da NVIDIA incluído estiver em pré-visualização, instale-o através de bmctl update para adicionar a seguinte anotação ao cluster que tem nós de GPU:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
  annotations:
    preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"
spec:
  ...

A pilha do operador de GPU da NVIDIA é instalada no cluster quando a anotação é aplicada.

Desinstale o operador incluído

Enquanto o operador de GPU da NVIDIA incluído estiver em pré-visualização, desinstale-o usando bmctl update para remover a seguinte anotação do cluster que tem nós de GPU:

preview.baremetal.cluster.gke.io/nvidia-gpu-operator: "enable"

Todos os componentes da pilha do operador de GPU da NVIDIA são removidos do cluster quando a anotação é removida.

Ative a atribuição dinâmica de recursos

A atribuição dinâmica de recursos é uma API Kubernetes que lhe permite pedir e partilhar recursos genéricos, como GPUs, entre pods e contentores. Os controladores de terceiros gerem estes recursos. Esta capacidade ajuda a executar cargas de trabalho de IA através da alocação dinâmica e precisa dos recursos de GPU nos seus clusters bare metal, o que melhora a utilização de recursos e o desempenho para cargas de trabalho exigentes.

A atribuição dinâmica de recursos está disponível para pré-visualização para clusters da versão 1.33 e posteriores. As instruções seguintes descrevem como configurar o cluster para usar a atribuição dinâmica de recursos. Depois de ativada, pode configurar as cargas de trabalho da GPU para usar a atribuição dinâmica de recursos.

Configure o cluster para ativar a atribuição dinâmica de recursos:

Edite o ficheiro de configuração do cluster para incluir a anotação preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable" de pré-visualização e adicione DynamicResourceAllocation: true em featureGates na secção kubeletConfig:

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: dra
  namespace: cluster-dra
  annotations:
    preview.baremetal.cluster.gke.io/dynamic-resource-allocation: "enable"
spec:
  controlPlane:
    nodePoolSpec:
      kubeletConfig:
        featureGates:
          DynamicResourceAllocation: true
# ... other cluster configuration

Atualize o cluster executando o comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Substitua o seguinte:
- CLUSTER_NAME: o nome do cluster de utilizadores que está a atualizar.
- ADMIN_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
Depois de aplicar esta configuração, o campo READY das suas máquinas de hardware físico pode alternar entre True e False várias vezes. Aguarde que o campo READY se estabilize em True antes de continuar.
Para ativar o DynamicResourceAllocation feature gate em pools de nós que tenham nós com GPUs, defina DynamicResourceAllocation como true na secção featureGates da secção kubeletConfig da especificação NodePool:

Para ver instruções sobre como adicionar e atualizar um node pool, consulte o artigo Faça a gestão de node pools num cluster.
```
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: np
  namespace: cluster-dra
spec:
  clusterName: dra
  kubeletConfig:
    featureGates:
      DynamicResourceAllocation: true
  nodes:
# ... other node pool configuration
```
Depois de adicionar ou atualizar o conjunto de nós, aguarde que todas as máquinas bare metal no conjunto de nós atinjam o estado Ready.

Para verificar o estado das suas máquinas bare metal do cluster, use o seguinte comando:

kubectl get baremetalmachines --kubeconfig ADMIN_KUBECONFIG -A

Quando as máquinas sem sistema operativo estiverem prontas, a resposta deve ser semelhante à seguinte resposta de exemplo:

NAMESPACE          NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION        DESIRED ABM VERSION
cluster-admin      10.200.0.2   dra        true    baremetal://10.200.0.2   10.200.0.2    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.6   user-dra   true    baremetal://10.200.0.6   10.200.0.6    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.7   user-dra   true    baremetal://10.200.0.7   10.200.0.7    1.33.0-gke.793   1.33.0-gke.793
cluster-user-dra   10.200.0.8   user-dra   true    baremetal://10.200.0.8   10.200.0.8    1.33.0-gke.793   1.33.0-gke.793

Limitações

O operador de GPU da NVIDIA incluído tem as seguintes limitações:

O operador de GPU da NVIDIA incluído suporta apenas os seguintes componentes de software da NVIDIA:
- NVIDIA Container Toolkit
- NVIDIA DCGM Exporter
- NVIDIA Kubernetes Device Plugin
- NVIDIA MIG Manager para Kubernetes.
Durante a pré-visualização, a configuração do operador de GPU da NVIDIA é fixa. Se tentar personalizar quaisquer definições, estas são reconciliadas com as definições de instalação originais.
Não é possível usar o operador de GPU da NVIDIA incluído para instalar controladores de GPU da NVIDIA.
Durante a pré-visualização, esta funcionalidade usa o grupo de APIs resource.k8s.io/v1beta1, que difere do grupo de APIs Kubernetes de código aberto para esta funcionalidade, resource.k8s.io/v1. O grupo de APIs de v1código aberto oferece mais funcionalidades e melhor estabilidade do que o grupo de APIs v1beta1.

O que se segue?

Para usar a atribuição dinâmica de recursos com as suas cargas de trabalho de GPU, consulte o artigo Faça a gestão de dispositivos GPU com a atribuição dinâmica de recursos.
Para saber mais acerca da atribuição dinâmica de recursos, consulte o artigo Atribuição dinâmica de recursos na documentação do Kubernetes.

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

Como atualizar clusters

bmctl

CLI gcloud

Terraform

Adicione ou remova nós num cluster

bmctl

Exemplo: remover um nó de trabalho

CLI gcloud

Exemplo: remover um nó de trabalho

Substitua os nós do plano de controlo de HA

bmctl

Exemplo: substituir um nó do plano de controlo de HA

CLI gcloud

Exemplo: substituir um nó do plano de controlo de HA

Valide as suas atualizações

kubectl

CLI gcloud

Pools de endereços do balanceador de carga

bmctl

CLI gcloud

Evite a eliminação inadvertida de clusters

bmctl

CLI gcloud

Ignore as verificações prévias

Adicione ou remova administradores de clusters

bmctl

CLI gcloud

Defina um utilizador de início de sessão

bmctl

CLI gcloud

Redes avançadas

bmctl

CLI gcloud

NetworkGatewayGroup

Balanceamento de carga de BGP

BGPLoadBalancer

BGPPeer

Aumente o intervalo da rede de serviços

bmctl

CLI gcloud

Configure as definições de obtenção de imagens do kubelet

bmctl

CLI gcloud

Como usar

Personalização do Keepalived

Instale ou desinstale o operador de GPU da NVIDIA incluído

Pré-requisitos

Informações da versão

Versões dos componentes de software

Compatibilidade de controladores

Atualizar o operador de GPU da NVIDIA incluído

Instale o operador incluído

Desinstale o operador incluído

Ative a atribuição dinâmica de recursos

Limitações

O que se segue?

Documentação de referência

bmctl

CLI gcloud

Terraform

Atualize clusters

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`