Editor – Este post é um extrato do nosso eBook abrangente, Managing Kubernetes Traffic with F5 NGINX: Um guia prático . Baixe gratuitamente hoje mesmo .
Muitas organizações que configuram o Kubernetes pela primeira vez começam com o controlador NGINX Ingress desenvolvido e mantido pela comunidade Kubernetes ( kubernetes/ingress-nginx ). No entanto, à medida que as implantações do Kubernetes amadurecem, algumas organizações descobrem que precisam de recursos avançados ou desejam suporte comercial, mantendo o NGINX como o plano de dados.
Uma opção é migrar para o NGINX Ingress Controller desenvolvido e mantido pela F5 NGINX ( nginxinc/kubernetes-ingress ), e aqui fornecemos instruções completas para que você possa evitar algumas complicações resultantes das diferenças entre os dois projetos.
Não tem certeza de como essas opções diferem? Leia Um guia para escolher um controlador Ingress, Parte 4: Opções do controlador de entrada NGINX em nosso blog.
Para distinguir entre os dois projetos no restante desta postagem, nos referimos ao NGINX Ingress Controller mantido pela comunidade Kubernetes ( kubernetes/ingress-nginx ) como o “controlador Ingress da comunidade” e ao mantido pelo F5 NGINX ( nginxinc/kubernetes-ingress ) como “NGINX Ingress Controller”.
Há duas maneiras de migrar do controlador Ingress da comunidade para o NGINX Ingress Controller:
Com esta opção de migração, você usa o recurso padrão do Kubernetes Ingress para definir recursos raiz e os recursos do NGINX Ingress para aprimorar sua configuração com mais recursos e facilidade de uso.
As definições de recursos personalizados (CRDs) para recursos do NGINX Ingress – VirtualServer, VirtualServerRoute , TransportServer , GlobalConfiguration e Policy – permitem que você delegue facilmente o controle sobre várias partes da configuração para diferentes equipes (como AppDev e equipes de segurança), além de fornecer maior segurança e validação de configuração.
A tabela mapeia a configuração da terminação SSL e do roteamento baseado em caminho da Camada 7 no campo spec
do recurso padrão do Kubernetes Ingress com o campo spec
no recurso NGINX VirtualServer . A sintaxe e o recuo diferem ligeiramente nos dois recursos, mas eles realizam as mesmas funções básicas do Ingress.
Recurso de entrada do Kubernetes | Recurso NGINX VirtualServer |
---|---|
|
|
Com o controlador Ingress da comunidade, um objeto da API ConfigMap do Kubernetes é a única maneira de expor serviços TCP e UDP .
Com o NGINX Ingress Controller, os recursos do TransportServer definem uma ampla gama de opções para balanceamento de carga TCP/UDP e TLS Passthrough. Os recursos do TransportServer são usados em conjunto com os recursos do GlobalConfiguration para controlar conexões de entrada e saída.
Para obter mais informações, consulte Suporte para serviços de passagem TCP, UDP e TLS nos recursos do NGINX Ingress em nosso blog.
As implantações do Kubernetes de nível de produção geralmente precisam estender regras básicas do Ingress para implementar casos de uso avançados, incluindo implantações canário e azul-verde, limitação de tráfego, manipulação de tráfego de entrada-saída e muito mais.
O controlador Ingress da comunidade implementa muitos desses casos de uso com anotações do Kubernetes. No entanto, muitas dessas anotações são criadas com extensões Lua personalizadas que pertencem a definições de recursos do NGINX Ingress muito específicas e, como resultado, não são adequadas para implementar funcionalidades avançadas em um ambiente de produção estável e com suporte.
Nas seções a seguir, mostraremos como converter anotações do controlador Ingress da comunidade em recursos do controlador Ingress NGINX.
Mesmo que você envie alterações frequentes de código para suas cargas de trabalho de contêiner de produção, você deve continuar atendendo seus usuários existentes. As implantações canário e azul-verde permitem que você faça isso, e você pode executá-las no plano de dados do NGINX Ingress Controller para obter atualizações estáveis e previsíveis em ambientes Kubernetes de nível de produção.
A tabela mostra os campos nos recursos NGINX VirtualServer e VirtualServerRoute que correspondem às anotações do controlador Ingress da comunidade para implantações canary .
O controlador Ingress da comunidade avalia as anotações canary nesta ordem de precedência:
nginx.ingress.kubernetes.io/canary-by-header
nginx.ingress.kubernetes.io/canary-by-cookie
nginx.ingress.kubernetes.io/canary-by-weight
Para que o NGINX Ingress Controller os avalie da mesma maneira, eles devem aparecer nessa ordem no manifesto NGINX VirtualServer ou VirtualServerRoute.
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
|
|
|
|
|
|
Em ambientes de microsserviços, onde os aplicativos são efêmeros por natureza e, portanto, mais propensos a retornar respostas de erro, as equipes de DevOps fazem uso extensivo de políticas de controle de tráfego – como interrupção de circuito e limitação de taxa e conexão – para evitar condições de erro quando os aplicativos não estão íntegros ou não estão funcionando conforme o esperado.
A tabela mostra os campos nos recursos NGINX VirtualServer e VirtualServerRoute que correspondem às anotações do controlador Ingress da comunidade para limitação de taxa , erros HTTP personalizados , um backend padrão personalizado e reescrita de URI .
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conforme indicado na tabela, no momento em que este artigo foi escrito, os recursos do NGINX Ingress não incluíam campos que traduzem diretamente as quatro anotações do controlador Ingress da comunidade a seguir, e você deve usar snippets. O suporte direto para as quatro anotações, usando recursos de política , está planejado para versões futuras do NGINX Ingress Controller.
nginx.ingress.kubernetes.io/limit-connections
nginx.ingress.kubernetes.io/limit-rate
nginx.ingress.kubernetes.io/limit-rate-after
nginx.ingress.kubernetes.io/limit-whitelist
Manipular cabeçalhos HTTP é útil em muitos casos de uso, pois eles contêm informações adicionais que são importantes e relevantes para sistemas envolvidos em uma transação HTTP. Por exemplo, o controlador Ingress da comunidade oferece suporte à ativação e à configuração de cabeçalhos de compartilhamento de recursos de origem cruzada (CORS), que são usados com aplicativos AJAX, onde o código JavaScript front-end de um navegador está se conectando a um aplicativo back-end ou servidor web.
A tabela mostra os campos nos recursos NGINX VirtualServer e VirtualServerRoute que correspondem às anotações do controlador Ingress da comunidade para manipulação de cabeçalho .
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
Há outras funcionalidades de proxy e balanceamento de carga que você pode querer configurar no NGINX Ingress Controller, dependendo do caso de uso específico. Essas funcionalidades incluem a configuração do algoritmo de balanceamento de carga, bem como configurações de tempo limite e buffer para conexões com proxy.
A tabela mostra as instruções no campo upstream
dos recursos NGINX VirtualServer e VirtualServerRoute que correspondem às anotações do controlador Ingress da comunidade para balanceamento de carga NGINX personalizado , tempos limite de proxy , buffer de proxy e conexões de roteamento para o endereço IP e a porta do cluster de um serviço .
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Uma malha de serviços é particularmente útil em um ambiente de confiança zero estrito, onde aplicativos distribuídos dentro de um cluster se comunicam com segurança por meio de autenticação mútua. E se precisarmos impor o mesmo nível de segurança ao tráfego que entra e sai do cluster (tráfego norte-sul)?
Podemos configurar a autenticação mTLS na camada do Ingress Controller para que os sistemas finais de conexões externas se autentiquem apresentando um certificado válido.
A tabela mostra os campos nos recursos da Política NGINX que correspondem às anotações do controlador Ingress da comunidade para autenticação de certificado de cliente e autenticação de certificado de backend .
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
|
|
A tabela mostra os campos nos recursos da Política NGINX que são exclusivos do NGINX Ingress Controller com base no NGINX Plus e correspondem às anotações do Ingress Controller da comunidade para persistência de sessão (afinidade).
Controlador de entrada da comunidade | NGINX Ingress Controller |
---|---|
|
|
A segunda opção para migrar do controlador Ingress da comunidade para o NGINX Ingress Controller é usar apenas anotações e ConfigMaps no recurso Ingress padrão do Kubernetes e potencialmente confiar no processamento no estilo " mestre/servo ". Isso mantém toda a configuração no objeto Ingress.
Observação: Com esse método, não altere o campo de especificação
do recurso Ingress.
A tabela a seguir descreve as anotações do controlador Ingress da comunidade que correspondem diretamente às anotações suportadas pelo NGINX Ingress Controller.
1O controlador Ingress da comunidade usa Lua para implementar alguns de seus algoritmos de balanceamento de carga. O NGINX Ingress Controller não tem um equivalente para todos eles.
2Redireciona o tráfego HTTP para HTTPS. O controlador Ingress da comunidade implementa isso com código Lua, enquanto o controlador Ingress NGINX usa condições if
nativas do NGINX.
A tabela a seguir descreve as anotações do controlador Ingress da comunidade que correspondem diretamente às anotações suportadas pelo NGINX Ingress Controller com base no NGINX Plus.
Controlador de entrada da comunidade | Controlador de entrada NGINX baseado no NGINX Plus |
---|---|
|
|
Observação: O NGINX Ingress Controller baseado no NGINX Plus tem anotações adicionais para recursos que o Community Ingress Controller não oferece suporte, incluindo verificações de integridade ativas e autenticação usando JSON Web Tokens (JWTs).
A tabela a seguir mapeia as chaves ConfigMap do controlador Ingress da comunidade para suas chaves ConfigMap do controlador NGINX Ingress diretamente correspondentes. Observe que vários nomes de chaves do ConfigMap são idênticos. Além disso, tanto o controlador Ingress da comunidade quanto o controlador Ingress NGINX têm chaves ConfigMaps que o outro não tem (não mostrado na tabela).
Você pode migrar do controlador Ingress da comunidade para o NGINX Ingress Controller usando recursos NGINX Ingress personalizados ou o recurso Ingress padrão do Kubernetes com anotações e ConfigMaps. A primeira opção oferece suporte a um conjunto mais amplo de recursos de rede e, portanto, é mais adequada para ambientes Kubernetes de nível de produção.
Esta postagem é um extrato do nosso e-book abrangente, Gerenciando o tráfego do Kubernetes com o F5 NGINX: Um guia prático . Baixe gratuitamente hoje mesmo .
Experimente o NGINX Ingress Controller baseado no NGINX Plus hoje mesmo em um teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso .
"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."