Guia para escolher um controlador de Ingress, parte 2: riscos e preparação para o futuro

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 aumentar 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. Guia para escolher um controlador de Ingress, parte 1: identifique seus requisitos
6. Guia para escolher um controlador de Ingress, Parte 2: riscos e preparação para o futuro (este artigo)
7. Um guia para escolher um controlador de Ingress, parte 3: código aberto vs. padrão vs. comercial
8. Um guia para escolher um controlador de Ingress, parte 4: opções do controlador de Ingress do 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 ambiente de testes à produção.

Na Parte 1 do nosso guia para escolher um controlador de Ingress, explicamos como identificar seus requisitos. Mas ainda não é hora de testar os produtos! Neste artigo, explicamos como o controlador de Ingress errado pode reduzir a velocidade dos seus lançamentos e até mesmo fazer com que você perca clientes. Como qualquer ferramenta, os controladores de Ingress podem introduzir riscos e afetar a escalabilidade futura. Vamos ver como eliminar opções que podem causar mais prejuízos do que benefícios.

Riscos dos controladores de Ingress

Há três riscos específicos que você deve considerar ao adotar uma ferramenta de gerenciamento de tráfego para Kubernetes: complexidade, latência e segurança. Esses problemas costumam estar interligados; quando um deles está presente, é provável que os outros também estejam. Todos podem ser introduzidos por um controlador Ingress, e cabe à sua organização decidir se o risco é tolerável. Os consumidores de hoje são exigentes, e qualquer fator que prejudique a experiência digital pode ser inaceitável, mesmo diante de um conjunto atraente de recursos.

Complexidade – Ela compromete o propósito de uma arquitetura de microsserviços?

As melhores ferramentas do Kubernetes são aquelas que atendem aos objetivos da arquitetura de microsserviços: são leves e têm um design simples. É possível desenvolver um controlador Ingress com muitos recursos sem abrir mão desses princípios, mas nem sempre isso acontece. Alguns projetistas incluem funções demais ou usam scripts complexos para adicionar recursos que não são nativos do mecanismo subjacente, resultando em um controlador Ingress desnecessariamente complexo.

E por que isso é importante? No Kubernetes, uma ferramenta excessivamente complexa pode afetar negativamente o desempenho da aplicação e limitar sua capacidade de escalar horizontalmente a implantação. Em geral, é possível identificar um controlador Ingress excessivamente complexo pelo seu tamanho: quanto maior a área ocupada, mais complexa é a ferramenta.

Latência – O Ingress Controller deixa seus aplicativos mais lentos?

Os controladores de Ingress podem aumentar a latência devido ao uso de recursos, erros e tempos limite. Analise a latência adicionada em implantações estáticas e dinâmicas e descarte as opções que introduzam uma latência inaceitável de acordo com seus requisitos internos. Para saber mais sobre como as reconfigurações podem afetar a velocidade dos aplicativos, consulte Testes de desempenho de controladores de Ingress do NGINX em um ambiente de nuvem Kubernetes dinâmico em nosso blog.

Segurança – O Ingress Controller abre as portas para hackers?

As Vulnerabilidades e Exposições Comuns (CVEs) são predominantes na Internet atual, e o tempo que o fornecedor do seu controlador de Ingress leva para disponibilizar uma correção para uma CVE pode ser a diferença entre a segurança e uma violação. Dependendo da tolerância a riscos da sua organização, talvez seja melhor descartar soluções que levem mais do que alguns dias (ou, no máximo, semanas) para disponibilizar correções.

Além das CVEs, alguns controladores Ingress expõem você a outra possível vulnerabilidade. Considere este cenário: você trabalha para um varejista on-line e precisa de ajuda para solucionar problemas na configuração do seu controlador Ingress de código aberto. Como não há suporte comercial disponível, você publica o problema em um fórum como o Stack Overflow. Alguém se oferece para ajudar e quer procurar problemas nos arquivos de configuração e de log do controlador Ingress e de outros componentes do Kubernetes. Pressionado para resolver o problema rapidamente, você compartilha os arquivos.

O “bom samaritano” ajuda você a resolver o problema, mas, seis meses depois, você descobre uma violação: números de cartões de crédito foram roubados dos registros dos seus clientes. Ops. Acontece que os arquivos que você compartilhou continham informações que foram usadas para invadir seu aplicativo. Esse cenário ilustra um dos principais motivos pelos quais as organizações optam por pagar pelo suporte: a garantia de confidencialidade.

