Como os ambientes de orquestração de contêineres afetam o monitoramento da integridade

Ecossistema F5 | 16 de outubro de 2017

O monitoramento é a base da disponibilidade. Antes de escolher um recurso de destino, todo balanceador de carga precisa saber se esse recurso está realmente disponível. Caso contrário, qual seria o sentido?

Em ambientes em que a vida útil dos recursos pode ser medida em minutos, em vez de horas ou dias, torna-se ainda mais importante saber o status dos recursos antes de decidir enviar uma solicitação a eles.

O monitoramento da integridade é parte essencial dos balanceadores de carga e proxies. Isso também se aplica (ou deveria se aplicar) a ambientes conteinerizados. À medida que esses ambientes continuam a amadurecer (rapidamente), vemos surgir novos modelos de monitoramento para enfrentar os desafios bastante peculiares associados a sistemas distribuídos tão voláteis.

integridade-do-proxy-de-encaminhamento

O monitoramento tradicional da integridade certamente faz parte da equação, mas alguns modelos de disponibilidade e escalabilidade em ambientes de contêineres impõem desafios ao monitoramento tradicional da integridade que precisam ser enfrentados. Por exemplo, espera-se que os proxies implantados em um modelo de proxy de encaminhamento sejam capazes de selecionar um destino íntegro (disponível) entre todos os serviços possíveis. Enquanto um proxy reverso (um balanceador de carga tradicional, por assim dizer) é responsável apenas por acompanhar o estado de um conjunto bastante específico de serviços de uma única aplicação, um proxy de encaminhamento precisa conhecer o estado de todos os serviços de todas as aplicações no ambiente. Afinal, enviar uma solicitação para um contêiner que já está fora de serviço seria ruim, né?

Monitoramento tradicional da integridade

Tradicionalmente, o monitoramento de integridade é realizado por um proxy de duas maneiras:

  • Monitoramento ativo: Envio de sondagens ou solicitações de verificação de integridade aos contêineres e avaliação das respostas.
  • Monitoramento passivo: Observação das solicitações naturais dos clientes e de suas respostas.

Como você pode imaginar, o monitoramento ativo de cada serviço por todos os proxies de encaminhamento aumentará consideravelmente o tráfego na rede local e consumirá recursos desnecessariamente. Para ser útil, o monitoramento deve ocorrer, no mínimo, na camada TCP e, idealmente, na camada HTTP. Afinal, a conectividade de rede não indica a integridade nem a disponibilidade do serviço. O consumo de conexões TCP e a necessidade de processamento HTTP sobrecarregarão rapidamente os contêineres à medida que o número de nós (e, consequentemente, de proxies de encaminhamento) aumentar. Você não vai querer ter que escalar a infraestrutura porque os contêineres estão sobrecarregados pelo monitoramento.

O monitoramento passivo é uma opção melhor nesse caso, pois não sobrecarrega o sistema monitorado, mas apresenta limitações em alguns ambientes de contêineres. Muitos deles são baseados em princípios de redes sobrepostas, o que dificulta garantir que cada proxy consiga visualizar e acompanhar todas as respostas dos serviços. Não é impossível, mas é um desafio na camada de rede.

Ambos os modelos também sobrecarregam o próprio proxy, exigindo que recursos sejam dedicados apenas ao monitoramento do ambiente, em vez de à tarefa para a qual foram implementados: escalar serviços.

Monitoramento de integridade em contêineres

Os ambientes de contêineres não estão alheios a esses desafios. Em resposta, estamos vendo surgir dois novos modelos que certamente ajudarão a garantir a disponibilidade em arquiteturas que utilizam proxies de encaminhamento para proporcionar disponibilidade e escalabilidade.

Esses dois modelos são:

  • Monitoramento ambiental: Os proxies têm conhecimento do estado de integridade e da disponibilidade graças às informações fornecidas pelo Ambiente de Orquestração de Contêineres (COE) sobre a integridade dos contêineres.
  • Monitoramento compartilhado: Como provavelmente haverá muitos proxies em um ambiente, o trabalho de monitoramento pode ser dividido entre eles, e os resultados podem ser compartilhados.

O monitoramento do ambiente costuma estar associado ao registro de serviços, que acompanha os contêineres à medida que entram e saem do sistema. Isso significa que ele geralmente é a fonte mais confiável de informações sobre a disponibilidade de contêineres no sistema. Os proxies também podem assinar eventos acionados pela criação e destruição de contêineres para acompanhar esses recursos por conta própria (na prática, atuando eles mesmos como um registro).

