Esta página foi traduzida pela API Cloud Translation.

Atualizar clusters

Depois de criar um cluster, é possível alterar alguns aspectos da configuração dele. Por exemplo:

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

É possível usar bmctl ou a CLI do Google Cloud para fazer atualizações em um cluster. Se você criou um cluster de administrador ou de usuário usando o Terraform, use-o para atualizar o cluster. Observações:

Muitos aspectos da configuração do cluster são imutáveis e não podem ser atualizados após a criação do cluster. Consulte uma lista abrangente de campos mutáveis e imutáveis na Referência dos campos de configuração do cluster. A referência de campo é uma tabela classificável. Clique nos cabeçalhos das colunas para alterar a ordem de classificação. Clique no nome de um campo para conferir a descrição.
A gcloud CLI e o Terraform só aceitam a atualização de clusters de administrador e usuário. Você precisa usar bmctl para atualizar outros tipos de cluster.
A gcloud CLI e o Terraform só aceitam alterações nos recursos de cluster e pool de nós. Use kubectl ou bmctl para atualizar outros recursos personalizados que afetam o cluster.

Como atualizar clusters

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

`bmctl`

Altere os valores dos campos aplicáveis no arquivo de configuração do cluster, que fica localizado aqui por padrão:
bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml
Para atualizar o cluster, execute o comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=KUBECONFIG
```
Substitua:
- CLUSTER_NAME: o nome do cluster que você quer atualizar.
- KUBECONFIG: para clusters de administrador, híbridos ou independentes, insira o caminho para o arquivo kubeconfig do cluster. Para um cluster de usuário, insira o caminho para o arquivo kubeconfig do cluster de admin.

Não use bmctl update e kubectl apply -f de forma intercambiável ao editar o arquivo de configuração do cluster. Quando esses comandos são usados alternadamente, o conteúdo preenchido pelo cabeçalho da especificação do cluster pode ser removido acidentalmente. Por exemplo, é possível usar bmctl update para atualizar o arquivo de configuração do cluster para configurar um espelho de registro. O cluster terá spec.nodeConfig.registryMirrors preenchido após a reconciliação.

Se você tentar fazer alterações no cluster usando a configuração com o comando kubectl apply -f, o spec.nodeConfig.registryMirrors preenchido pelo reconciliador no cluster será removido. Esse comportamento acontece porque a configuração não existe na especificação de configuração do cluster, mas existe no cluster.

CLI da gcloud

Especifique apenas as flags da configuração que você quer modificar.
Execute o comando de atualização aplicável:
- Clusters de administrador: gcloud container bare-metal admin-clusters update
- Clusters de usuários: gcloud container bare-metal clusters update.
- Pools de nós em um cluster de usuário: gcloud container bare-metal node-pools update

Terraform

Altere os valores dos campos aplicáveis no arquivo de configuração do Terraform que você usou para criar o cluster ou o pool de nós. Consulte as descrições detalhadas dos campos na documentação de referência do Terraform:
Execute o comando terraform apply para atualizar a configuração.

As seções a seguir descrevem alguns exemplos comuns para atualizar um cluster atual.

Adicionar ou remover nós de um cluster

Um pool de nós é um grupo de nós de um cluster que têm a mesma configuração. Lembre-se de que um nó sempre pertence a um pool. Para adicionar um novo nó a um cluster, adicione o nó a um pool específico. Remover um nó de um pool equivale a remover o nó do cluster por completo.

Há três tipos de pools de nós no Google Distributed Cloud: plano de controle, balanceador de carga e pools de nós de trabalho. Nas seções a seguir, descrevemos como adicionar ou remover nós de cada tipo de pool.

`bmctl`

Para adicionar ou remover um nó de um pool, adicione ou remova o endereço IP do nó em uma seção específica do arquivo de configuração do cluster. A lista a seguir mostra qual seção editar em um determinado pool de nós:

Pool de nós de trabalho: adicione ou remova o endereço IP do nó na seção spec.nodes da especificação NodePool.
Pool de nós do plano de controle: adicione ou remova o endereço IP do nó na seçã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 seção spec.loadBalancer.nodePoolSpec.nodes da especificação Cluster.

Exemplo: remover um nó de trabalho

Confira um exemplo de arquivo de configuração de cluster 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 você está removendo estiver executando pods críticos, primeiro coloque o nó no modo de manutenção.

É possível monitorar o processo de drenagem de nós de trabalho visualizando os campos status.nodesDrained e status.nodesDraining no recurso NodePool.
Edite o arquivo de configuração do cluster para excluir a entrada do endereço IP do nó.

Atualize o cluster:

bmctl update cluster1 \
    --kubeconfig=ADMIN_KUBECONFIG

CLI da gcloud

Use um comando update para adicionar ou remover nós. O comando update usado e a flag em que o endereço IP é especificado dependem do tipo de pool de nós que você quer atualizar:

Pool de nós de trabalho: execute gcloud container bare-metal node-pools update e especifique o endereço IP na flag --node-configs 'node-ip=IP_ADDRESS'.
Pool de nós do plano de controle em um cluster de administrador: execute gcloud container bare-metal admin-clusters update e especifique o endereço IP na flag --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nós do plano de controle em um cluster de usuário: execute gcloud container bare-metal clusters update e especifique o endereço IP na flag --control-plane-node-configs 'node-ip=IP_ADDRESS'.
Pool de nós do balanceador de carga: execute gcloud container bare-metal clusters update e especifique o endereço IP na flag --metal-lb-load-balancer-node-configs 'node-ip=IP_ADDRESS' ou
--bgp-load-balancer-node-configs 'node-ip=IP_ADDRESS'

A flag em que você especifica o endereço IP aceita apenas um node-ip. Inclua a flag para cada endereço IP no pool de nós.

Os comandos update substituem todos os endereços IP pelos endereços IP que você especificar. Para adicionar um nó, inclua os endereços IP dos nós atuais e o endereço IP do novo nó no comando update. Da mesma forma, você remove os nós incluindo apenas os endereços IP dos nós que quer manter.

Exemplo: remover um nó de trabalho

Nesta seção, mostramos como remover um nó de trabalho de um pool de nós usando dados de exemplo. Outros comandos da gcloud CLI que podem ser úteis também estão incluídos nas etapas a seguir.

(Opcional) Se o nó que você está removendo estiver executando pods críticos, primeiro coloque o nó no modo de manutenção.

É possível monitorar o processo de drenagem de nós de trabalho visualizando os campos status.nodesDrained e status.nodesDraining no recurso NodePool.

Execute o comando list para listar todos os pools 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 será assim:

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 pool 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 saída a seguir está truncado para facilitar a leitura:
```
annotations:
  ...
  baremetal.cluster.gke.io/version: 1.29
...
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
...
```
Observe o seguinte no exemplo de saída:
- O campo name contém o nome totalmente qualificado do pool de nós. Ao especificar o nome do pool de nós em um comando, é possível especificar o nome totalmente qualificado ou o nome do pool de nós, por exemplo, node-pool-1, junto com --cluster, --project e as flags --location.
- A seção nodeConfigs contém dois campos nodeIp com os endereços IP dos nós.
Execute o comando a seguir 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 você especificar. Como 192.0.2.1 não está incluído, o nó foi removido.

A saída desse comando é semelhante a:
```
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. Descubra o status da operação executando o comando a seguir em outra janela de terminal:
```
gcloud container bare-metal operations describe operation-1697154681749-6078d9def4030-76686d6e-9fcb1de9 \
    --project= example-project-12345 \
    --location=us-central1
```
Execute o comando de novo de vez em quando para verificar o status.

Se a remoção do nó falhar, você poderá forçar a remoção dele do cluster. Consulte detalhes em Forçar a remoção de nós corrompidos.

Substituir nós do plano de controle de alta disponibilidade

`bmctl`

É possível usar bmctl para substituir os nós do plano de controle de alta disponibilidade (HA, na sigla em inglês) em todos os tipos de cluster.

Para substituir um nó em um cluster, siga estas etapas:

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

Exemplo: substituir um nó do plano de controle de alta disponibilidade

Confira um exemplo de arquivo de configuração de cluster que mostra três nós do plano de controle em um cluster de usuário:

---
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ó listado na seção spec.controlPlane.nodePoolSpec.nodes, siga estas etapas:

Remova o nó excluindo a entrada de endereço IP dele no arquivo de configuração do cluster. Depois dessa alteração, o arquivo de configuração do cluster terá esta aparência:

---
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 mudanças a seguir:
- Substitua CLUSTER_NAME pelo nome do cluster que você quer atualizar.
- Se o cluster for de autogerenciamento, como o cluster de administrador ou independente, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster. Se o cluster for de usuário, como neste exemplo, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de admin.
Depois que o comando bmctl update for executado, levará algum tempo para concluir os jobs machine-preflight e machine-init. Confira o status dos nós e os respectivos pools executando os comandos descritos na seção Verificar as atualizações deste documento. Quando o pool e os nós estiverem em estado "pronto", siga para a próxima etapa.
Adicione um novo nó do plano de controle ao pool adicionando o endereço IP do novo nó do plano de controle à seção spec.controlPlane.nodePoolSpec.nodes do arquivo de configuração do cluster. Depois dessa alteração, o arquivo de configuração do cluster ficará assim:
```
---
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 da gcloud

É possível usar a gcloud CLI para substituir os nós do plano de controle de alta disponibilidade (HA, na sigla em inglês) nos clusters de administrador e usuário.

Para substituir um nó em um cluster, siga estas etapas:

Remova o endereço IP do nó executando o comando update aplicável:
- Cluster de usuário: gcloud container bare-metal clusters update
- Cluster de administrador: gcloud container bare-metal admin-clusters update
Verifique o status da remoção do nó no cluster executando 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 controle de alta disponibilidade

Nesta seção, mostramos como substituir um plano de controle de um cluster usando dados de exemplo. Outros comandos da gcloud CLI que podem ser úteis também estão incluídos nas etapas a seguir.

Execute o comando list para listar todos os clusters de usuário em um projeto do Google Cloud:

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

Definir --location=- significa listar todos os clusters em todas as regiões. Se você precisar reduzir o escopo da lista, defina --location como uma região específica.

O resultado será assim:

NAME                 LOCATION      VERSION   ADMIN_CLUSTER        STATE
abm-user-cluster1a   us-central1   1.29      abm-admin-cluster1   RUNNING
abm-user-cluster1b   europe-west1  1.29      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 saída 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
...
```
Observe o seguinte no exemplo de saída:
- O campo name contém o nome totalmente qualificado do cluster. Ao especificar o nome do cluster em um comando, é possível definir o nome totalmente qualificado ou o nome do cluster, por exemplo, abm-user-cluster1a, com --project e --location flags.
- A seção nodeConfigs contém três campos nodeIp com os endereços IP dos nós do plano de controle.

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'

A saída desse comando é semelhante a:

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. Descubra o status da operação executando o comando a seguir em outra janela de terminal:

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

Execute o comando de novo de vez em quando para verificar o status.

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'

Verificar as atualizações

`kubectl`

Também é possível ver o status dos nós e os respectivos pools com o comando kubectl get.

Por exemplo, o comando a seguir mostra o status dos pools de nós no namespace do cluster cluster-my-cluster:

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

O sistema retorna 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 a etapa de reconciliação ainda está em andamento. Aguarde até o status mudar para Reconciling=0.

É possível também conferir o status dos nós do cluster executando o seguinte comando:

kubectl get nodes --kubeconfig=KUBECONFIG

CLI da gcloud

Conforme descrito anteriormente, depois de executar um comando update, é possível verificar o status da operação usando gcloud container bare-metal operations describe OPERATIONS_ID. A saída do comando fornece o status 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 usada para atualizar um pool de nós, é possível ver o status atual de um pool de nós executando o comando describe aplicável, conforme mostrado anteriormente.

Confira como diagnosticar seus clusters em Criar snapshots para diagnosticar clusters.

Pools de endereços do balanceador de carga

bmctl

A seção addressPools contém campos para especificar pools de balanceamento de carga para os balanceadores de carga em pacote do MetalLB e do protocolo de gateway de borda (BGP, na sigla em inglês). É possível adicionar mais pools de endereços de balanceamento de carga a qualquer momento, mas não é possível remover ou modificar pools de endereços atuais. A partir do Google Distributed Cloud versão 1.16.0, é possível modificar os valores de addressPools.avoidBuggyIPs e addressPools.manualAssign a qualquer momento.

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 da gcloud

É possível adicionar mais pools de endereços de balanceamento de carga a qualquer momento para os balanceadores de carga em pacote, mas não é possível remover pools de endereços atuais. A flag especificada em gcloud container bare-metal clusters update para adicionar um pool de endereços depende do tipo de balanceador de carga em pacote:

MetalLB (camada 2): use a flag --metal-lb-address-pools.
Protocolo de gateway de borda (BGP, na sigla em inglês): 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 de sua escolha para o pool.
avoid-buggy-ips: se você definir como True, o controlador de gerenciamento de endereços IP (IPAM, na sigla em inglês) não atribuirá endereços IP que terminam em .0 ou .255 aos Serviços. Isso evita o problema de dispositivos de consumo com bugs que descartam por erro o tráfego enviado para esses endereços IP especiais. Se não for especificado, False será usado como padrão. A partir do Google Distributed Cloud versão 1.16.0, é possível modificar esse valor em um pool de endereços atual.
manual-assign: se você não quiser que o controlador IPAM atribua automaticamente endereços IP deste pool para Serviços, defina como True. Em seguida, um desenvolvedor pode criar um Serviço do tipo LoadBalancer e especificar manualmente um dos endereços do pool. Se não for especificado, manual-assign será definido como False. A partir do Google Distributed Cloud versão 1.16.0, é possível modificar esse valor em um pool de endereços atual.
Na lista de addresses: cada endereço precisa ter um intervalo no formato CIDR ou de hífen. Para especificar um único endereço IP em um pool, como o VIP de entrada, use /32 na notação CIDR, por exemplo, 192.0.2.1/32.

Observe as seguintes regras de sintaxe:

Coloque o valor inteiro entre aspas simples.
Não é permitido usar espaços em branco.
Separe cada intervalo de endereços IP com um ponto e vírgula.

É possível especificar mais de uma instância da flag, conforme mostrado no exemplo a seguir:

--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 pools de endereços do balanceador de carga, consulte loadBalancer.addressPools em "Configurar o balanceamento de carga em pacote".

Impedir a exclusão acidental de clusters

`bmctl`

Se você adicionar a anotação baremetal.cluster.gke.io/prevent-deletion: "true" ao arquivo de configuração do cluster, não será possível excluir o cluster. Por exemplo, executar 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 da gcloud

Se você especificar a flag --add-annotations com o valor baremetal.cluster.gke.io/prevent-deletion="true", não será possível excluir o cluster. Exemplo:

Adicione a anotação para evitar a exclusão acidental do cluster:

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 excluir o cluster de usuário:

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

A saída desse comando terá esta aparência:

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.

Ignorar verificações de simulação

Este recurso está disponível apenas com bmctl update.

O valor padrão do campo bypassPreflightCheck é false. Se você definir esse campo como true no arquivo de configuração do cluster, as verificações de simulação internas serão ignoradas para aplicar recursos aos clusters atuais.

  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

Adicionar ou remover administradores de cluster

`bmctl`

É possível adicionar ou remover um usuário ou uma conta de serviço como administrador de um cluster de usuário. Basta especificar endereços de e-mail na seção clusterSecurity.authorization.clusterAdmin.gcpAccounts do arquivo de configuração do cluster. As contas recebem o papel de administrador do cluster, fornecendo acesso total a ele.

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

Ao atualizar um cluster de usuário para adicionar uma conta, inclua todas as contas da lista (contas novas e atuais) porque bmctl update substitui a lista pelo que você especifica no arquivo de configuração. Para remover uma conta, remova-a do arquivo de configuração do cluster e execute bmctl update.

gcloud CLI

É possível adicionar ou remover um usuário ou uma conta de serviço como administrador do cluster. Basta especificar um endereço de e-mail na flag --admin-users. A flag aceita apenas um endereço de e-mail. Para adicionar vários usuários, 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 permissões. Especifique todos os usuários atuais e novos que você quer que sejam administradores do cluster.

Definir um usuário de login

É possível especificar um nome de usuário não raiz que queira usar para o acesso do recurso sudo sem senha às máquinas de nós no cluster. Sua chave SSH, sshPrivateKeyPath, precisa funcionar para o usuário especificado. As operações de criação e atualização de clusters verificam se as máquinas de nós podem ser acessadas com o usuário 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 da gcloud

Especifique o usuário que você quer usar para acessar 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 senha para um usuário, siga estas etapas em cada máquina de nó do cluster:

Use sudo visudo para abrir o arquivo sudoers para edição:
```
sudo visudo -f /etc/sudoers
```
O comando visudo bloqueia o arquivo sudoers para evitar edições simultâneas e valida a sintaxe do arquivo ao salvar.
Para seu usuário de login, adicione uma entrada ao arquivo sudoers da seguinte maneira:
```
USERNAME ALL=(ALL) NOPASSWD: ALL
```
Feche e salve o arquivo.
Para executar comandos com os privilégios do usuário de login, execute o seguinte comando:
```
su - USERNAME
```
Para verificar se uma senha não é necessária para que o usuário de login execute os comandos sudo, execute o seguinte comando sudo:
```
sudo ip a
```

Rede avançada

Você configura recursos de rede avançados em vários recursos personalizados após a criação do cluster. Para usar os recursos personalizados e os recursos de rede relacionados, ative a rede avançada ao criar o cluster.

`bmctl`

Defina clusterNetwork.advancedNetworking como true na configuração do cluster ao criá-lo:

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

gcloud CLI

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

Depois que o cluster for criado com a rede avançada ativada, será possível configurar os recursos personalizados descritos nesta seção usando kubectl apply.

`NetworkGatewayGroup`

O recurso personalizado NetworkGatewayGroup é usado para fornecer endereços IP flutuantes para recursos de rede avançados, como o gateway NAT de saída ou o recurso de balanceamento de carga em pacote com o 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 do BGP

Configure o balanceamento de carga do protocolo de gateway de borda (BGP) no recurso do cluster e em outros recursos personalizados. Os comandos gcloud container bare-metal clusters create e update oferecem suporte à configuração do BGP no recurso de cluster, mas não nos recursos personalizados.

Quando você configura balanceadores de carga em pacote com o BGP, o balanceamento de carga do plano de dados usa, por padrão, os mesmos pares externos especificados para o peering do plano de controle. Como alternativa, é possível configurar o balanceamento de carga do plano de dados separadamente usando os recursos personalizados BGPLoadBalancer e BGPPeer. Para mais informações, consulte Configurar balanceadores de carga em pacote com o 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

Aumentar o intervalo da rede de serviço

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