Uma observação sobre controladores de Ingress baseados no OpenResty

O OpenResty é uma plataforma web desenvolvida com base no NGINX Open Source que incorpora LuaJIT, scripts Lua e módulos NGINX de terceiros para ampliar a funcionalidade do NGINX Open Source. Por sua vez, há vários controladores Ingress desenvolvidos com base no OpenResty que, em nossa opinião, podem adicionar dois riscos em comparação com nossos controladores Ingress baseados no NGINX Open Source e no NGINX Plus:

• Tempos limite – Como observado, o OpenResty usa scripts Lua para implementar recursos avançados, como os do nosso Ingress Controller comercial baseado no NGINX Plus. Um desses recursos é a reconfiguração dinâmica, que elimina um requisito do NGINX Open Source que reduz a disponibilidade – especificamente, a necessidade de recarregar a configuração do NGINX quando os endpoints de serviço são alterados. Para realizar a reconfiguração dinâmica com o OpenResty, o manipulador Lua escolhe para qual serviço upstream encaminhar a solicitação, eliminando assim a necessidade de recarregar a configuração do NGINX. No entanto, o Lua precisa verificar continuamente se há alterações nos backends, o que consome recursos. As solicitações recebidas demoram mais para ser processadas, fazendo com que algumas fiquem paralisadas, o que aumenta a probabilidade de tempos limite. À medida que você amplia a escala para atender a mais usuários e serviços, a diferença entre o número de solicitações recebidas por segundo e o número que o Lua consegue processar aumenta exponencialmente. As consequências são latência, complexidade e custos mais altos. Leia Testes de desempenho de Ingress Controllers do NGINX em um ambiente de nuvem Kubernetes dinâmico para ver quanta latência o Lua pode adicionar.
• Atrasos na aplicação de patches de CVE – Em comparação com os Ingress Controllers da NGINX, os patches para CVEs inevitavelmente demoram mais para chegar aos Ingress controllers baseados em ferramentas como o OpenResty, que, por sua vez, são baseadas no NGINX Open Source. Conforme explicamos em detalhes em Mitigação rápida e fácil de vulnerabilidades de segurança com o NGINX Plus, quando uma CVE no NGINX é descoberta, nós, como fornecedor, geralmente somos informados antes que ela seja divulgada publicamente. Isso nos permite lançar um patch para o NGINX Open Source e o NGINX Plus assim que a CVE é anunciada. As tecnologias baseadas no NGINX Open Source talvez só tomem conhecimento da CVE nesse momento e, segundo nossa experiência, os patches do OpenResty são lançados com um atraso significativo em relação aos nossos – quatro meses em um caso recente. Os patches para um Ingress controller baseado no OpenResty inevitavelmente demoram ainda mais, dando a agentes mal-intencionados tempo de sobra para explorar a vulnerabilidade.

Prepare seu Ingress Controller para o futuro

Mesmo que você esteja apenas começando a explorar o Kubernetes, é bem provável que pretenda colocá-lo em produção algum dia. Há quatro áreas principais em que suas necessidades provavelmente aumentarão com o tempo: infraestrutura, segurança, suporte e multilocação.

Infraestrutura – Você usará o Kubernetes em ambientes híbridos ou multinuvem?

É raro uma organização se comprometer de forma integral e permanente com um único tipo de ambiente. É mais comum que as organizações tenham uma combinação de ambientes locais e em nuvem, que pode incluir nuvens privadas, públicas, híbridas e múltiplas. (Para entender melhor as diferenças entre esses ambientes, leia Qual é a diferença entre multinuvem e nuvem híbrida?.)

Como mencionamos na Parte 1 desta série, é tentador escolher as ferramentas padrão de cada ambiente, mas há uma série de problemas específicos dos controladores de Ingress padrão. Abordaremos todas as desvantagens na Parte 3 da série, mas a questão mais relevante para garantir a adaptabilidade futura é a dependência de fornecedor – não é possível usar um controlador de Ingress específico de uma nuvem em todos os seus ambientes. O uso de ferramentas padrão específicas de uma nuvem afeta sua capacidade de escalar, pois restam apenas duas alternativas pouco atraentes:

1. Tentar fazer com que a nuvem existente atenda a todas as suas necessidades
2. Reescreva todas as suas configurações — não apenas as de balanceamento de carga, mas também as de segurança! — para o controlador Ingress em cada novo ambiente

