O Kubernetes desempenha um papel importante na Microsoft. O sistema de gerenciamento de contêineres é uma peça fundamental das muitas nuvens da empresa, desde Microsoft 365 e Xbox, até Azure, até parceiros como OpenAI que usam o Kubernetes da Microsoft para hospedar seus próprios serviços.
Como resultado, a Microsoft inventou muitas de suas próprias ferramentas de gerenciamento do Kubernetes. Isso inclui Kaito para implantação de cargas de trabalho de inferência de IA e Fleet para gerenciamento em larga escala de clusters Kubernetes. Todas as diversas ferramentas da Microsoft ficam sob seus dois serviços gerenciados do Kubernetes, o Azure Kubernetes Service e o Azure Container Service, permitindo que você implante e orquestre seus aplicativos baseados em contêiner sem a necessidade de construir a estrutura de gerenciamento necessária. Tudo vem de graça, com APIs, portais e interfaces de linha de comando.
Antigamente, teria sido isso. A Microsoft teria usado esses recursos para se diferenciar de seus concorrentes e de suas nuvens Kubernetes. Mas a Microsoft levou a sério o modelo de código aberto, com muitos dos líderes de suas iniciativas Kubernetes vindos de uma experiência de código aberto. Em vez de manter suas ferramentas Kubernetes para si, a Microsoft as lança como projetos de código aberto, onde qualquer pessoa pode usá-las e contribuir com novo código.
Apresentando a plataforma de observabilidade Retina
Uma das ferramentas mais recentes do Azure a se tornar um projeto de código aberto é o Retina, uma ferramenta de observabilidade de rede projetada para ajudá-lo a entender o tráfego de rede em todos os seus clusters, independentemente de como eles estejam configurados ou qual sistema operacional eles usam. Também não há vínculo com a funcionalidade do Azure. Você pode executar o Retina em qualquer instância do Kubernetes, localmente ou no AWS, Azure ou GCP.
No coração do Retina, assim como a ferramenta de segurança Falco, estão os Filtros de Pacotes Berkeley estendidos (eBPF). Eles permitem executar código no kernel do sistema operacional host, fora dos contêineres do aplicativo, para que você possa usar testes eBPF sem afetar significativamente o código que está executando. Não há necessidade de adicionar agentes aos seus contêineres ou adicionar bibliotecas de monitoramento ao seu código, e uma sonda eBPF pode monitorar todos os nós em execução em um host, seja uma VM na nuvem ou um hardware físico local.
A execução de testes Retina no kernel simplifica o monitoramento da rede. Você não precisa saber quais placas de rede estão instaladas no servidor host ou como a instalação do Kubernetes usa uma malha de serviço. Em vez disso, você verá como a pilha de rede do sistema operacional host está lidando com pacotes. Você pode rastrear tipos de pacotes, latência e perda de pacotes, aproveitando os recursos TCP/IP de baixo nível que podem não estar acessíveis em um nível superior.
Ao se concentrar em tornar a rede nativa da nuvem observável, o Retina foi projetado para se adequar a qualquer conjunto de ferramentas de monitoramento e qualquer instalação do Kubernetes. Há suporte para Linux e Windows, o que deve ajudá-lo a monitorar e depurar aplicativos híbridos que combinam serviços Linux e Windows. Como os testes eBPF são códigos, você pode considerá-los como plug-ins personalizáveis, permitindo que o Retina evolua com novos recursos do Kubernetes e ofereça suporte às métricas necessárias para seus requisitos de monitoramento.
Os dados são entregues ao conhecido serviço de registro do Prometheus no nível do nó. Os dados coletados incluem DNS, operações da camada 4 e capturas de pacotes. Como os dados são rotulados, você pode criar um mapa de operações em seu ambiente Kubernetes, ajudando a rastrear problemas como um microsserviço de bloqueio enquanto o Retina registra o padrão de fluxos dentro e ao redor de suas instâncias Kubernetes.
Primeiros passos com Retina
Comece clonando o repositório Retina GitHub e, em seguida, use os gráficos Helm incluídos para instalar. Pode ser necessário configurar o Prometheus também para garantir que o Retina esteja registrando dados. Se quiser usar o Retina CLI, você precisa estar executando em um Kubernetes hospedado em Linux. A CLI é executada em kubectl, portanto, será fácil de usar junto com outras ferramentas CLI do Kubernetes. Como alternativa, você pode usar definições de recursos customizados YAML para configurar e executar uma captura de rede.
No Linux, o plugin de captura de rede eBPF é uma versão da ferramenta de código aberto Inspektor Gadget. Foi originalmente desenvolvido pela equipe Kinvolk, agora parte do Azure e ainda focada na engenharia de contêineres. Inspektor Gadget é uma biblioteca de ferramentas Kubernetes eBPF que funciona com aplicativos Kubernetes de qualquer tamanho, desde nós únicos até grandes clusters. Retina usa dispositivos de rastreamento do Inspektor Gadget para observar eventos do sistema de rede.
Observando redes de contêineres
O site Retina fornece instruções detalhadas para trabalhar com a ferramenta. O Retina oferece três modos de operação diferentes: métricas básicas por nó, métricas mais detalhadas de “contexto remoto” com suporte para agregação por pod de origem e destino e uma opção de “contexto local” que permite escolher quais pods monitorar.
É importante observar que você não vê tudo por padrão, pois isso pode ser complicado. Em vez disso, diferentes métricas são habilitadas por diferentes plug-ins. Por exemplo, se você deseja rastrear chamadas DNS, comece habilitando o plugin DNS. Todas as métricas incluem metadados de cluster e instância, para que você possa filtrar e gerar relatórios usando rótulos para identificar nós e pods de destino específicos. As opções de contexto local e remoto adicionam rótulos que rastreiam a origem e o destino.
A configuração do Retina também requer a configuração de um destino Prometheus para os dados, juntamente com um painel Grafana apropriado. A Microsoft fornece exemplos de configurações para ambos no GitHub no repositório Retina. Os padrões exibem dados de rede e DNS para seu cluster. Ter os dados no Prometheus permite usar outras ferramentas para trabalhar com dados Retina, por exemplo, alimentar dados em um mecanismo de política para acionar alertas ou automatizar operações específicas.
Com o Retina instalado e o Prometheus e o Grafana configurados, agora você pode ir além dos padrões, configurando o agente Retina e os plugins via YAML. A configuração de métricas adicionais é feita por meio de definições de recursos personalizados do Kubernetes.
Medindo operações de rede Kubernetes
Retina não é realmente uma ferramenta para monitoramento contínuo em nível de pacote, pois gerará muitos dados em um cluster ocupado, a menos, é claro, que você o use com uma ferramenta baseada em políticas para identificar exceções da operação normal. Na prática, talvez seja melhor usar o Retina para identificar as causas principais dos problemas com um cluster em execução. Talvez os nós não estejam conseguindo se comunicar entre si ou você suspeite que os erros possam ser devidos à latência em uma interação de serviço específica. Aqui você pode acionar a captura de pacotes necessária com um único comando que coleta todos os dados necessários para executar um diagnóstico.
A operação contínua é relatada por meio de métricas que fornecem informações estatísticas sobre os principais problemas da rede. Eles podem ser gerenciados usando o Prometheus para gerar alertas, com painéis Grafana para fornecer uma visão geral do desempenho geral do seu cluster, juntamente com dados de outras ferramentas de observabilidade.
Uma métrica útil oferecida pelo Retina é frequentemente ignorada: latência da API. No entanto, no desenvolvimento nativo da nuvem, muitas vezes você trabalha com APIs de terceiros. Alguns podem ser serviços de plataforma de um provedor de nuvem, enquanto outros podem ser fontes de dados essenciais de linha de negócios, como Salesforce ou SAP Hana. Aqui você pode usar a latência do servidor API da Retina para obter métricas que ajudam a rastrear os tempos de resposta do servidor.
Ter esses dados permite iniciar um processo de diagnóstico com seu provedor de API, ajudando a rastrear a origem de quaisquer latências. Atrasos no acesso à API podem ser um bloqueador significativo em seus aplicativos, portanto, ter esses dados pode ajudá-lo a fornecer um aplicativo mais confiável e responsivo.
Um ecossistema Kubernetes em maturação
A Microsoft disponibilizou uma versão prévia de uma ferramenta de observabilidade baseada em Retina para o Azure Kubernetes Service como o complemento Network Observability. Isso funciona com o Prometheus e o Grafana gerenciados do Azure. Você pode encontrar uma lista de métricas pré-configuradas em sua documentação, mas atualmente ela oferece apenas um subconjunto de recursos do Retina, fornecendo apenas métricas em nível de nó.
Um ponto importante a considerar com o Retina é que ele se baseia na experiência do Azure com o Kubernetes. As métricas capturadas imediatamente são o que a equipe do Azure considera importante, e você está construindo o conhecimento que dá suporte a um dos maiores e mais ativos ambientes Kubernetes do mundo. Se precisar de métricas alternativas, você pode criar seus próprios testes eBPF para Retina, que podem ser compartilhados com a comunidade mais ampla do Kubernetes.
O código aberto requer conhecimento compartilhado para ter sucesso. Ao abrir a base de código, a Microsoft está incentivando os desenvolvedores de Retina a trazerem seu conhecimento para a plataforma, na esperança de que AWS, GCP e outros operadores de Kubernetes em escala compartilhem com o mundo as lições de rede que aprenderam. À medida que o Kubernetes amadurece, ferramentas baseadas em eBPF, como Retina e Falco, se tornarão cada vez mais importantes, fornecendo os dados necessários para fornecer aplicações nativas da nuvem seguras e confiáveis em escala.
