Um guia para escolher um controlador Ingress, parte 2: Riscos e preparação para o futuro

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
6. Um guia para escolher um controlador Ingress, parte 2: Riscos e preparação para o futuro (este post)
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 .

Na Parte 1 do nosso guia para escolher um controlador Ingress , explicamos como identificar seus requisitos. Mas ainda não é hora de testar os produtos! Nesta postagem, explicamos como o controlador Ingress errado pode diminuir a velocidade de lançamento e até mesmo custar clientes. Como acontece com qualquer ferramenta, os controladores Ingress podem introduzir riscos e impactar a escalabilidade futura. Vamos ver como eliminar escolhas que podem causar mais mal do que bem.

Riscos do controlador de entrada

Há três riscos específicos que você deve considerar ao introduzir uma ferramenta de gerenciamento de tráfego para o Kubernetes: complexidade, latência e segurança. Essas questões geralmente estão interligadas; quando uma está presente, é provável que você veja as outras. Cada um pode ser introduzido por um controlador Ingress e cabe à sua organização decidir se o risco é tolerável. Os consumidores de hoje são inconstantes, e qualquer coisa que cause uma experiência digital ruim pode ser inaceitável, apesar de um conjunto de recursos atraente.

Complexidade – Ela derrota 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: leves e simples no design. É possível desenvolver um controlador Ingress muito rico em recursos que siga esses princípios, mas isso nem sempre é a norma. Alguns designers incluem muitas funções ou usam scripts complicados para adicionar recursos que não são nativos do mecanismo subjacente, resultando em um controlador Ingress desnecessariamente complexo.

E por que isso importa? No Kubernetes, uma ferramenta excessivamente complexa pode impactar negativamente o desempenho do aplicativo e limitar sua capacidade de dimensionar sua implantação horizontalmente. Normalmente, você pode identificar um controlador Ingress muito complexo pelo seu tamanho: quanto maior a pegada, mais complexa é a ferramenta.

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

Os controladores de entrada podem adicionar latência devido ao uso de recursos, erros e tempos limite. Observe a latência adicionada em implantações estáticas e dinâmicas e elimine opções que introduzem latência inaceitável com base em seus requisitos internos. Para obter mais detalhes sobre como as reconfigurações podem afetar a velocidade do aplicativo, consulte Testes de desempenho de controladores de entrada NGINX em um ambiente de nuvem Kubernetes dinâmico em nosso blog.

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

Vulnerabilidades e Exposições Comuns (CVEs) são abundantes na Internet de hoje, e o tempo que leva para o seu provedor de controlador Ingress fornecer um patch CVE pode ser a diferença entre segurança e uma violação. Com base na tolerância a riscos da sua organização, você pode querer eliminar soluções que levam mais do que alguns dias (ou no máximo semanas) para fornecer patches.

Além dos CVEs, alguns controladores Ingress expõem você a outra vulnerabilidade potencial. Considere este cenário: você trabalha para um varejista on-line e precisa de ajuda para solucionar problemas de configuração do seu controlador Ingress de código aberto. Não há suporte comercial disponível, então 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 log do controlador Ingress e outros componentes do Kubernetes. Sentindo a pressão para resolver o problema rapidamente, você compartilha os arquivos.

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

Uma nota sobre controladores de entrada baseados em OpenResty

OpenResty é uma plataforma web construída no NGINX Open Source que incorpora LuaJIT, scripts Lua e módulos NGINX de terceiros para estender a funcionalidade do NGINX Open Source. Por sua vez, existem vários controladores Ingress criados no OpenResty, que acreditamos que podem potencialmente adicionar dois riscos em comparação aos nossos controladores Ingress baseados no NGINX Open Source e NGINX Plus:

• Tempos limite – Conforme observado, o OpenResty usa scripts Lua para implementar recursos avançados como aqueles em nosso controlador Ingress comercial baseado em NGINX Plus . Um desses recursos é a reconfiguração dinâmica, que elimina um requisito do NGINX Open Source que reduz a disponibilidade, ou seja, que a configuração do NGINX deve ser recarregada quando os pontos de extremidade do serviço mudam. Para realizar a reconfiguração dinâmica com o OpenResty, o manipulador Lua escolhe para qual serviço upstream rotear a solicitação, eliminando assim a necessidade de recarregar a configuração do NGINX.

  Entretanto, Lua precisa verificar continuamente se há alterações nos backends, o que consome recursos. As solicitações recebidas demoram mais para serem processadas, fazendo com que algumas delas fiquem paralisadas, o que aumenta a probabilidade de tempos limite esgotados. À medida que você expande para 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 pode manipular aumenta exponencialmente. A consequência é latência, complexidade e custos mais altos.

  Leia Testes de desempenho de controladores de entrada NGINX em um ambiente de nuvem Kubernetes dinâmico para ver quanta latência o Lua pode adicionar.

• Atrasos na aplicação de patches CVE – Em comparação com os controladores Ingress do NGINX, os patches para CVEs inevitavelmente demoram mais para aparecer nos controladores Ingress com base em ferramentas como o OpenResty, que por sua vez são baseados no NGINX Open Source. Conforme descrevemos em detalhes em Mitigando vulnerabilidades de segurança de forma rápida e fácil com o NGINX Plus , quando um CVE no NGINX é descoberto, nós, como fornecedores, geralmente somos informados antes que o CVE seja divulgado publicamente. Isso nos permite lançar um patch para o NGINX Open Source e o NGINX Plus assim que o CVE for anunciado.

  Tecnologias baseadas no NGINX Open Source podem não aprender sobre o CVE até esse ponto e, em nossa experiência, os patches do OpenResty ficam significativamente atrás dos nossos — quatro meses em um caso recente . Patches para um controlador Ingress baseado no OpenResty inevitavelmente levam ainda mais tempo, dando a um agente mal-intencionado ampla oportunidade de explorar a vulnerabilidade.

