Um guia para escolher um controlador Ingress, parte 1: Identifique seus requisitos

Editor – Este post faz parte de uma série de 10 partes:

1. Reduza a complexidade com o Kubernetes de nível de produção
2. Como melhorar a resiliência no Kubernetes com gerenciamento avançado de tráfego
3. Como melhorar a visibilidade no Kubernetes
4. Seis maneiras de proteger o Kubernetes usando ferramentas de gerenciamento de tráfego
5. Um guia para escolher um controlador Ingress, parte 1: Identifique seus requisitos (esta postagem)
6. Um guia para escolher um controlador Ingress, parte 2: Riscos e preparação para o futuro
7. Um guia para escolher um controlador Ingress, parte 3: Código aberto vs. Padrão vs. Comercial
8. Um guia para escolher um controlador Ingress, parte 4: Opções do controlador de entrada NGINX
9. Como escolher uma malha de serviço
10. Teste de desempenho de controladores de entrada NGINX em um ambiente de nuvem Kubernetes dinâmico

Você também pode baixar o conjunto completo de blogs como um e-book gratuito – Levando o Kubernetes do teste à produção .

Quando as organizações começam a experimentar o Kubernetes, elas geralmente não pensam muito na escolha do controlador Ingress . Eles podem pensar que todos os controladores do Ingress são iguais e, para começar a funcionar rapidamente, é mais fácil manter o controlador padrão do Ingress para a estrutura do Kubernetes que eles escolheram. E é verdade que praticamente qualquer controlador Ingress é adequado para testes ou ambientes de produção de baixo volume. Mas à medida que você escala, sua escolha do controlador Ingress se torna mais importante. Isso ocorre porque os controladores do Ingress podem fornecer muito mais do que a funcionalidade básica de mover seu tráfego do ponto A para o ponto B.

Do gerenciamento avançado de tráfego à visibilidade e segurança integrada, um controlador Ingress pode ser uma das ferramentas mais poderosas em sua pilha do Kubernetes. Na verdade, na F5 NGINX consideramos que ele é a base de qualquer implantação do Kubernetes de nível de produção . Mas muitos desenvolvedores e equipes de operações de plataforma não percebem todo o poder de um controlador Ingress — ou as consequências de escolher um que não pode ser dimensionado. Escolher um controlador Ingress que não seja bem dimensionado ou que não proteja ambientes complexos pode impedir que você tire o Kubernetes dos testes e coloque-o em produção. Nesta série de blogs, pretendemos ensinar a você os conceitos básicos dos controladores Ingress e como fazer uma escolha inteligente que ofereça a funcionalidade e a segurança de que você precisa, hoje e amanhã.

O que é um controlador Ingress?

Um controlador Ingress é um balanceador de carga especializado que gerencia o tráfego das camadas 4 e 7 que entra nos clusters do Kubernetes e, potencialmente, o tráfego que sai deles. Para que todos estejamos na mesma página, aqui estão os termos que usamos na NGINX (e eles são basicamente os mesmos em todo o setor):

• Tráfego de entrada – Tráfego que entra em um cluster Kubernetes
• Tráfego de saída – Tráfego que sai de um cluster Kubernetes
• Tráfego norte-sul – Tráfego que entra e sai de um cluster Kubernetes (também chamado de tráfego de entrada e saída )
• Tráfego leste-oeste – Tráfego que se move entre serviços dentro de um cluster Kubernetes (também chamado de tráfego serviço a serviço )
• Service mesh – Uma ferramenta de gerenciamento de tráfego para roteamento e proteção de tráfego de serviço para serviço

Por que você precisa de um controlador Ingress?

Por padrão, os aplicativos executados em pods (contêineres) do Kubernetes não são acessíveis pela rede externa, mas apenas por outros pods dentro do cluster do Kubernetes. O Kubernetes tem um objeto de configuração integrado para balanceamento de carga HTTP, chamado Ingress , que define como entidades fora de um cluster Kubernetes podem se conectar aos pods representados por um ou mais serviços do Kubernetes.

Quando você precisa fornecer acesso externo aos seus serviços do Kubernetes, crie um recurso Ingress para definir as regras de conectividade, incluindo o caminho do URI, o nome do serviço de suporte e outras informações. No entanto, por si só, o recurso Ingress não faz nada. Você deve implantar e configurar um aplicativo controlador do Ingress (usando a API do Kubernetes) para implementar as regras definidas nos recursos do Ingress.

O que um controlador Ingress faz?

• Aceita tráfego de fora do ambiente do Kubernetes, potencialmente o modifica (molda) e o distribui para pods em execução dentro do ambiente. O controlador Ingress substitui o modelo de distribuição de tráfego padrão kube-proxy , fornecendo controles adicionais como aqueles que os controladores de entrega de aplicativos (ADCs) e proxies reversos fornecem em ambientes não Kubernetes.
• Monitora os pods individuais de um serviço, garantindo roteamento inteligente e evitando que as solicitações sejam “ bloqueadas ”.
• Implementa regras de saída para aumentar a segurança com TLS mútuo (mTLS) ou limitar o tráfego de saída de determinados pods para serviços externos específicos.

Quando chega a hora de selecionar um controlador Ingress, pode ser tentador começar com uma lista de recursos, mas você pode acabar com um controlador Ingress que tem recursos fantásticos, mas não satisfaz as necessidades do seu negócio. Em vez disso, certifique-se de explorar dois elementos que impactam o quão bem o controlador Ingress funcionará para sua equipe e seus aplicativos: casos de uso (quais problemas ele resolverá) e recursos (como você vai "pagar" por isso). Abordaremos esses dois tópicos no restante deste blog.

Quais problemas você deseja que o controlador Ingress resolva?

O principal caso de uso de um controlador Ingress é o gerenciamento de tráfego, então você provavelmente deseja que o controlador Ingress lide com um ou mais destes casos de uso comuns:

• Balanceamento de carga (HTTP2, HTTP/HTTPS, terminação SSL/TLS, TCP/UDP, WebSocket, gRPC)
• Controle de tráfego (limitação de taxa, interrupção de circuito, verificações de saúde ativas)
• Divisão de tráfego (roteamento de depuração, testes A/B, implantações canário, implantações azul-verde)

Mas não há razão para se contentar com um “pônei de um truque só” – a maioria dos controladores Ingress pode fazer mais do que gerenciar o tráfego. Ao usar o controlador Ingress para resolver vários problemas, você não apenas reduz o tamanho e a complexidade da sua pilha, mas também pode descarregar requisitos não funcionais dos aplicativos para o controlador Ingress. Vamos analisar quatro casos de uso não tradicionais do controlador Ingress que podem ajudar a tornar suas implantações do Kubernetes mais seguras, ágeis e escaláveis, ao mesmo tempo em que fazem uso mais eficiente de seus recursos.

Monitoramento e visibilidade

A falta de visibilidade no cluster do Kubernetes é um dos maiores desafios em ambientes de produção, contribuindo para dificuldades na solução de problemas e resiliência. Como os controladores Ingress operam na borda dos seus clusters Kubernetes e tocam em cada bit de tráfego, eles estão bem posicionados para fornecer dados que podem ajudar você a solucionar (e até mesmo evitar) dois problemas comuns: aplicativos lentos e exaustão de recursos no cluster ou plataforma Kubernetes. Para que o controlador Ingress melhore a visibilidade, ele precisa:

• Forneça métricas em tempo real para que você possa diagnosticar o que está acontecendo “agora”
• Ser capaz de exportar métricas para ferramentas de visibilidade populares, como Prometheus e Grafana, que plotam valores ao longo do tempo para ajudar a prever picos de tráfego e outras tendências

Gateway de API

A menos que você esteja procurando executar manipulação de solicitação-resposta no Kubernetes, é muito provável que o controlador Ingress possa funcionar também como seu gateway de API. Dependendo do seu conjunto de recursos, um controlador Ingress pode fornecer funções básicas de gateway de API, incluindo terminação TLS, autenticação de cliente, limitação de taxa, controle de acesso detalhado e roteamento de solicitações nas camadas 4 a 7.

Autenticação e Single Sign‑On

Descarregar a autenticação de credenciais de login dos seus serviços do Kubernetes para o seu controlador do Ingress pode resolver dois problemas.

• Permita que os usuários façam login em vários aplicativos com um único conjunto de credenciais implementando o logon único (SSO) com o OpenID Connect (OIDC).
• Elimine a necessidade de criar funcionalidades de autenticação em cada aplicativo, permitindo que seus desenvolvedores se concentrem na lógica de negócios de seus aplicativos.

Integração de firewall de aplicativo da Web

Não é que um controlador Ingress possa servir como um firewall de aplicativo da web (WAF), mas sim que o WAF pode ser consolidado com o controlador Ingress. Embora um WAF possa ser implantado em muitos lugares fora e dentro do Kubernetes, para a maioria das organizações o local mais eficiente e eficaz é no mesmo pod que o controlador Ingress. Este caso de uso é perfeito quando as políticas de segurança estão sob a direção do SecOps ou DevSecOps e quando é necessária uma abordagem detalhada, por serviço ou por URI. Isso significa que você pode usar a API do Kubernetes para definir políticas e associá-las aos serviços. Além disso, a funcionalidade de controle de acesso baseado em função (RBAC) do controlador Ingress pode permitir que o SecOps aplique políticas por ouvinte, enquanto os usuários DevOps definem políticas por recurso Ingress.

Como você vai obter recursos para o controlador Ingress?

Cada controlador Ingress tem um custo... mesmo aqueles que são gratuitos e de código aberto (talvez você já tenha ouvido a frase "grátis como um cachorrinho"). Alguns custos podem ter valores previsíveis atribuídos como itens de linha no seu orçamento, enquanto outros dependem de quanto tempo sua equipe tem para lidar com as consequências do controlador Ingress escolhido (maior complexidade, falta de portabilidade e assim por diante). Vamos analisar os custos – em termos de tempo e dinheiro – a serem considerados ao fazer o orçamento para um controlador Ingress: tempo e dinheiro.

