Guia para escolher um controlador de Ingress, parte 1: identifique seus requisitos

Jenn GileDiretor de Marketing de Produto, NGINX

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

1. Reduza a complexidade com Kubernetes pronto para produção
2. Como melhorar a resiliência no Kubernetes com o 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 Ingress Controller, parte 1: identifique seus requisitos (este post)
6. Guia para escolher um controlador de Ingress, Parte 2: riscos e preparação para o futuro
7. Um guia para escolher um controlador de Ingress, parte 3: código aberto vs. padrão vs. comercial
8. Guia para escolher um controlador de Ingress, parte 4: opções de controladores de Ingress da NGINX
9. Como escolher uma malha de serviços
10. Teste de desempenho de controladores de Ingress NGINX em um ambiente de nuvem Kubernetes dinâmico

Você também pode baixar a coleção completa de artigos como um e-book gratuito – Levando o Kubernetes do teste à produção.

Quando as organizações começam a experimentar o Kubernetes, muitas vezes não dão muita atenção à escolha de um controlador Ingress. Elas podem achar que todos os controladores Ingress são iguais e que, para começar a operar rapidamente, é mais fácil manter o controlador Ingress padrão do framework Kubernetes escolhido. E é verdade que praticamente qualquer controlador Ingress funciona bem em ambientes de teste ou de produção com baixo volume. No entanto, à medida que você ganha escala, a escolha do controlador Ingress se torna mais importante. Isso porque os controladores Ingress podem oferecer muito mais do que a funcionalidade básica de encaminhar o tráfego do ponto A ao ponto B.

Do gerenciamento avançado de tráfego à observabilidade e à segurança integrada, um controlador de Ingress pode ser uma das ferramentas mais poderosas da sua stack do Kubernetes. Na verdade, na F5 NGINX, consideramos que ele é a base de qualquer implantação de Kubernetes pronta para produção. No entanto, muitos desenvolvedores e equipes de operações de plataforma não percebem todo o poder de um controlador de Ingress — nem as consequências de escolher um que não seja escalável. Escolher um controlador de Ingress que não seja bem dimensionado ou não proteja ambientes complexos pode impedir que você tire o Kubernetes da fase de testes e o leve para produção. Nesta série de posts, nosso objetivo é apresentar os conceitos básicos dos controladores de Ingress e mostrar como fazer uma escolha acertada que ofereça a funcionalidade e a segurança de que você precisa, hoje e no futuro.

O que é um controlador de Ingress?

Um controlador de Ingress é um balanceador de carga especializado que gerencia o tráfego de camadas 4 e 7 que entra nos clusters do Kubernetes e, possivelmente, o tráfego que sai deles. Para garantir que todos estejam alinhados, estes são os termos que usamos na NGINX (e que são, em grande parte, os mesmos usados em todo o setor):

• Tráfego de entrada – Tráfego que entra em um cluster do 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 entre serviços dentro de um cluster Kubernetes (também chamado de tráfego serviço a serviço)
• Malha de serviços – Uma ferramenta de gerenciamento de tráfego para rotear e proteger o tráfego entre serviços

Por que você precisa de um Ingress Controller?

Por padrão, os aplicativos executados em pods (contêineres) do Kubernetes não podem ser acessados 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 externas a um cluster do 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 backend e outras informações. No entanto, por si só, o recurso Ingress não faz nada. Você precisa implantar e configurar uma aplicação de controlador Ingress (usando a API do Kubernetes) para implementar as regras definidas nos recursos Ingress.

O que faz um controlador de Ingress?

• Aceita o tráfego proveniente de fora do ambiente Kubernetes, podendo modificá-lo (moldá-lo) e distribuí-lo aos pods em execução dentro do ambiente. O controlador Ingress substitui o modelo padrão de distribuição de tráfego do kube-proxy traffic distribution model, oferecendo controles adicionais semelhantes aos fornecidos por controladores de entrega de aplicações (ADCs) e proxies reversos em ambientes que não utilizam Kubernetes.
• Monitora os pods individuais de um serviço, garantindo o roteamento inteligente e evitando que as solicitações sejam “descartadas”.
• 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 a serviços externos específicos.

Na hora de escolher um controlador de Ingress, pode ser tentador começar por uma lista de recursos, mas você pode acabar escolhendo um controlador de Ingress com recursos fantásticos que não atende às necessidades da sua empresa. Em vez disso, avalie dois aspectos que afetam a eficácia do controlador de Ingress para sua equipe e suas aplicações: casos de uso (quais problemas ele resolverá) e recursos necessários (como você vai “pagar” por ele). Abordaremos esses dois tópicos no restante deste blog.

