Controladores de Ingress: novo nome, função conhecida

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

Coloquialismos. São aquelas palavras e expressões que têm um significado exclusivamente local e podem confundir quem não é da região. Por exemplo, quando estou na rua e com sede, procuro um bebedouro — ou melhor, um “bubbler”. Você provavelmente (supondo que não seja de Wisconsin) procura um “water fountain”. Em Wisconsin, medimos as distâncias pelo tempo, não por milhas. Os semáforos são chamados de luzes de “parar e seguir”. Afinal, é isso que você faz.

A expressão favorita do meu marido (ele não é daqui) para tirar sarro é “C’mere once”. Não vou tentar explicar, além de dizer que ela faz sentido para mim e para as crianças com quem a uso. E entendemos instintivamente que “Up North” não é uma direção, mas um lugar cuja localização pode variar de acordo com quem fala, embora tenha uma conotação comum a todos os naturais de Wisconsin: “aquele lugar para onde vamos para fugir de tudo”.

Você provavelmente tem sua própria lista, já que cresceu em outro lugar. Mas este blog é meu, então posso usar a minha.

No entanto, o objetivo de hoje não é dar uma aula de semântica propriamente dita, mas falar sobre sua aplicabilidade a um fenômeno mais localizado, bem no seu próprio quintal. Isto é, se o seu quintal fosse a sua organização.

A ascensão dos contêineres e de seus indispensáveis sistemas automatizados de controle de clusters (frequentemente chamados de orquestração) teve a consequência não intencional de levar expressões coloquiais de um lado para o outro da divisa. A propósito, estamos falando da passagem do desenvolvimento de aplicativos para a área de TI propriamente dita.

O curioso caso dos coloquialismos de contêineres

Muitas das funções necessárias para alcançar a flexibilidade e a confiabilidade exigidas em escala levaram à migração de determinados serviços, antes restritos à produção, para o “ambiente” de contêineres. Agora, essas funções estão, aparentemente, “incorporadas” a esse ambiente e usam integrações leves (APIs e filas de mensagens) para oferecer o que, até então, só era possível em um ambiente de computação em nuvem totalmente implementado: escalabilidade automática e aplicações de alta disponibilidade.

Dessa forma, as funções de balanceamento de carga são nativas dos pods/nós por meio de pequenos serviços semelhantes a daemons. Embora não sejam muito avançadas (estamos falando de recursos pouco superiores aos do balanceamento de carga de rede), elas cumprem a função para a qual foram projetadas. Esses serviços podem ser (e são) conectáveis, por assim dizer, permitindo o uso de outros projetos (de código aberto e fornecidos por fabricantes) que oferecem recursos mais avançados (e, espera-se, algoritmos melhores).

Mas, por si só, essas funções de balanceamento de carga não oferecem a escalabilidade e a alta disponibilidade que buscamos (e das quais precisamos em ambientes de produção). Elas também não são capazes de rotear APIs — o que exige recursos inteligentes de HTTP (L7). Precisamos disso para escalar horizontalmente, com eficiência, aplicações modernas baseadas em microsserviços e expostas por fachadas de API. Precisamos de uma solução mais robusta.

É aí que entram os controladores de ingresso . Esses são os “balanceadores de carga” que analisam e direcionam o tráfego de entrada com base em URIs e cabeçalhos HTTP, permitindo o roteamento na camada de aplicação e a escalabilidade.

O que aconteceu foi que os desenvolvedores que criaram (e posteriormente passaram a usar) controladores de ingresso basicamente recriaram o que nós, da área de operações de rede, chamaríamos de gerenciamento de tráfego, entrega de aplicações ou comutação/roteamento de conteúdo. Ao longo dos anos, usamos muitos termos diferentes em operações de rede, assim como o pessoal de desenvolvimento e operações. Roteamento de aplicações e roteamento de páginas também são termos usados pelos desenvolvedores para descrever o roteamento de camada 7. O conceito é conhecido por ambos os grupos. Mas os termos — os coloquialismos — não.

Um controlador de entrada é responsável por encaminhar as solicitações ao serviço (virtual) apropriado dentro do cluster de contêineres. Esse serviço pode ser outro proxy de balanceamento de carga ou uma estrutura específica do sistema de contêineres. Em ambos os casos, a função do controlador de entrada é encaminhar o tráfego com base em valores da camada 7 (HTTP) presentes nos cabeçalhos de uma solicitação HTTP. Geralmente, esse valor é o URI, mas também pode ser o nome do host ou algum outro valor personalizado (como um número de versão ou uma chave de API).

Depois que o controlador de entrada extrai o valor do cabeçalho, ele usa as políticas descritas nos arquivos de recursos para determinar como distribuí-lo. Ele pode distribuí-lo igualmente ou enviar 75% para uma versão do serviço e 25% para outra. Nesse sentido, ele é bastante flexível. O controlador de entrada também é responsável pelo monitoramento (integridade e status) e precisa ter muito cuidado para não encaminhar uma solicitação a um serviço “inativo”.

Parece familiar, pessoal de netops? Deveria, porque essas são basicamente as funções de um proxy inteligente (com suporte à camada 7, ou L7), como o BIG-IP.

Agora que você sabe em que eles são semelhantes, posso garantir que existem algumas diferenças. Em especial, um controlador de entrada é configurado de forma declarativa. Ou seja, sua configuração é determinada por uma descrição em um arquivo de recursos externo ao próprio controlador. Isso difere dos proxies inteligentes tradicionais que controlam e direcionam o tráfego de entrada. Os proxies inteligentes tradicionais são fontes autoritativas do ambiente. Um controlador de entrada não é. Ele busca essas informações em outro lugar, em arquivos que funcionam como uma espécie de “camada de abstração” e permitem flexibilidade nas implementações. Isso significa que ele (ou um componente complementar) precisa ler e interpretar esses arquivos e criar a configuração adequada à descrição. Além disso, precisa mantê-la atualizada. Embora a variabilidade no controle de entrada de um ambiente conteinerizado seja menor do que nas camadas mais internas do sistema, ela ainda muda e precisa ser monitorada.

No fim das contas, o controlador de entrada é responsável pelo roteamento, na camada de aplicação, das solicitações externas para o recurso apropriado dentro do ambiente conteinerizado. O que é praticamente a definição de um balanceador de carga inteligente.

O nome pode ter mudado, mas as funções continuam praticamente as mesmas.

Sobre o autor

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