Resolver problemas com upgrades

Nesta página, mostramos como resolver problemas com upgrades de cluster do Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Problema: kube-apiserver não íntegro após o upgrade do plano de controle

O problema a seguir ocorre quando você inicia um upgrade manual do plano de controle da versão do GKE do cluster. Alguns webhooks de admissão implantados pelo usuário podem impedir que os componentes do sistema criem papéis permissivos do RBAC necessários para funcionar corretamente. Durante um upgrade do plano de controle,o Google Cloud recria o componente do servidor da API Kubernetes (kube-apiserver). Se um webhook bloquear o papel RBAC do componente do servidor da API, o servidor da API não será iniciado e o upgrade do cluster não será concluído.

Mesmo que um webhook esteja funcionando corretamente, ele pode causar falhas no upgrade do cluster, porque pode ser inacessível no plano de controle recém-criado.

A mensagem de erro na CLI gcloud é semelhante a esta:

FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.

Para identificar o webhook com falha, verifique se há chamadas de RBAC nos registros de auditoria do GKE com as seguintes informações:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

RBAC_RULE é o nome completo de um papel do RBAC, como rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

O nome do webhook com falha é exibido no registro com o seguinte formato:

admission webhook WEBHOOK_NAME denied the request

Para resolver esse problema, tente o seguinte:

  • Ajuste suas restrições para permitir a criação e a atualização de ClusterRoles que tenham o prefixo system:.
  • Ajuste o webhook para não interceptar solicitações de criação e atualização de papéis do RBAC do sistema.
  • Desative o webhook.

Por que isso acontece?

O Kubernetes reconhece automaticamente{track-name="k8sLink" track-type="troubleshooting"} os papéis do RBAC do sistema padrão com as políticas padrão na versão secundária mais recente. As políticas padrão para papéis do sistema às vezes são alteradas em novas versões do Kubernetes.

Para realizar essa reconciliação, o GKE cria ou atualiza os ClusterRoles e ClusterRoleBindings no cluster. Se você tiver um webhook que intercepte e rejeite as solicitações de criação ou atualização em função do escopo das permissões usadas pelas políticas do RBAC padrão, o servidor de API não poderá funcionar na nova versão secundária.

Problema: cargas de trabalho removidas após o upgrade do cluster padrão

As cargas de trabalho correrão o risco de serem removidas após um upgrade de cluster se as seguintes condições forem verdadeiras:

  • As cargas de trabalho do sistema exigem mais espaço quando o plano de controle do cluster está executando a nova versão do GKE.
  • Seus nós atuais não têm recursos suficientes para executar as novas cargas de trabalho do sistema e as cargas de trabalho atuais.
  • O autoescalador está desativado para o cluster.

Para resolver esse problema, tente o seguinte:

Problema: a versão do nó não é compatível com a versão do plano de controle

Verifique qual versão do Kubernetes o plano de controle do cluster está executando e verifique qual versão do Kubernetes os pools de nós do cluster estão executando. Se algum dos pools de nós do cluster tiver mais de duas versões secundárias mais antigas que o plano de controle, isso pode causar problemas com o cluster.

Periodicamente, a equipe do GKE realiza upgrades do plano de controle do cluster em seu nome. Os planos de controle são atualizados para versões estáveis mais recentes do Kubernetes. Por padrão, os nós de um cluster têm o upgrade automático ativado. Não é recomendável desativá-lo.

Se o upgrade automático estiver desativado para os nós de um cluster e você não fizer o upgrade manual da versão do pool de nós para uma versão compatível com o plano de controle, seu plano de controle vai se tornar incompatível com os nós, já que o plano de controle é atualizado automaticamente ao longo do tempo. A incompatibilidade entre o plano de controle do cluster e os nós pode causar problemas inesperados.

A versão do Kubernetes e a política de suporte de diferença de versão estabelecem que os planos de controle são compatíveis com nós de até duas versões secundárias mais antigas que o plano de controle. Por exemplo, os planos de controle do Kubernetes 1.19 são compatíveis com os nós do Kubernetes 1.19, 1.18 e 1.17. Para resolver esse problema, faça upgrade manual da versão do pool de nós para uma que seja compatível com o plano de controle.

Se você acha que o processo de upgrade está causando a interrupção das cargas de trabalho em execução nos nós afetados, siga as etapas abaixo para migrar as cargas de trabalho para um novo pool de nós:

  1. Crie um novo pool de nós com uma versão compatível.
  2. Demarque os nós do pool de nós existente.
  3. Opcional: atualize as cargas de trabalho em execução no pool de nós atual para adicionar um nodeSelector para o rótulo cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME, em que NEW_NODE_POOL_NAME é o nome do novo pool de nós. Isso garante que o GKE coloque essas cargas de trabalho em nós no novo pool de nós.
  4. Esvazie o pool de nós atual.
  5. Verifique se as cargas de trabalho estão sendo executadas corretamente no novo pool de nós. Se estiverem, exclua o antigo pool de nós. Se você notar interrupções de carga de trabalho, reprograme as cargas de trabalho nos nós atuais removendo a restrição dos nós no pool de nós atual e drenando os novos nós. Resolva o problema e tente novamente.

Problema: pods travados no estado pendente após a configuração do Node Allocatable

Depois de configurar o Node Allocatable e realizar um upgrade da versão do nó, os pods que estavam em execução mudaram para "pendente".

Se os pods estiverem pendentes após um upgrade, sugerimos o seguinte:

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.