Orçamento para custos de tempo

O orçamento para contagem de funcionários pode ser muito mais desafiador do que para itens de linha de custo fixo, especialmente quando você está tentando obter recursos para um projeto em um espaço desconhecido. Você precisa fazer perguntas como:

• Quem irá configurar e administrar o controlador Ingress? Isso faz parte do trabalho de tempo integral deles (por exemplo, como membros da sua equipe de operações de plataforma) ou eles estão assumindo isso como uma responsabilidade extra (como desenvolvedores)?
• Você pode reservar um tempo para que os funcionários façam treinamento formal? Ou a ferramenta precisa ser simples o suficiente para que você possa aprender rápida e facilmente no trabalho?
• Você está preparado para que os funcionários mexam nele sempre que um novo recurso for necessário ou gastem muito tempo na solução de problemas quando houver um problema? Ou você precisa que eles forneçam outro valor comercial?

Uma nota sobre a propriedade da ferramenta Kubernetes

Observamos uma tendência no setor de consolidar ferramentas e propriedade sob o domínio das equipes de NetOps. Embora isso possa ajudar muito a simplificar sua pilha e melhorar a segurança, defendemos a duplicação cuidadosa de ferramentas com base nas metas da equipe . Faz sentido que a equipe NetOps gerencie ferramentas de perímetro (como balanceadores de carga externos) porque elas se concentram na plataforma mais ampla, mas as equipes de DevOps se preocupam mais com os serviços implantados perto do código do aplicativo e precisam de mais agilidade e controle mais refinado do que obtêm com as ferramentas NetOps. As ferramentas do Kubernetes, incluindo o controlador Ingress, têm mais chances de sucesso quando são selecionadas pelo DevOps. Isso não quer dizer que você deve conceder aos desenvolvedores total liberdade de escolha de ferramentas! Alguma padronização brutal de ferramentas dentro do Kubernetes ainda é uma prática recomendada.

Orçamento para custos de capital

Quando as organizações experimentam o Kubernetes pela primeira vez, geralmente não reservam muito para ferramentas ou suporte. Se você tem recursos humanos para realmente dar suporte a um controlador Ingress que precisa de mais "acompanhamento", então nenhum orçamento monetário é aceitável... a princípio. Mas, à medida que seu investimento no Kubernetes aumenta, você pode se ver limitado pelos recursos da ferramenta ou querer dedicar sua equipe a outras prioridades. É aí que a balança pende para o pagamento de uma ferramenta mais fácil de usar e estável, com recursos e suporte corporativos.

Quando estiver pronto para pagar por um controlador Ingress, esteja ciente de que o modelo de licenciamento é importante. Com base em modelos de preços tradicionais fora do Kubernetes, o preço dos controladores Ingress geralmente é “por instância” ou “por proxy Ingress”. Embora existam casos de uso em que isso ainda faz sentido no Kubernetes, licenciar um controlador Ingress em uma base “por cluster” significa que você paga com base na locação do aplicativo em vez do “número de proxies”.

Aqui estão nossas recomendações para diferentes cenários:

• Novo no Kubernetes? Escolha o licenciamento por cluster.
  Quando você não tem experiência com o Kubernetes, é muito difícil prever com precisão o número de instâncias do controlador Ingress que você precisa. Se você for forçado a escolher várias instâncias, poderá subestimar – dificultando a obtenção de seus objetivos – ou superestimar e desperdiçar dinheiro que seria melhor gasto em outras partes do projeto Kubernetes. Negociar um preço fixo relativamente baixo para um “pequeno cluster” aumenta suas chances de sucesso.
• Escalando o Kubernetes? Escolha o licenciamento por cluster.
  É quase impossível prever quanto e com que frequência você precisará aumentar ou diminuir os recursos do Kubernetes (estourando e colapsando). O preço por instância força sua equipe a impor limites arbitrários para permanecer dentro dos limites de licenciamento. Com o licenciamento por cluster, você não precisa rastrear contêineres Ingress individuais e, dependendo do fornecedor (como NGINX), o bursting pode ser incluído sem custo adicional.
• Implantações avançadas ou estáticas? Escolha o licenciamento por instância.
  Se você é experiente o suficiente com o Kubernetes para saber exatamente como usará o controlador Ingress, planeja usar um pequeno número de proxies Ingress por cluster e não precisa de nenhum serviço agrupado que possa vir junto com a ferramenta, o preço por instância pode ser uma ótima escolha.

Próximos passos: Tolerância ao risco e preparação para o futuro

Agora que você entendeu seus requisitos, o próximo passo é decidir em equipe qual é sua tolerância aos riscos que um controlador Ingress pode apresentar e descobrir como você precisará que o controlador Ingress seja dimensionado à medida que sua implantação do Kubernetes cresce. Abordaremos esses tópicos na Parte 2 .