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 verificará
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:
Abra o arquivo hostconfig do cluster de usuário para edição:
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
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.
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
egateway
.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
[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:
Verifique o status de MachineDeployment do cluster para ver se há eventos ou mensagens de erro:
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
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
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 arquivologs/gkectl-$(date).log
no diretório local em que você executagkectl
. -
Para
gkeadm
, o arquivo de registros padrão élogs/gkeadm-$(date).log
no diretório local em que você executagkeadm
.
-
Para
- 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:
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
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
Falha no comando de atualização
Ao executargkectl update
para atualizar um cluster, talvez você veja a seguinte mensagem de erro:
Failed to update the cluster: failed to begin updating user cluster "CLUSTER_NAME": timed out waiting for the condition
kubectl get --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] onpremusercluster
cluster [CLUSTER_NAME] is READY=true