Versão 1.15. Esta versão não é mais compatível. Para informações sobre como fazer upgrade para a versão 1.16, consulte Fazer upgrade dos clusters na documentação mais recente. Para mais informações sobre as versões compatíveis e não compatíveis, consulte a página Histórico de versões na documentação mais recente.

Atualizar clusters

Depois de criar um cluster com o bmctl, é possível alterar alguns aspectos da configuração com a seguinte sequência de ações:

Altere os valores de determinados campos no arquivo de configuração do cluster, que, por padrão, está localizado aqui: bmctl-workspace/CLUSTER-NAME/CLUSTER-NAME.yaml.
Para atualizar o cluster, execute o comando bmctl update.

Assim, é possível, por exemplo, adicionar ou remover nós ou substituir nós em um cluster. Saiba como fazer isso e outras atualizações em um cluster.

No entanto, é importante observar que muitos aspectos da configuração do cluster são imutáveis e não podem ser atualizados depois da criação. 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 ver a descrição.

Adicionar ou remover nós de um cluster

Um pool de nós é um grupo de nós em 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.

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: como remover um nó de trabalho

Veja 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: 172.18.0.5
  - address: 172.18.0.6

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.

Para monitorar o processo de drenagem de nós de trabalho, visualize 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 cluster -c CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG
```
Substitua:
- CLUSTER_NAME: o nome do cluster que você quer atualizar.
- ADMIN_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
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.

Como forçar a remoção de um nó

Se o comando bmctl update não conseguir remover um nó, talvez seja necessário forçar essa remoção no cluster. Consulte detalhes em Forçar a remoção de nós corrompidos.

Substituir nós do plano de controle de alta disponibilidade

É possível substituir nós do plano de controle de alta disponibilidade (HA) em clusters de administrador, usuário, independente e híbrido.

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.

O restante desta seção mostra um exemplo.

Veja 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: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.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: 10.200.0.11
     - address: 10.200.0.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. Veja 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: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.14
```
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.

Verificar as atualizações

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

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

Recursos que você pode alterar com uma atualização

Além de adicionar, remover ou substituir nós, é possível usar o comando bmctl update para alterar determinados valores de campos mutáveis, recursos personalizados (CRs, na sigla em inglês) e anotações no arquivo de configuração do cluster.

Para atualizar um recurso de cluster, edite o arquivo de configuração do cluster e use bmctl update para aplicar as alterações.

As seções a seguir descrevem alguns exemplos comuns para atualizar um cluster atual alterando um valor de campo, um CR ou uma anotação.

`loadBalancer.addressPools`

A seção addressPools contém campos para especificar pools de balanceamento de carga para balanceadores de carga em pacote. É 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 existentes.

addressPools:
- name: pool1
  addresses:
  - 192.168.1.0-192.168.1.4
  - 192.168.1.240/28
- name: pool2
  addresses:
  - 192.168.1.224/28

Impedir a exclusão acidental de clusters

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:

`bypassPreflightCheck`

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

`loginUser`

Defina o campo loginUser na configuração de acesso do nó. Este campo suporta o recurso sudo sem senha para login na máquina.

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

`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. Para usar o recurso personalizado NetworkGatewayGroup e os recursos de rede relacionados, defina clusterNetwork.advancedNetworking como true ao criar os clusters.

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

`BGPLoadBalancer`

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 o recurso personalizado BGPLoadBalancer (e o recurso personalizado BGPPeer). Para mais informações, consulte Configurar balanceadores de carga em pacote com o BGP.

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

`BGPPeer`

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 o recurso personalizado BGPPeer (e o recurso personalizado BGPLoadBalancer). Para mais informações, consulte Configurar balanceadores de carga em pacote com o BGP.

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

`NetworkAttachmentDefinition`

É possível usar o comando bmctl update para modificar recursos personalizados NetworkAttachmentDefinition que correspondam à rede.

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-network-1
  namespace: cluster-my-cluster
spec:
  config: '{
  "type": "ipvlan",
  "master": "enp2342",
  "mode": "l2",
  "ipam": {
    "type": "whereabouts",
    "range": "172.120.0.0/24"

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.

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

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.

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.

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

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 pull de imagens, defina serializeImagePulls como false para permitir pulls de imagens paralelos.
Se você encontrar erros de limitação de pull de imagem, como pull QPS exceeded, aumente registryPullQPS e registryBurst para aumentar a capacidade de processamento de 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.

Use `bmctl update` para aplicar suas alterações

Depois de modificar o arquivo de configuração, atualize o cluster executando o seguinte comando bmctl update:

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, substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de admin.