Quais problemas você quer que o Ingress Controller resolva?

O principal caso de uso de um controlador Ingress é o gerenciamento de tráfego. Portanto, é provável que você queira que o controlador Ingress seja capaz de lidar 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, circuit breaking, verificações ativas de integridade)
• Divisão de tráfego (roteamento de depuração, testes A/B, implantações canário, implantações blue-green)

Mas não há motivo para se contentar com uma solução que faz uma coisa 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 stack, como também pode transferir requisitos não funcionais dos aplicativos para o controlador Ingress. Vamos analisar quatro casos de uso não tradicionais de controladores Ingress que podem ajudar a tornar suas implantações do Kubernetes mais seguras, ágeis e escaláveis, além de permitir um uso mais eficiente dos seus recursos.

Monitoramento e visibilidade

A falta de visibilidade do cluster do Kubernetes é um dos maiores desafios em ambientes de produção, dificultando a solução de problemas e a resiliência. Como os controladores Ingress operam na borda dos clusters do Kubernetes e processam todo o tráfego, eles estão em uma posição privilegiada para fornecer dados que podem ajudar a solucionar (e até mesmo evitar) dois problemas comuns: aplicativos lentos e esgotamento de recursos no cluster ou na plataforma do Kubernetes. Para melhorar a visibilidade, o controlador Ingress precisa:

• Fornecer métricas em tempo real para que você possa diagnosticar o que está acontecendo “neste exato momento”
• Permitir a exportação de métricas para ferramentas populares de observabilidade, como Prometheus e Grafana, que exibem os valores ao longo do tempo para ajudar você a prever picos de tráfego e outras tendências

Gateway de API

A menos que você queira realizar a manipulação de solicitações e respostas no Kubernetes, é muito provável que o controlador Ingress também possa atuar como seu gateway de API. Dependendo do conjunto de recursos, um controlador Ingress pode oferecer funções essenciais de gateway de API, incluindo terminação TLS, autenticação de clientes, limitação de taxa, controle de acesso granular e roteamento de solicitações nas camadas 4 a 7.

Autenticação e login único

Transferir a autenticação das credenciais de login dos seus serviços do Kubernetes para o controlador de 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 desenvolver funcionalidades de autenticação em cada aplicação, permitindo que seus desenvolvedores se concentrem na lógica de negócios dos aplicativos.

Integração com Firewall de Aplicações Web

Não se trata de um controlador Ingress atuar como um firewall de aplicações Web (WAF), mas sim de o WAF poder ser consolidado com o controlador Ingress. Embora um WAF possa ser implantado em vários locais, dentro e fora do Kubernetes, para a maioria das organizações, o local mais eficiente e eficaz é no mesmo pod que o controlador Ingress. Esse caso de uso é ideal quando as políticas de segurança ficam sob a responsabilidade das equipes de SecOps ou DevSecOps e quando é necessária uma abordagem granular, por serviço ou por URI. Isso significa que você pode usar a API do Kubernetes para definir políticas e associá-las a serviços. Além disso, a funcionalidade de controle de acesso baseado em função (RBAC) do controlador Ingress permite que a equipe de SecOps aplique políticas por listener, enquanto os usuários de DevOps definem políticas por recurso Ingress.

Como você vai alocar recursos para o controlador de Ingress?

Todo controlador Ingress tem um custo… até mesmo os que são gratuitos e de código aberto (talvez você já tenha ouvido a expressão “grátis como um filhote de cachorro”). Alguns custos podem ser previstos em valores monetários e incluídos como itens no seu orçamento, enquanto outros dependem de quanto tempo sua equipe precisa dedicar para lidar com as consequências da escolha do controlador Ingress (maior complexidade, falta de portabilidade e assim por diante). Vejamos os custos — tanto em termos de tempo quanto de dinheiro — que devem ser considerados ao definir o orçamento para um controlador Ingress.

Planejamento dos custos de tempo

Elaborar um orçamento de pessoal pode ser muito mais desafiador do que orçar itens de custo fixo, especialmente quando você está tentando alocar recursos para um projeto em uma área com a qual não tem familiaridade. É preciso fazer perguntas como:

