> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # Kubernetes - Mais teoria e menos framework - URL: https://www.azurebrasil.cloud/blog/kubernetes-mais-teoria-e-menos-framework/ - Published: 2024-04-01T16:16:21.000Z - Updated: 2024-04-01T16:16:21.000Z - Author: Bruno Brito 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. ![green ceramic statue of a man](https://images.unsplash.com/photo-1620662831351-9f68f76d0b9a?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDJ8fHRoaW5rZXJ8ZW58MHx8fHwxNzExNjQ3NzE2fDA&ixlib=rb-4.0.3&q=80&w=2000) 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](https://kubernetes.io/docs/tasks/extend-kubernetes/setup-konnectivity/?ref=azurebrasil.cloud), 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](https://learn.microsoft.com/en-us/azure/aks/faq?ref=azurebrasil.cloud#how-does-the-managed-control-plane-communicate-with-my-nodes), 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: 1. 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). 2. A impossibilidade de acessar os logs dos PODs sinalizava uma falha na comunicação entre o API Server e o Kubelet. 3. O Konnectivity depende de um certificado TLS, que possui uma data de expiração. Com base nessas hipoteses, começamos o troubleshooting: 1. Há bloqueios de comunicação? 2. Qual versão atual do cluster? 3. 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. ```bash > 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](https://learn.microsoft.com/en-us/azure/aks/certificate-rotation?ref=azurebrasil.cloud#manually-rotate-your-cluster-certificates): ```bash 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.