Proteja seu controlador Ingress para o futuro

Mesmo que você esteja apenas começando a se aventurar no Kubernetes, há uma boa chance de você desejar colocá-lo em produção algum dia. Há quatro áreas principais onde suas necessidades provavelmente crescerão ao longo do tempo: infraestrutura, segurança, suporte e multilocação.

Infraestrutura – Você usará o Kubernetes em ambientes de nuvem híbrida ou multi-nuvem?

É raro que uma organização esteja total e permanentemente comprometida com um tipo de ambiente. Mais comumente, as organizações têm uma mistura de ambientes locais e na nuvem, que pode incluir nuvem privada, pública, híbrida e multinuvem. (Para uma análise mais aprofundada de como esses ambientes diferem, leia Qual é a diferença entre multinuvem e nuvem híbrida? .)

Como mencionamos na Parte 1 desta série, é tentador escolher ferramentas que vêm por padrão em cada ambiente, mas há uma série de problemas específicos dos controladores Ingress padrão. Abordaremos todas as desvantagens na Parte 3 da série, mas a questão mais relevante para a proteção futura é o bloqueio do fornecedor: você não pode usar um controlador Ingress específico da nuvem em todos os seus ambientes. O uso de ferramentas específicas da nuvem padrão afeta sua capacidade de escalar porque você fica com apenas duas alternativas pouco atraentes:

1. Tente fazer com que a nuvem existente funcione para todas as suas necessidades
2. Reescreva todas as suas configurações – não apenas o balanceamento de carga, mas também a 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 porque causa proliferação de ferramentas, abre novas vulnerabilidades de segurança e exige que seus funcionários enfrentem curvas de aprendizado íngremes. A terceira e mais eficiente alternativa é escolher um controlador Ingress independente de infraestrutura desde o início, permitindo que você use a mesma ferramenta em todos os seus ambientes.

Quando se trata de infraestrutura, há outro elemento a considerar: certificações. Vamos usar o exemplo do Red Hat OpenShift Container Platform (OCP). Se você é um usuário do OCP, provavelmente já sabe que o Red Hat Marketplace oferece operadores certificados para OCP, incluindo o NGINX Ingress Operator . Os padrões de certificação da Red Hat significam que você fica tranquilo sabendo que a ferramenta funciona com sua implantação e pode até incluir suporte conjunto da Red Hat e do fornecedor. Muitas organizações têm requisitos para usar ferramentas certificadas por motivos de segurança e estabilidade, então, mesmo que você esteja apenas testando agora, 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 foram os dias em que a segurança do perímetro era suficiente para manter aplicativos e clientes seguros. Os aplicativos Kubernetes são mais bem protegidos quando a segurança – incluindo autenticação e autorização – está próxima dos aplicativos. 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 estar no seu futuro.

O que tudo isso tem a ver com seu controlador Ingress? Bastante! Centralizar a segurança (autenticação, autorização, proteção DoS, firewall de aplicativo web) no ponto de entrada faz muito sentido do ponto de vista de custo e eficiência. E embora a maioria das malhas de serviço possa ser integrada à maioria dos controladores do Ingress, a forma como elas se integram importa muito. Um controlador Ingress alinhado à sua estratégia de segurança pode evitar grandes dores de cabeça durante toda a jornada de desenvolvimento do seu aplicativo.

Leia Aplicativos nativos da nuvem seguros sem perder velocidade para obter mais detalhes sobre os riscos da entrega de aplicativos nativos da nuvem e Implantação de serviços de aplicativos no Kubernetes, Parte 2 para saber mais sobre os fatores que determinam o melhor local para ferramentas de segurança.

Suporte – O quão “por conta própria” você pode se dar ao luxo de ser?

Quando as equipes estão apenas experimentando o Kubernetes, o suporte – seja da comunidade ou de uma empresa – geralmente não é a maior prioridade. Isso é aceitável se suas equipes têm muito tempo para criar suas próprias soluções e alternativas, mas não é sustentável quando você passa para a produção. Mesmo que você não precise de suporte hoje, pode ser sensato escolher um controlador Ingress que permita adicionar suporte no futuro – ou que tenha um nível de suporte barato que pode ser atualizado conforme você escala.

Multi-locação – Como várias equipes e aplicativos podem compartilhar um ambiente de contêiner com segurança?

No começo, havia uma equipe e um aplicativo... não é assim que toda história começa? A história geralmente continua com uma equipe desenvolvendo com sucesso seu aplicativo Kubernetes, levando a organização a executar mais serviços no Kubernetes. E, claro, mais serviços = mais equipes = mais complexidade.

Para atingir a eficiência máxima, as organizações adotam a multilocação e adotam um modelo Kubernetes que oferece suporte ao acesso e ao isolamento exigidos por seus processos de negócios, ao mesmo tempo em que fornece a sanidade e os controles de que seus operadores precisam. Alguns controladores Ingress podem ajudar você a dividir esses clusters por meio de uma série de recursos e conceitos: vários ingresso, classes, namespaces e recursos com escopo que oferecem suporte à definição de controles de acesso baseados em função (RBAC).

Próximo passo: Reduzir opções

Agora que você pensou sobre seus requisitos, tolerância a riscos e preparação para o futuro, você tem informações suficientes para começar a restringir o amplo campo de controladores Ingress. Dividir esse campo por categoria pode ajudar você a concluir essa etapa rapidamente. Na Parte 3 da nossa série, exploraremos três categorias diferentes de controladores Ingress, incluindo os prós e contras de cada uma.