• Quem configurará e administrará o controlador Ingress? Isso faz parte do trabalho em tempo integral dessas pessoas (por exemplo, como integrantes da sua equipe de Operações de Plataforma) ou elas assumirão essa tarefa como uma responsabilidade adicional (na função de desenvolvedores)?
• É possível reservar tempo para que os funcionários façam um treinamento formal? Ou a ferramenta precisa ser simples o suficiente para que eles aprendam a usá-la de forma rápida e fácil no trabalho?
• Você está preparado para deixar que os funcionários façam ajustes na ferramenta sempre que um novo recurso for necessário ou passem muito tempo solucionando problemas quando algo der errado? Ou você precisa que eles gerem valor para a empresa de outras formas?

Uma observação sobre a responsabilidade pelas ferramentas do Kubernetes

Observamos uma tendência no setor de consolidar as ferramentas e sua gestão sob a responsabilidade das equipes de NetOps. Embora isso possa contribuir muito para simplificar sua stack e melhorar a segurança, defendemos uma duplicação criteriosa de ferramentas com base nos objetivos da equipe. Faz sentido que a equipe de NetOps gerencie as ferramentas de perímetro (como balanceadores de carga externos), pois seu foco está na plataforma como um todo. No entanto, as equipes de DevOps se preocupam principalmente com os serviços implantados próximos ao código da aplicação e precisam de mais agilidade e de um controle mais granular do que as ferramentas de NetOps oferecem. As ferramentas do Kubernetes, incluindo o controlador Ingress, têm mais chances de sucesso quando são selecionadas pela equipe de DevOps. Isso não significa que você deva dar aos desenvolvedores total liberdade para escolher as ferramentas! Uma padronização rigorosa das ferramentas dentro do Kubernetes ainda é uma prática recomendada.

Orçamento para despesas de capital

Quando as organizações começam a experimentar o Kubernetes, geralmente não reservam muito orçamento para ferramentas ou suporte. Se você dispõe de pessoal suficiente para realmente dar suporte a um controlador de Ingress que exige mais “atenção”, não ter um orçamento financeiro pode funcionar... no início. Porém, à medida que seu investimento no Kubernetes aumenta, você pode acabar limitado pelos recursos da ferramenta ou querer direcionar sua equipe para outras prioridades. É nesse momento que passa a valer a pena pagar por uma ferramenta mais fácil de usar e mais estável, com recursos e suporte de nível empresarial.

Quando você estiver pronto para pagar por um controlador de Ingress, lembre-se de que o modelo de licenciamento é importante. Com base nos modelos tradicionais de precificação usados fora do Kubernetes, o preço dos controladores de Ingress costuma ser definido “por instância” ou “por proxy de Ingress”. Embora ainda existam casos de uso em que isso faça sentido no Kubernetes, licenciar um controlador de Ingress “por cluster” significa que você paga com base na locação dos aplicativos, e não no “número de proxies”.

Confira nossas recomendações para diferentes cenários:

• Está começando a usar o Kubernetes? Escolha o licenciamento por cluster.
  Quando você tem pouca experiência com o Kubernetes, é muito difícil prever com precisão o número de instâncias do controlador Ingress necessárias. Se tiver que escolher um número de instâncias, você poderá subestimá-lo — dificultando o alcance dos seus objetivos — ou superestimá-lo e desperdiçar recursos que seriam mais bem investidos em outras partes do projeto Kubernetes. Negociar um preço fixo relativamente baixo para um “cluster pequeno” aumenta suas chances de sucesso.
• Precisa escalar o Kubernetes? Escolha o licenciamento por cluster.
  É praticamente impossível prever quanto e com que frequência você precisará aumentar ou reduzir os recursos do Kubernetes (expansão e contração). A cobrança por instância obriga sua equipe a definir limites arbitrários para não ultrapassar as restrições de licenciamento. Com o licenciamento por cluster, você não precisa monitorar cada contêiner de Ingress e, dependendo do fornecedor (como a NGINX), a expansão pode estar incluída sem custo adicional.
• Implantações avançadas ou estáticas? Escolha o licenciamento por instância.
  Se você tem experiência suficiente com Kubernetes para saber exatamente como usará o controlador de Ingress, pretende usar um pequeno número de proxies de Ingress por cluster e não precisa de nenhum serviço incluído que possa acompanhar a ferramenta, então a cobrança por instância pode ser uma ótima opção.

Próximos passos: tolerância a riscos e preparação para o futuro

Agora que você já compreende seus requisitos, a próxima etapa é decidir em equipe qual é a sua tolerância aos riscos que um controlador Ingress pode introduzir e determinar como ele precisará ser dimensionado à medida que sua implantação do Kubernetes crescer. Abordamos esses tópicos na Parte 2.

Sobre o autor

Jenn GileDiretor de Marketing de Produto, NGINX

Mais publicações de Jenn Gile