Por exemplo, se o monitoramento de integridade estiver habilitado para um aplicativo no Marathon, um proxy poderá usar o campo 'healthCheckResults'. No Kubernetes, os proxies podem usar verificações de atividade e/ou prontidão. As verificações de integridade do ambiente permitem que os proxies comecem a selecionar endpoints mais íntegros antes que o sistema de orquestração reinicie um endpoint com problemas.

O monitoramento compartilhado faz muito sentido em sistemas que empregam modelos de proxy de encaminhamento, especialmente aqueles baseados em uma malha de serviços como o Istio. O proxy associado ao nó certamente pode monitorar a integridade e a disponibilidade dos contêineres para os quais encaminha solicitações (de forma muito semelhante à maneira como poderia acompanhar os serviços em um modelo de proxy reverso). No entanto, certamente não é desejável que cada proxy sonde ativamente todos os endpoints de um sistema desse tipo. Assim, ao compartilhar informações locais de integridade com outros proxies (ou, melhor ainda, com o ambiente), todos os proxies podem obter o estado completo conhecido do sistema sem a necessidade de realizar verificações de integridade excessivas em cada serviço.

Muitas mudanças estão ocorrendo na “rede” em relação aos serviços de aplicações, como o balanceamento de carga, e à forma como eles interagem para atender às necessidades e aos requisitos de novos modelos, como a conteinerização. Esses requisitos pressionam constantemente os proxies a se adaptar. Isso acontece porque os proxies são uma das tecnologias mais flexíveis desenvolvidas nos últimos vinte anos e continuam sendo uma base importante sobre a qual os serviços de aplicações são projetados, desenvolvidos e implantados.

Compartilhar
Tags: DevOps, 2017

Sobre o autor

Lori Mac Vittie
Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie

Publicações relacionadas no blog

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros
Ecossistema F5 | 21/10/2026

Entrega e proteção de agentes de IA em fábricas de IA: F5 para a arquitetura de referência NVIDIA OpenShell para agentes de IA seguros

As soluções da F5 ampliam a Arquitetura de Referência NVIDIA OpenShell para agentes de IA seguros.

Como medir – e minimizar – o custo total de propriedade do seu Kubernetes
Ecossistema F5 | 10/12/2020

Como medir – e minimizar – o custo total de propriedade do seu Kubernetes

O Kubernetes pode ser baixado e executado gratuitamente, mas sua manutenção está longe de não ter custos. Assim como outras grandes plataformas de código aberto que são “gratuitas” apenas em um sentido simplista, o Kubernetes quase certamente exigirá investimentos para ser implantado e operado.

As-Code: a pilha de TI contínua
Ecossistema F5 | 08/10/2018

As-Code: a pilha de TI contínua

Infraestrutura, configuração, pipeline, operações. De repente, tudo é “como código”. Lori MacVittie busca esclarecer a terminologia e identificar os diferentes componentes de uma stack contínua de TI.

O estado da entrega de aplicações em 2017: automação, APIs e DevOps
Ecossistema F5 | 17/04/2017

O estado da entrega de aplicações em 2017: automação, APIs e DevOps

Explore o relatório State of Application Delivery de 2017. Leia o blog retrospectivo da F5 sobre o início da ascensão das redes declarativas e dos pipelines de DevOps.

DevOps Summit: onde a rede foi convidada para a festa
Ecossistema F5 | 11/06/2015

DevOps Summit: onde a rede foi convidada para a festa

No DevOps Summit NY, falou-se muito não apenas sobre DevOps, mas também sobre contêineres, IoT e microsserviços. As sessões se concentraram não só na mudança cultural necessária para crescer em escala com uma abordagem DevOps, mas também fizeram questão de incluir...

F5 e Nutanix convergem em infraestrutura no .NEXT
Ecossistema F5 | 08/06/2015

F5 e Nutanix convergem em infraestrutura no .NEXT

Aplicações empresariais como Microsoft SharePoint e Exchange, juntamente com a VDI, continuam sendo a espinha dorsal da sua empresa. A produtividade, embora não seja tão atraente quanto o lucro, é um fator essencial para o sucesso das operações empresariais atuais. Deixar de...