Kubernetes: expondo informações sobre Pods utilizando a Downward API
Retornar informações sobre instâncias de uma aplicação é uma necessidade extremamente comum, principalmente se levarmos em consideração questões envolvendo o monitoramento e a resolução de eventuais problemas (troubleshooting). Diversas stacks de desenvolvimento oferecem funcionalidades que auxiliam neste sentido, viabilizando o acesso a dados como o identificador de uma instância da aplicação e até o Kernel do sistema operacional em uso.
A título de exemplo e como tenho maior contato com .NET, costumo utilizar com frequência os tipos Environment (namespace System) e RuntimeInformation (namespace System.Runtime.InteropServices). Posso com os mesmos retornar informações como o ID de um Pod (por meio da propriedade MachineName em Environment), assim como a versão do .NET empregada na construção desse projeto (através da propriedade FrameworkDescription em RuntimeInformation). Outras tecnologias como Java, Node, Python, PHP, Ruby e Rust (para citar apenas algumas) certamente contam com funcionalidades semelhantes.
No caso de projetos voltados ao Kubernetes, entretanto, nem sempre todas as informações possíveis poderão ser retornadas via framework ou outra solução oferecida pela linguagem/plataforma de desenvolvimento escolhida. Acabei por me deparar com esta necessidade em .NET ao precisar manipular informações como o node/nó em que se encontrava um Pod, além do namespace ao qual esse elemento estava associado.
Limites envolvendo uso de CPU e memória e que foram configurados no objeto de Deployment também constituem bons exemplos. Aplicações construídas nas mais diversas stacks provavelmente não contarão com recursos nativos para a obtenção de tais informações. Como podemos então superar este tipo de limitação?
Há felizmente uma solução nativa que integra o próprio Kubernetes para simplificar em muito este processo: trata-se do mecanismo conhecido como Downward API.
A Downward API permite que containers que formam um Pod exponham informações sobre eles mesmos e o ambiente nos quais se encontram, com isto podendo acontecer a partir do uso de Environment Variables.
Demonstrei inclusive a utilização da Downward API em uma live recente no Canal .NET, com a gravação estando disponível para ser assistida no YouTube:
Tomei como exemplo um site para contagem de acessos com 2 Pods, sendo que cada um destes se encontrava em um node diferente num cluster baseado no Azure Kubernetes Service (oferta gerenciada de Kubernetes dentro da nuvem Microsoft). Na imagem a seguir podemos observar os 2 nós, 1 namespace (contagem) e os 2 Pods mencionados:
Já a imagem seguinte traz um exemplo de acesso via browser ao primeiro Pod (testes-sitecontagem-5c869576c6–56m4p), que está localizado no node aks-agentpool-79014159-vmss000000:
Ao passo que o próximo print mostra um acesso ao segundo Pod (testes-sitecontagem-5c869576c6-k6b2j), com este situado no nó aks-agentpool-79014159-vmss000001:
E como as informações destacadas em vermelho (node atual e namespace) nessas 2 últimas imagens foram obtidas?
Na listagem a seguir temos o código YAML com as configurações de Deployment para esta aplicação:
- As configurações correspondentes ao nó e ao namespace foram atreladas às variáveis de ambiente Kubernetes__Node (a partir da linha 21) e Kubernetes__Namespace (a partir da linha 25);
- Para referenciar a Downward API nesses 2 casos foram utilizados os atributos valueFrom > fieldRef > fieldPath;
- A configuração spec.nodeName em fieldPath associa o valor do node em que se encontra um Pod à Environment Variable correspondente (Kubernetes__Node neste exemplo);
- Já metadata.namespace vincula à variável de ambiente de destino (agora Kubernetes__Namespace) o namespace em que o Pod/Deployment está situado.
A Downward API disponibiliza diversas outras definições como:
- metadata.name, o nome do Pod;
- limits.memory, o limite de memória para um container;
- limits.cpu, o limite de CPU para um container.
Este código que faz uso da Downward API, bem como a aplicação (criada com .NET 7 + ASP.NET Core + Razor Pages) empregada nesses testes, foram disponibilizados em 2 repositórios no GitHub:
Caso achem útil esta solução, peço por favor um ⭐️ nos repositórios apoiando. Fica também o convite para que vocês me sigam lá no GitHub!
Os valores da Downward API que foram vinculados a Kubernetes__Node e Kubernetes__Namespace irão substituir os itens de configuração Kubernetes:Node e Kubernetes:Namespace, que foram definidos no arquivo appsettings.json da aplicação:
