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.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.
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 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.
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:
- Ativar escalonamento automático para pools de nós atuais
- Ativar provisionamento automático de nós
- Criar um novo pool de nós
- Escalone um pool de nós atual