Na DoiT International, atendemos clientes de todos os portes e, de tempos em tempos, identificamos problemas recorrentes, principalmente entre os clientes de maior escala. Achamos que vale a pena compartilhar um problema recente na atualização do GKE do Google ( Kubernetes gerenciado), caso outras equipes estejam planejando suas atualizações ou enfrentando situações parecidas.
Sintomas
Vale destacar que nem todos os clientes passam por isso, mas estes são os sintomas que observamos:
- após a atualização, o kubectl CLI não consegue interagir com o cluster (API-Server não responde)
- o processo de atualização parece estar "travado" e não é concluído nem após 20 minutos
- aviso de erro no console ou nos logs com mensagem semelhante a " All cluster resources were brought up, but: component "kube-apiserver" from endpoint "gke-XXXXXXXX-XXXXXXX" is unhealthy."
Diagnóstico de risco
Embora não aconteça com todo mundo, os pontos em comum que identificamos são:
- versão do cluster GKE inferior à 1.16
- Cluster zonal (master de zona única para o control plane)
- Workloads "tagarelas", que ficam o tempo todo conversando com o API-Server, como Istio, Flux ou ArgoCD
- Atualizações entre versões como 1.12 -> 1.13, 1.13 -> 1.14, 1.14 -> 1.15, 1.15 -> 1.16 (em geral não acontece em atualizações de patch)
Quem pode ser impactado?
Reforçando: até agora, isso aconteceu com apenas alguns clientes, e a maioria se encaixa nesse perfil — clusters zonais com workloads pesados sobrecarregando o API-Server, fazendo com que ele demorasse demais para passar nos health checks durante a atualização e acabasse em estado "travado". Esperamos que estas informações ajudem você a planejar futuras atualizações de versão ou a resolver problemas em andamento.
Como resolver
Abrir um caso no Google Support para aumentar o timeout do health check
Se você já está enfrentando esse problema, mas seus worker nodes continuam atendendo tráfego (faltando apenas o acesso via kubectl ao control plane), abra um chamado com o Google Support ou com seu parceiro de suporte técnico (tomara que seja a DoiT International) para aumentar o timeout do health check para 3 minutos. Assim, o API-Server ganha mais tempo para se recuperar e evita um ciclo de health checks malsucedidos.
Reduza o tamanho do node pool e a carga sobre o API-Server
Se você puder conviver com uma possível indisponibilidade dos worker nodes, dá para aliviar a pressão sobre o API-Server desativando os workloads "tagarelas" e reduzindo-os por um tempo, ou simplesmente escalando o node pool para 0, deixando a atualização concluir e depois escalando de volta.
Outras causas possíveis
Alguns dos nossos engenheiros já encontraram cenários em que o control plane ficou inacessível por causa de uma race condition envolvendo a tabela netfilter/conntrack do Linux. Isso já foi corrigido, mas versões mais antigas eram suscetíveis ao problema.
Solução de longo prazo
Os engenheiros do Google estão cientes do problema e uma correção está prevista para o próximo mês na versão 1.16 ou superior (atualização manual). Até a publicação deste post, ainda não há link público para o issue tracker.
Atualize seu cluster de zonal para regional
Infelizmente, não existe um "botão mágico" para migrar um cluster de zonal para regional, mas um dos nossos cloud architects escreveu um artigo descrevendo uma abordagem de migração com uma ferramenta open source bastante popular: o Velero.