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 da configuração MachineDeployment do cluster. É possível corrigir a configuração da linha de comando usando kubectl patch.

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

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 usar IPs estáticos, verifique se você alocou endereços IP suficientes no cluster:

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

em que:

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

Na saída do comando, procure o campo reservedAddresses. É preciso haver mais endereços IP no campo do que nós em execução no cluster de usuário.

Se você precisar adicionar mais endereços ao campo reservedAddresses, siga estas etapas:

  1. Abra o recurso de cluster do cluster de usuário para edição:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME]

    A configuração do cluster é aberta no editor padrão do shell.

  2. Adicione quantos blocos de IP estáticos forem necessários. Um bloco de IP é composto pelos campos gateway, hostname, ip e netmask.

Abaixo está um campo reservedAddresses de exemplo com os quatro blocos de IP estáticos destacados:

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Antes de começar

Exporte uma variável de ambiente KUBECONFIG que aponte para o kubeconfig do cluster de usuário que você quer redimensionar:

export KUBECONFIG=[USER_CLUSTER_KUBECONFIG]

Como redimensionar um cluster de usuário

Para redimensionar um cluster, edite o recurso MachineDeployment do cluster de usuário. Para encontrar o nome do recurso MachineDeployment do cluster de usuários, execute o seguinte comando:

kubectl get machinedeployments

O MachineDeployment do cluster de usuário inclui o nome do cluster.

Para redimensionar o cluster de usuário, você precisa corrigir a configuração do MachineDeployment do cluster. É possível alterar o valor do campo replicas da configuração, que indica quantos nós o cluster precisa executar:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p "{\"spec\": {\"replicas\": [INT] }}" --type=merge

em que [INT] é o número de nós que você quer que o cluster de usuário execute.

Verificar o redimensionamento

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

kubectl get nodes
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME] | grep Replicas

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.

Novos nós criados, mas não íntegros

Sintomas

Novos nós não se registram no plano de controle do cluster de usuário ao usar o modo de balanceamento de carga manual.

Causas possíveis

A validação da entrada no nó pode estar ativada para bloquear o processo de inicialização dos nós.

Resolução

Para desativar a validação, execute:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

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 geração 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 detalhamento -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 registro 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