À medida que os mundos do DevOps e NetOps colidem e os ambientes de contêineres absorvem definições tradicionalmente usadas na rede, parece prudente explorar o uso do termo "entrada", muitas vezes confuso, em termos de caminho de dados e ambientes de contêiner.
Os termos entrada e saída têm sido usados classicamente para descrever a direção do tráfego na rede da perspectiva do data center. A entrada é de entrada, a saída é de saída.
À medida que os ambientes de contêiner amadureceram, o termo ingress foi aplicado para ter uma definição muito específica e focada na aplicação.
Entrada. Um objeto de API que gerencia o acesso externo aos serviços em um cluster, normalmente HTTP. O Ingress pode fornecer balanceamento de carga, terminação SSL e hospedagem virtual baseada em nome.
É importante fazer uma pausa e observar que um recurso de entrada, conforme definido em um ambiente Kubernetes, descreve recursos que devem ser executados dentro do próprio perímetro do contêiner.
Cada entrada é um proxy reverso que aceita solicitações externas e, com base nas regras especificadas pelo recurso de entrada do Kubernetes, direciona essas solicitações para o serviço correto do Kubernetes. O serviço, por sua vez, equilibra a carga de solicitações em um conjunto de contêineres associados, geralmente por meio de algoritmos de balanceamento de carga nativos da camada 4 (TCP). Essa é uma das maneiras pelas quais uma API unificada é apresentada ao mundo exterior. O ingress analisa as chamadas de API (o caminho do URI) e as distribui para os microsserviços hospedados em contêineres apropriados dentro do cluster de contêineres.
O F5 fornece os mesmos recursos de uma entrada clássica do Kubernetes, mas adiciona recursos adicionais na forma de roteamento SNI e balanceamento de carga da camada 4 (TCP). A capacidade de executar o roteamento SNI (indicador de nome do servidor) é um benefício para aqueles que desejam criptografia TLS de ponta a ponta nas trocas de mensagens, pois permite que o F5 roteie adequadamente as solicitações com base nas informações nos cabeçalhos sem descriptografar a carga/mensagem real. Embora isso restrinja o alcance da funcionalidade que pode ser aplicada à solicitação — por exemplo, ela não pode ser escaneada em busca de conteúdo malicioso —, isso fornece o suporte necessário para arquiteturas nas quais o conteúdo deve permanecer criptografado por razões regulatórias ou operacionais. O balanceamento de carga da Camada 4 (TCP) é frequentemente usado externamente a um ambiente de contêiner para dimensionar serviços de entrada no estilo Kubernetes.
O F5 normalmente é implantado externamente ao ambiente do contêiner. Ele é frequentemente usado como uma solução de balanceamento de carga para expor clusters externamente, ou seja, fornecer acesso público a serviços compostos por um cluster de contêineres. Uma pesquisa da CNCF descobriu que 67% dos entrevistados escolhem uma opção de balanceador de carga para expor serviços de cluster externamente, com outros 33% aproveitando recursos de entrada (L7).
Para que possamos fornecer os mesmos recursos de uma entrada do Kubernetes, um "conector" nativo de contêiner é usado para facilitar as atualizações das políticas que definem as políticas de tráfego. Este conector reside dentro e se integra ao orquestrador de contêineres (normalmente o Kubernetes, mas o Red Hat OpenShift também é popular). A comunicação com o ingress do F5 é realizada via API. As atualizações incluem alterações nas definições de recursos de ingress (políticas de roteamento HTTP), bem como alterações na configuração, como o lançamento ou a remoção de uma instância de contêiner que impacta uma definição de serviço atual.
A vantagem de usar o F5 em vez de serviços de entrada simples é a capacidade de aplicar recursos avançados ao tráfego de entrada e saída. Segurança, enriquecimento de cabeçalho e otimizações de desempenho específicas do cliente podem ser aplicadas ao usar o F5 sem modificar o ambiente ou a arquitetura do contêiner ou o próprio aplicativo.
Recursos adicionais: