Como redimensionar um cluster de usuário

Nesta página, você aprende a redimensionar um cluster de usuário do GKE On-Prem. Redimensionar um cluster de usuário significa adicionar ou remover nós desse cluster. A remoção de nós de um cluster precisa liberar os endereços IP do cluster, disponibilizando-os para uso por outros nós. A adição de nós exige que os endereços IP estejam disponíveis para esses nós.

Para redimensionar um cluster de usuário, altere os campos replicas na seção nodePools do arquivo de configuração e implante essas alterações nesse cluster usando o comando gkectl update cluster.

Para informações sobre limites máximos e mínimos para clusters de usuários, consulte Cotas e limites.

Para mais informações sobre como gerenciar pools de nós com gkectl update cluster, consulte Como criar e gerenciar pools de nós.

Verificar se há endereços IP suficientes disponíveis

Se você estiver adicionando mais nós a um cluster, certifique-se de que ele tenha endereços IP suficientes. Para verificar se você tem endereços IP suficientes, isso dependerá se o cluster usa um servidor DHCP ou IPs estáticos.

DHCP

Se o cluster usar o DHCP, verifique se o servidor DHCP na rede em que os nós são criados tenham endereços IP suficientes. Haverá mais endereços IP do que há nós em execução no cluster de usuário.

IPs estáticos

Se o cluster usa IPs estáticos, executar gkectl update cluster, primeiro, verifica se você alocou endereços IP suficientes nele. Caso contrário, você encontrará na mensagem de erro o número de endereços IP extras necessários para fazer a atualização.

Se precisar adicionar mais endereços IP ao cluster de usuário, siga estas etapas:

  1. Abra o arquivo hostconfig para editar o cluster do usuário.

  2. Para ver os endereços reservados para um cluster de usuário:

    kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] 
    -n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

onde:

  • [ADMIN_CLUSTER_KUBECONFIG] informa ao kubectl para usar o kubeconfig do cluster de administrador, que é usado para visualizar e/ou alterar as configurações do cluster de usuário.
  • -n [USER_CLUSTER_NAME] informa ao kubectl para procurar um namespace com o mesmo nome do cluster de usuário.
  • [USER_CLUSTER_NAME] -o yaml informa ao kubectl em qual cluster de usuário você está executando o comando. -o yaml exibe a configuração do cluster de usuário.
  1. Se algum dos endereços reservados para um cluster de usuário estiver incluído no arquivo hostconfig, adicione-o ao bloco correspondente com base em netmask e gateway.

  2. Adicione quantos endereços IP estáticos adicionais ao bloco correspondente forem necessários, e execute gkectl update cluster.

Veja abaixo um exemplo de arquivo hostconfig com os quatro blocos de IP estáticos destacados:

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
blocks:
- netmask: 255.255.248.0
  gateway: 21.0.135.254
  ips:
    - ip: 21.0.133.41
      hostname: user-node-1
    - ip: 21.0.133.50
      hostname: user-node-2
    - ip: 21.0.133.56
      hostname: user-node-3
    - ip: 21.0.133.47
      hostname: user-node-4

Como redimensionar um cluster de usuário

A partir da versão 1.5.0, é possível redimensionar um cluster alterando os campos replicas na seção nodePools do arquivo de configuração e implantando essas alterações nesse cluster usando o comando gkectl update cluster.

Verificar o redimensionamento

Para verificar se o redimensionamento foi realizado com êxito, execute:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] describe machinedeployments [NODE_POOL_NAME] | grep Replicas

em que [USER_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de usuário. O número de nós que você escolheu precisa ser refletido na saída desses comandos.

Solução de problemas

Para mais informações, consulte Solução de problemas.

Falha no redimensionamento de um cluster de usuário

Sintomas

Falha na operação de redimensionamento em um cluster de usuário.

Causas possíveis

Vários fatores podem causar falhas nas operações de redimensionamento.

Resolução

Se um redimensionamento falhar, siga estas etapas:

  1. Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
  2. Verifique se há erros nas máquinas recém-criadas:

    kubectl describe machine [MACHINE_NAME]

Erro: "nenhum endereço pode ser alocado"

Sintomas

Depois de redimensionar um cluster de usuário, kubectl describe machine [MACHINE_NAME] exibe o seguinte erro:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
   
Causas possíveis

Não há endereços IP suficientes disponíveis para o cluster de usuário.

Resolução

Aloque mais endereços IP para o cluster. Em seguida, exclua a máquina afetada:

kubectl delete machine [MACHINE_NAME]

Se o cluster estiver configurado corretamente, uma máquina de substituição será criada com um endereço IP.

Número suficiente de endereços IP alocados, mas a máquina não é registrada no cluster

Sintomas

A rede tem endereços suficientes alocados, mas ainda assim a máquina não é registrada no cluster de usuário.

Causas possíveis

Pode haver um conflito de IP. O IP pode ser usado por outra máquina ou pelo balanceador de carga.

Resolução

Verifique se o endereço IP da máquina afetada não foi usado. Se houver um conflito, você precisará resolvê-lo no seu ambiente.

Como diagnosticar problemas de cluster usando gkectl

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de registros padrão:

  • Por padrão, as entradas de registro são salvas da seguinte maneira:

    • Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log, no diretório local em que você executa gkectl.
    • Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log, no diretório local em que você executa gkeadm.
  • Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
  • O nível de detalhes -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
  • O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registros que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

  1. Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager