Hoje o Kubernetes passa por uma fase similar ao que o Javascript passou anos atrás: A cada 5 minutos um componente completamente novo aparece.
E por a importância de dominar os fundamentos mais do que frameworks ou componentes.
Esta semana o cluster AKS de um cliente apresentava problemas: era impossível acessar os logs das aplicações, a visualização do uso de CPU e memória dos PODs estava indisponível, e um componente essencial do Kube-system, conhecido como Konnectivity, estava inoperante. E ele relatou que nenhuma alteração havia sido feita no ambiente nas últimas duas semanas.
Eu, não tinha nenhum conhecimento sobre o Konnectivity. Fui ler as documentações do Kubernetes, descobri que se tratava de um serviço para proteger a comunicação entre o API Server e os Worker Nodes. Nas docs verifiquei que era necessário a criação de um certificado TLS para sua configuração. Do lado do Azure, as documentações informam que este componente é automaticamente implantado no cluster.
Não conheço o Konnectivity, mas dado a descrição do problema, como podemos iniciar o troubleshooting? Levantamos as hipoteses baseado na teoria:
- A ausência de informações sobre CPU e memória indica que o Metric Server não estava conseguindo estabelecer comunicação com o Kubelet (cAdvisor).
- A impossibilidade de acessar os logs dos PODs sinalizava uma falha na comunicação entre o API Server e o Kubelet.
- O Konnectivity depende de um certificado TLS, que possui uma data de expiração.
Com base nessas hipoteses, começamos o troubleshooting:
- Há bloqueios de comunicação?
- Qual versão atual do cluster?
- Análisar o Konnectivity.
De imediato, verificamos que o cluster do cliente estava desatualizado. Isso levantou uma red flag.
Investigação de Bloqueios
O Konnectivity estabelece comunicação com o API Server através da porta 10250. Após verificar o Network Security Group do AKS, confirmamos que não existiam bloqueios nesta porta. Portanto, essa hipótese foi descartada.
Análise da Versão do Cluster
Mesmo sem intervenções diretas, atualizações automáticas podem ocorrer no API Server, especialmente se o cluster estiver desatualizado. Isso pode resultar em um descolamento entre a versão do API Server e as versões dos componentes nos Worker Nodes, tornando-se uma potencial fonte de problemas.
Manter um cluster AKS ou EKS atualizado não é apenas uma prática recomendada; é crucial para evitar incompatibilidades que possam levar a falhas ou a problemas mais sérios. Além disso, vale ressaltar que, diante de um cenário desses, o cloud provider não oferece suporte, complicando ainda mais a resolução do problema.
Já passei por situações complicadas onde o cluster EKS de um cliente simplesmente deixou de funcionar. A AWS só entrou em ação porque o cliente era estratégico, com uma conta que batia os sete dígitos. Mas tem vezes que a ajuda do suporte se resume a "atualiza o cluster aí". E não vai além disso, sem oferecer uma solução de verdade ou ajudar a descobrir onde está o problema.
Konnectivity
Ao nos depararmos com a configuração do Konnectivity, a primeira dúvida que surge é: "O que exatamente devo verificar aqui?"
Aqui na Azure Brasil, temos acesso a diversos clusters em funcionamento, o que nos permite fazer um comparativo. Iniciamos verificando a versão da imagem, que era idêntica à de um cluster que estava operacional. Um detalhe que chamou nossa atenção foi a presença de alguns argumentos na inicialização, relacionados a um certificado TLS. De acordo com a documentação do Kubernetes, é necessário configurar um certificado TLS em determinada etapa.
Considerando que os certificados TLS têm prazo de validade, decidimos investigar a data de validade desse certificado. Havia dois certificados: um do Client e outro do CA. Um deles com vencimento previsto para 2051 e outro já expirado. Comparamos com outro AKS e percebemos que esse era o problema.
> openssl x509 certificado.crt -text
Certificate:
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: Mar 15 12:00:00 2022 GMT
Not After : Mar 25 12:00:00 2023 GMT
Para certificar, verificamos se havia mais problemas similares a esse no Google, revisamos a documentação e esse era de fato o problema.
E para fechar a analise. Uma das documentações sugeria realizar uma "análise de solução de problemas" por meio do painel do Azure. Efetuamos a analise que confirmou: o problema estava realmente no certificado. E a rotação automática não estava habilitada porque o RBAC do cluster não estava ativo.
A solução consistia em rotacionar manualmente as chaves do Cluster, mais info aqui:
az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
az aks rotate-certs -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
Resumo
Não importa quão profundo seja seu conhecimento em Kubernetes, ou quantos componentes você já dedicou horas a fio para implementar. Sempre há um cenário completamente novo, onde há algum componente que você nunca estudou. É nesse momento que aparece a importância de conhecer a teoria. Buscar entender como os conceitos teóricos estão sendo aplicados por esse componente com problema.
Este relato é um "gol de placa", nem sempre somos tão assertivos, mas só foi possível graças a um compromisso de estudo contínuo da teoria: Como é a arquitetura do Kubernetes, o que faz cada componente de um cluster e para que servem.