Embora a primeira alternativa muitas vezes não seja viável por motivos comerciais, a segunda também é complicada, pois causa a proliferação de ferramentas, cria novas vulnerabilidades de segurança e exige que seus funcionários enfrentem curvas de aprendizado acentuadas. A terceira alternativa, e a mais eficiente, é escolher desde o início um controlador de Ingress independente de infraestrutura, permitindo que você use a mesma ferramenta em todos os seus ambientes.

Quando se trata de infraestrutura, há outro elemento a considerar: as certificações. Vejamos o exemplo do Red Hat OpenShift Container Platform (OCP). Se você usa o OCP, provavelmente já sabe que o Red Hat Marketplace oferece operadores certificados para o OCP, incluindo o NGINX Ingress Operator. Os padrões de certificação da Red Hat proporcionam a tranquilidade de saber que a ferramenta funciona com sua implantação e podem até incluir suporte conjunto da Red Hat e do fornecedor. Muitas organizações exigem o uso de ferramentas certificadas por motivos de segurança e estabilidade. Portanto, mesmo que você esteja apenas na fase de testes, vale a pena ter em mente os requisitos da sua empresa para ambientes de produção.

Segurança – Como você protegerá o Kubernetes por dentro?

Já se foi o tempo em que apenas a segurança de perímetro era suficiente para manter aplicativos e clientes protegidos. Os aplicativos do Kubernetes ficam mais bem protegidos quando a segurança — incluindo autenticação e autorização — está próxima deles. E, com as organizações exigindo cada vez mais criptografia de ponta a ponta e adotando um modelo de rede de confiança zero no Kubernetes, uma malha de serviços pode fazer parte do seu futuro.

O que tudo isso tem a ver com seu controlador de Ingress? Muita coisa! Centralizar a segurança (autenticação, autorização, proteção contra DoS e firewall de aplicações web) no ponto de Ingress faz muito sentido tanto do ponto de vista de custos quanto de eficiência. E, embora a maioria das malhas de serviço possa ser integrada à maioria dos controladores de Ingress, a forma como essa integração é feita é muito importante. Um controlador de Ingress alinhado à sua estratégia de segurança pode evitar grandes dores de cabeça durante toda a jornada de desenvolvimento das suas aplicações.

Leia Proteja aplicações nativas da nuvem sem perder velocidade para saber mais sobre os riscos da entrega de aplicações nativas da nuvem e leia Implantação de serviços de aplicações no Kubernetes, parte 2 para conhecer melhor os fatores que determinam o melhor local para as ferramentas de segurança.

Suporte – Até que ponto você pode se dar ao luxo de ficar “por conta própria”?

Quando as equipes estão apenas fazendo experimentos com o Kubernetes, o suporte — seja da comunidade ou de uma empresa — geralmente não é a maior prioridade. Isso não é um problema se suas equipes tiverem bastante tempo para criar suas próprias soluções e alternativas, mas não é sustentável quando você passa para o ambiente de produção. Mesmo que você não precise de suporte hoje, pode ser uma boa ideia escolher um controlador Ingress que permita adicionar suporte no futuro — ou que tenha um plano de suporte acessível que possa ser aprimorado à medida que você cresce.

Multilocação – Como várias equipes e aplicações podem compartilhar um ambiente de contêineres com segurança?

No início, havia uma equipe e um aplicativo… não é assim que toda história começa? Muitas vezes, a história continua com essa equipe desenvolvendo com sucesso seu aplicativo no Kubernetes, o que leva a organização a executar mais serviços no Kubernetes. E, claro, mais serviços = mais equipes = mais complexidade.

Para alcançar a máxima eficiência, as organizações adotam a multilocação e um modelo de Kubernetes que oferece o acesso e o isolamento exigidos por seus processos de negócios, além de proporcionar a organização e os controles de que seus operadores precisam. Alguns controladores de Ingress podem ajudar a segmentar esses clusters por meio de diversos recursos e conceitos: vários ingresses, classes, namespaces e recursos com escopo definido que permitem configurar controles de acesso baseados em função (RBAC).

Próximo passo: reduza as opções

Agora que você já refletiu sobre seus requisitos, sua tolerância a riscos e a preparação para o futuro, tem informações suficientes para começar a reduzir o vasto leque de controladores Ingress. Dividir esse universo em categorias pode ajudar você a concluir esta etapa rapidamente. Na Parte 3 da nossa série, exploraremos três categorias diferentes de controladores Ingress, incluindo os prós e os contras de cada uma.

Sobre o autor

Jenn GileDiretor de Marketing de Produto, NGINX

Mais publicações de Jenn Gile