`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 da gcloud

Para aumentar o intervalo do CIDR de serviço IPv4 em um cluster de usuário, especifique o novo intervalo na flag --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

Definir as configurações de extração de imagem do kubelet

O kubelet é executado em cada nó do cluster. O kubelet é responsável por monitorar contêineres em um nó e garantir que eles estejam íntegros. Quando necessário, o kubelet consulta e extrai imagens do Container Registry.

Atualizar as configurações do kubelet manualmente e mantê-las sincronizadas em todos os nós do cluster pode ser um desafio. Para piorar, as alterações manuais da configuração do kubelet nos nós são perdidas quando você faz upgrade do cluster.

Para tornar as atualizações sincronizadas mais fáceis e permanentes, o Google Distributed Cloud permite que você especifique algumas configurações do kubelet para cada um dos pools de nós do cluster: nós do plano de controle, nós do balanceador de carga e nós de trabalho. As configurações se aplicam a todos os nós em um determinado pool e persistem por meio de upgrades de cluster. Os campos dessas configurações são mutáveis, para que você possa atualizá-los a qualquer momento, não apenas durante a criação do cluster.

`bmctl`

Os campos compatíveis a seguir controlam as operações de pull do Container Registry para o kubelet:

registryBurst (padrão: 10)
registryPullQPS (padrão: 5)
serializeImagePulls (padrão: true)

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

É possível definir esses campos nas seções kubeletConfig da especificação do cluster e do NodePool para os seguintes pools de nós:

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

O exemplo a seguir mostra os campos adicionados com os valores padrão no arquivo de configuração do cluster. Observe 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 configuração se aplica a todos os nós do pool.

CLI da gcloud

As flags a seguir controlam as operações de pull do Container Registry para o kubelet:

Como usar

Veja algumas considerações para ajustar pulls da imagem:

Como as imagens são extraídas em série por padrão, um pull de imagem que demora muito pode atrasar todos os outros pulls de imagem programados em um nó. O atraso na extração de imagens pode bloquear o processo de upgrade, principalmente quando novas imagens do Google Distributed Cloud precisam ser implantadas em um nó. Se você for afetado por atrasos de pulls de imagem, desative a opção de serializar pulls de imagem para permitir pulls de imagem paralelos.
Se você encontrar erros de limitação de pull de imagem, como pull QPS exceeded, aumente *-registry-pull-qps e *-registry-burst para aumentar a capacidade de processamento do pull de imagem. Esses dois campos ajustam a taxa de pull e o tamanho da fila e podem ajudar a resolver outros problemas relacionados à limitação. Valores negativos não são permitidos.

Atualizar clusters

Como atualizar clusters

bmctl

CLI da gcloud

Terraform

Adicionar ou remover nós de um cluster

bmctl

Exemplo: remover um nó de trabalho

CLI da gcloud

Exemplo: remover um nó de trabalho

Substituir nós do plano de controle de alta disponibilidade

bmctl

Exemplo: substituir um nó do plano de controle de alta disponibilidade

CLI da gcloud

Exemplo: substituir um nó do plano de controle de alta disponibilidade

Verificar as atualizações

kubectl

CLI da gcloud

Pools de endereços do balanceador de carga

bmctl

CLI da gcloud

Impedir a exclusão acidental de clusters

bmctl

CLI da gcloud

Ignorar verificações de simulação

Adicionar ou remover administradores de cluster

bmctl

gcloud CLI

Definir um usuário de login

bmctl

CLI da gcloud

Rede avançada

bmctl

gcloud CLI

NetworkGatewayGroup

Balanceamento de carga do BGP

BGPLoadBalancer

BGPPeer

Aumentar o intervalo da rede de serviço

bmctl

CLI da gcloud

Definir as configurações de extração de imagem do kubelet

bmctl

CLI da gcloud

Como usar

Documentação de referência

bmctl

CLI da gcloud

Terraform

`bmctl`

`bmctl`

`bmctl`

`kubectl`

`bmctl`

`bmctl`

`bmctl`

`bmctl`

`NetworkGatewayGroup`

`BGPLoadBalancer`

`BGPPeer`

`bmctl`

`bmctl`

`bmctl`