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:

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

  2. 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 nos clusters do GKE em 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ó:

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

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

  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.

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:

  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: 10.200.0.11
     - address: 10.200.0.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. 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.

  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: 10.200.0.11
     - address: 10.200.0.12
     - address: 10.200.0.14

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

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.

Desativar porta somente leitura do Kubelet

A partir da versão 1.15.0, o GKE em Bare Metal desativa por padrão a porta 10255, a porta somente leitura do Kubelet. Todas as cargas de trabalho do cliente configuradas para ler dados dessa porta 10255 não segura do Kubelet precisam migrar para usar a porta 10250 do Kubelet segura.

Somente os clusters criados com a versão 1.15.0 ou posterior têm essa porta desativada por padrão. A porta somente leitura 10255 do Kubelet permanece acessível para clusters criados com uma versão anterior à 1.15.0, mesmo após um upgrade do cluster para a versão 1.15.0 ou mais recente.

Essa alteração foi feita porque o Kubelet vaza informações de baixa confidencialidade na porta 10255, que não é autenticada, incluindo todas as informações de configuração de todos os pods em execução em um nó, o que pode ser valioso para um invasor. Além disso, expõe métricas e informações de status, que podem fornecer insights sensíveis para os negócios.

A desativação da porta somente leitura do Kubelet é recomendada pelo comparativo de mercado CIS do Kubernetes. Para desativar manualmente a porta na versão 1.14, siga as etapas abaixo:

  1. Edite o arquivo de configuração do cluster e adicione a seguinte anotação:

    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"

    O exemplo de arquivo de configuração de cluster a seguir mostra que a anotação foi adicionada:

    [...]
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-my-cluster
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
  name: my-cluster
  namespace: cluster-my-cluster
[...]

  2. Edite o recurso de cluster de validação do webhook do cluster:

    kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration

  3. Desative temporariamente a validação do webhook excluindo a linha com o verbo UPDATE:

    - admissionReviewVersions:
- v1
clientConfig:
  caBundle: …
  service:
    name: lcm-webhook-service
    namespace: kube-system
    path: /validate-baremetal-cluster-gke-io-v1-cluster
    port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: vcluster.kb.io
namespaceSelector: {}
objectSelector: {}
rules:
- apiGroups:
  - baremetal.cluster.gke.io
  apiVersions:
  - v1
  operations:
  - CREATE
  - UPDATE # <- DELETE THIS LINE
  - DELETE
  resources:
  - clusters
  scope: '*'
sideEffects: None
timeoutSeconds: 10

  4. Adicione a anotação ao recurso personalizado do cluster:

    kubectl edit clusters CLUSTER_NAME --kubeconfig KUBECONFIG_PATH

    Faça as mudanças a seguir:

    • Substitua CLUSTER_NAME pelo nome do cluster que você quer atualizar.
    • Substitua KUBECONFIG_PATH pelo caminho do arquivo kubeconfig do cluster.

  5. Adicione a anotação, conforme mostrado no exemplo de recurso personalizado de cluster atualizado abaixo:

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  annotations:
    baremetal.cluster.gke.io/enable-kubelet-read-only-port: "false"
[...]

  6. Salve e feche o recurso personalizado .o cluster.

  7. Para reativar a validação do webhook, adicione o verbo UPDATE novamente ao recurso de cluster de validação do webhook do cluster:

    kubectl edit validatingwebhookconfigurations lcm-validating-webhook-configuration

    No recurso personalizado, adicione o verbo UPDATE novamente na seção operations:

    - admissionReviewVersions:
- v1
clientConfig:
  caBundle: …
  service:
    name: lcm-webhook-service
    namespace: kube-system
    path: /validate-baremetal-cluster-gke-io-v1-cluster
    port: 443
failurePolicy: Fail
matchPolicy: Equivalent
name: vcluster.kb.io
namespaceSelector: {}
objectSelector: {}
rules:
- apiGroups:
  - baremetal.cluster.gke.io
  apiVersions:
  - v1
  operations:
  - CREATE
  - UPDATE # <- ADD THIS LINE BACK
  - DELETE
  resources:
  - clusters
  scope: '*'
sideEffects: None
timeoutSeconds: 10

    Salve e feche o recurso personalizado .o cluster.

Essas alterações são mantidas ao fazer upgrade para a versão 1.15.0 ou posterior.