Atualizar seu cluster GKE pode travar em obstáculos inesperados. Este post investiga um caso real em que uma atualização aparentemente simples para a versão 1.27 foi bloqueada por uma "chamada de API descontinuada".
O GKE pausa as atualizações automáticas
Se o GKE detectar o uso de um recurso ou de uma API descontinuada, ele pausa as atualizações automáticas para evitar que seu cluster seja levado a um estado quebrado. As atualizações para a próxima versão minor do Kubernetes ficam pausadas, mas o GKE continua entregando atualizações de patch ao cluster na versão minor atual.
Quando o GKE deixa de detectar o uso do recurso descontinuado ou chamadas a APIs descontinuadas por 30 dias, o cluster é atualizado automaticamente, desde que a próxima versão minor seja a versão padrão no release channel do cluster.
Se o GKE seguir detectando o uso do recurso descontinuado, o cluster permanece na versão minor atual até a data de end of life daquela versão. Quando essa data — disponível no Release Schedule — chega, o cluster é atualizado automaticamente para a próxima versão minor, e o ambiente pode ser comprometido caso o recurso removido ainda esteja em uso.
Atualização do GKE bloqueada
Neste caso, o GKE apontou uma chamada a uma API descontinuada como motivo para impedir a atualização a partir da versão 1.26. Mesmo vasculhando o cluster, não havia rastro do culpado — um "horizontalPodAutoscaler" usando uma API descontinuada.
Passos da investigação
GKE Insights: embora o GKE Insights tenha revelado a chamada à API descontinuada (
horizontalPodAutoscalerv2beta2) e um user agent ("v2.3.0"), esse user agent não trouxe nenhuma informação útilAPI descontinuada: consultando a lista de APIs descontinuadas da 1.27, dá para ver que o HPA v2beta2 não estará disponível em clusters rodando Kubernetes 1.26
Logs de auditoria de atividade administrativa: a primeira forma recomendada de investigar é localizar clientes de API que fazem chamadas de escrita à API descontinuada usando a query de log abaixo. A role roles/logging.viewer é necessária para executá-la.
resource.type="k8s_cluster"
labels."k8s.io/removed-release"="1.26"
protoPayload.authenticationInfo.principalEmail:("system:serviceaccount" OR "@")
protoPayload.authenticationInfo.principalEmail!~("system:serviceaccount:kube-system:")
- Logs de auditoria de acesso a dados : o próximo passo é localizar os clientes de API que fazem chamadas de leitura a APIs descontinuadas. Antes, é preciso habilitar Kubernetes data read e Admin read. Talvez você também precise da role roles/logging.privateLogViewer para enxergar os logs.
O culpado revelado
Depois de esperar os logs serem populados, o culpado apareceu: uma versão desatualizada (2.3.0) do kube-state-metrics! O kube-state-metrics, um serviço de monitoramento para objetos Kubernetes, estava fazendo chamadas "list" à API descontinuada v2beta2, disparando o bloqueio da atualização. Esse caso deixa claro o quanto os ambientes de nuvem são interconectados.
Olhando o código-fonte, dá para identificar exatamente de onde veio a chamada.
A solução
Atualizar o kube-state-metrics para uma versão que não usa a API descontinuada resolveu o problema e abriu caminho para uma atualização tranquila do GKE.
Conclusão
- Filtro de exclusão do bucket de logging: confira o filtro de exclusão do bucket de logging para garantir que os logs de auditoria de acesso a dados não estejam sendo descartados — isso agiliza a investigação.
- Fique de olho nas mudanças de API: acompanhe proativamente as mudanças nas APIs do Kubernetes para antecipar possíveis bloqueios de atualização.
- Entenda versões estáticas vs. release channels: avalie os trade-offs entre versões estáticas (estabilidade) e release channels (correções automáticas de segurança) na sua estratégia de atualização.
- Gerencie as atualizações com estratégia: use o auto-upgrade e as exclusões de manutenção para controlar o momento das atualizações, e considere permitir atualizações de patch para correções críticas de segurança.
- Atenção aos custos de logs: habilitar logs de auditoria de acesso a dados pode gerar custos adicionais. Avalie a real necessidade antes de mantê-los ligados por longos períodos.
Com essas dicas em mãos, você encara as atualizações do GKE com mais segurança e reduz o impacto nas suas operações de nuvem
Se você ainda não conhece a DoiT International, vale muito a pena dar uma olhada. Nosso time está pronto para entender o seu contexto e suas necessidades de engenharia em nuvem. Formados exclusivamente por talentos sêniores de engenharia, somos especializados em consultoria avançada de nuvem, design de arquitetura e suporte em debugging. Entre em contato e vamos conversar!
Espero que este post tenha sido útil! Se tiver alguma dúvida, fique à vontade para deixar um comentário abaixo.