Atualizar clusters

Version 1.16 

• Mais recente
• Versão 1.16
• Versões anteriores (sem suporte)

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 é usada para atualizar um cluster:

bmctl

1. 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

2. 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.

gcloud CLI

1. Especifique apenas as flags da configuração que você quer modificar.

2. 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

1. Altere os valores dos campos aplicáveis no arquivo de configuração do Terraform usado 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:

   • google_gkeonprem_bare_metal_admin_cluster

   • google_gkeonprem_bare_metal_cluster

   • google_gkeonprem_bare_metal_node_pool

2. 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 em GDCV para Bare Metal: 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ó:

1. (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.

2. Edite o arquivo de configuração do cluster para excluir a entrada do endereço IP do nó.

3. 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 especificados. 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.

1. (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.

2. 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
   

3. 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 abaixo está truncado para facilitar a leitura:

   annotations:
     ...
     baremetal.cluster.gke.io/version: 1.16
   ...
   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.

4. 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 especificados. 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
   

   Você pode executar 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 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:

1. Remova o endereço IP do nó do arquivo de configuração do cluster.
2. Atualize o cluster.
3. Verifique o status dos nós no cluster.
4. Adicione o endereço IP de um novo nó ao mesmo arquivo de configuração do cluster.
5. 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:

1. 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
   

2. 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.

3. 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.

4. 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
   

5. 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:

1. 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

2. Verifique o status da remoção do nó no cluster executando gcloud container bare-metal operations describe OPERATION_ID.

3. 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.

1. 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.16      abm-admin-cluster1   RUNNING
   abm-user-cluster1b   europe-west1  1.16      abm-admin-cluster1   RUNNING
   

2. 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.

3. 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
   

   Você pode executar o comando de novo de vez em quando para verificar o status.

4. 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
...

Seja qual for a ferramenta usada para atualizar um pool de nós, é possível receber 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 GKE em Bare Metal 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) não atribuirá endereços IP que terminam em .0 ou .255 para 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 GKE em Bare Metal 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 os endereços IP desse pool aos Serviços, defina-o 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 GKE em Bare Metal 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:

1. 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"
   

2. 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:
        - [e-mail]
        - [e-mail]
        - [e-mail]

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=[e-mail] \
    --admin-users=[e-mail]
    --admin-users=[e-mail]

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

Você pode especificar um nome de usuário não raiz que queira usar para acesso com o recurso SUDO sem senha às máquinas de nós do 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 especificado e com a chave SSH.

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

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 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.

Observação: o comando gcloud container bare-metal clusters update não permite a configuração desses recursos personalizados.

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, na sigla em inglês) 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 ajudar a tornar as atualizações sincronizadas mais fáceis e persistentes, o GKE em Bare Metal permite especificar algumas configurações do kubelet para cada um dos pools de nós do cluster: nós do plano de controle, do balanceador de carga e 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:

Aviso: definir registryBurst ou registryPullQPS como um valor negativo resulta em falhas do job de atualização para a configuração do kubelet. Para corrigir o problema, atualize esses campos para valores positivos ou remova-os da especificação. Se o job de atualização não for concluído por muito tempo, ele poderá preencher o espaço em disco da máquina com arquivos de backup de configuração do kubelet. Esses arquivos de backup podem ser encontrados em /var/lib/kubelet/config.yaml.bkup.*. Se esses arquivos de backup estiverem ocupando muito espaço em disco, será possível removê-los.

• 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:

• Nós do plano de controle

  • --control-plane-registry-burst
  • --control-plane-registry-pull-qps
  • --disable-control-plane-serialize-image-pulls
  • --enable-control-plane-serialize-image-pulls

• Nós do balanceador de carga

  • --bgp-load-balancer-registry-burst
  • --bgp-load-balancer-registry-pull-qps
  • --disable-bgp-load-balancer-serialize-image-pulls
  • --enable-bgp-load-balancer-serialize-image-pulls
  • --metal-lb-load-balancer-registry-burst
  • --metal-lb-load-balancer-registry-pull-qps
  • --disable-metal-lb-load-balancer-serialize-image-pull
  • --enable-metal-lb-load-balancer-serialize-image-pulls

• Nós de trabalho

  • --registry-burst
  • --registry-pull-qps
  • --disable-serialize-image-pulls
  • --enable-serialize-image-pulls

Aviso: definir as flags *-registryburst ou *-registry-pull-qps como um valor negativo resulta em falhas no job de atualização para a configuração do kubelet. Para corrigir o problema, atualize esses campos com valores positivos. Se o job de atualização falhar por muito tempo, ele poderá preencher o espaço em disco da máquina com arquivos de backup de configuração do kubelet. Esses arquivos de backup podem ser encontrados em /var/lib/kubelet/config.yaml.bkup.*. Se esses arquivos de backup estiverem ocupando muito espaço em disco, é possível removê-los.

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ó. Pulls de imagem atrasados podem bloquear o processo de upgrade, especialmente quando novas imagens do GKE em bare metal 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.

Documentação de referência

bmctl

• Referência do comando bmctl

• Referência de campo de configuração do cluster

CLI da gcloud

• gcloud container bare-metal clusters

• gcloud container bare-metal node-pools

• gcloud container bare-metal admin-clusters

Terraform

• google_gkeonprem_bare_metal_cluster

• google_gkeonprem_bare_metal_node_pool

• google_gkeonprem_bare_metal_admin_cluster