BLOG | NGINX

Migrando do Community Ingress Controller para o F5 NGINX Ingress Controller

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Amir Rawdat Miniatura
Amir Rawdat
Publicado em 19 de maio de 2022

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:

Opção 1: Migrar usando recursos de entrada do NGINX

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.

Configurando a terminação SSL e o roteamento baseado em caminho HTTP

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
apiVersão: networking.k8s.io/v1kind: Ingress
metadados:
nome: nginx-test
especificação:
tls:
- hosts:
- foo.bar.com
secretName: tls-secret
regras:
- host: foo.bar.com
http:
caminhos:
- caminho: /login
backend:
serviceName: login-svc
servicePort: 80
- caminho: /faturamento
nome do serviço: faturamento-svc
porta do serviço: 80
apiVersão: networking.k8s.io/v1kind: VirtualServer
metadados:
nome: nginx-test
especificação:
host: foo.bar.com
tls:
secreto: tls-secret
upstreams:
-nome: login
serviço: login-svc
porta: 80
- nome: faturamento
serviço: faturamento-svc
porta: 80
rotas: 
- caminho: /login
ação:
senha: login 
- caminho: /faturamento 
ação: 
senha: faturamento

Configurando balanceamento de carga TCP/UDP e passagem TLS

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.

Converter anotações do controlador de entrada da comunidade em recursos de entrada do NGINX

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.

Implantações Canárias

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:

  1. nginx.ingress.kubernetes.io/canary-by-header
  2. nginx.ingress.kubernetes.io/canary-by-cookie
  3. 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
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"
correspondências :- condições: - cabeçalho: httpHeader valor: nunca ação: passar: eco - cabeçalho: httpHeader valor: sempre ação: passar: eco-canário ação: passar: eco
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader" nginx.ingress.kubernetes.io/canary-by-header-value: " meu-valor "
correspondências: - condições: - cabeçalho: httpHeader valor: my-value ação: pass: echo-canary ação: pass: echo
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"
correspondências:- condições:
- cookie: cookieName
valor: nunca
ação:
senha: eco 
- cookie: cookieName
valor: sempre
ação:
senha: eco-canário
ação:
senha: eco
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"
divisões :- peso: 90 ação: passe: eco - peso: 10 ação: passe: eco-canário

Controle de Tráfego

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
nginx.ingress.kubernetes.io/custom-http-errors: " código " nginx.ingress.kubernetes.io/default-backend: "default-svc"
errorPages :- códigos: [ código ] redirecionamento: código: 301 URL: padrão-svc
nginx.ingress.kubernetes.io/limit-connections: " número "
http-snippets : | limit_conn_zone $binary_remote_addr zone= zone_name : size ; routes: - path: / path location-snippets : | limit_conn zone_name number ;
nginx.ingress.kubernetes.io/limit-rate: " número " nginx.ingress.kubernetes.io/limit-rate-after: " número "
trechos de localização: | limit_rate número ; limit_rate_after número ;
nginx.ingress.kubernetes.io/limit-rpm: " número " nginx.ingress.kubernetes.io/limit-burst-multiplier: " multiplicador "
rateLimit : taxa: número r/m burst: número * chave multiplicadora : ${binary_remote_addr} zoneSize: tamanho
nginx.ingress.kubernetes.io/limit-rps: " número " nginx.ingress.kubernetes.io/limit-burst-multiplier: " multiplicador "
rateLimit: taxa: número r/s burst: número * chave multiplicadora : ${binary_remote_addr} zoneSize: tamanho
nginx.ingress.kubernetes.io/limit-whitelist: " CIDR "
http-snippets: | server-snippets : |
nginx.ingress.kubernetes.io/rewrite-target: " URI "
rewritePath: Caminho de reescrita : " URI "

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

Manipulação de Cabeçalho

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
nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-credentials: "true" nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" nginx.ingress.kubernetes.io/cors-allow-methods: "COLOCAR, OBTER, POSTAR, OPÇÕES" nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/cors-max-age: " segundos "
responseHeaders : adicionar: - nome: Valor Access-Control-Allow-Credentials: "true" - nome: Valor Access-Control-Allow-Headers: "X-Encaminhado-Para" - nome: Valor Access-Control-Allow-Methods: "COLOCAR, OBTER, POSTAR, OPÇÕES" - nome: Valor Access-Control-Allow-Origin: "*" - nome: Valor Access-Control-Max-Age: " segundos "

Proxy e balanceamento de carga

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
nginx.ingress.kubernetes.io/load-balance
método lb
nginx.ingress.kubernetes.io/proxy-buffering
bufferização
nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size
amortecedores
nginx.ingress.kubernetes.io/proxy-connect-timeout
tempo limite de conexão
nginx.ingress.kubernetes.io/proxy-next-upstream
próximo-a-montante
nginx.ingress.kubernetes.io/proxy-next-upstream-timeout
próximo-tempo-limite-de-upstream
nginx.ingress.kubernetes.io/proxy-read-timeout
tempo limite de leitura
nginx.ingress.kubernetes.io/proxy-send-timeout
tempo limite de envio
nginx.ingress.kubernetes.io/service-upstream
usar-cluster-ip

Autenticação mTLS

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

nginx.ingress.kubernetes.io/auth-tls-secret: nomeSecretário
nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
ingressMTLS : clientCertSecret: secretName verifyClient: "on" verifyDepth: 1
nginx.ingress.kubernetes.io/proxy-ssl-secret: "nomesecreto"
nginx.ingress.kubernetes.io/proxy-ssl-verify: "ligado|desligado"
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1" nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2"
nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "PADRÃO"
nginx.ingress.kubernetes.io/proxy-ssl-name: "nome-do-servidor"
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "ligado|desligado"
egressMTLS : tlsSecret: secretName verifyServer: true|false verifyDepth: 1 protocolos: Cifras TLSv1.2: PADRÃO sslName: nome-do-servidor Nome-do-servidor: true|false

Persistência de sessão (exclusivo para NGINX Plus)

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
nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/session-cookie-name: "cookieName" nginx.ingress.kubernetes.io/session-cookie-expires: " x " nginx.ingress.kubernetes.io/session-cookie-path: "/route" nginx.ingress.kubernetes.io/session-cookie-secure: "true"
sessionCookie : enable: true nome: cookieName expira: x h caminho: /route seguro: true

Opção 2: Migrar usando o recurso Ingress do Kubernetes

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.

Configuração avançada com anotações

A tabela a seguir descreve as anotações do controlador Ingress da comunidade que correspondem diretamente às anotações suportadas pelo NGINX Ingress Controller.

Controlador de entrada da comunidade NGINX Ingress Controller Diretiva NGINX
nginx.ingress.kubernetes.io/configuration-snippet : |
nginx.org/location-snippets : |
N/D
nginx.ingress.kubernetes.io/load-balance1
nginx.org/lb-método
Padrão:

 

aleatório dois least_conn
nginx.ingress.kubernetes.io/proxy-buffering : "ligado|desligado"
nginx.org/proxy-buffering : "Verdadeiro|Falso"
buffer_proxy
nginx.ingress.kubernetes.io/proxy-buffers-number : " número " nginx.ingress.kubernetes.io/proxy-buffer-size : " x k"
nginx.org/proxy-buffers : " número 4k|8k" nginx.org/proxy-buffer-size : "4k|8k"
proxy_buffers tamanho_do_buffer_proxy
nginx.ingress.kubernetes.io/proxy-connect-timeout : " segundos "
nginx.org/proxy-connect-timeout: : " segundos s"
tempo_limite_de_conexão_proxy
nginx.ingress.kubernetes.io/proxy-read-timeout : " segundos "
nginx.org/proxy-read-timeout : " segundos s"
tempo_limite_de_leitura_do_proxy
nginx.ingress.kubernetes.io/proxy-send-timeout : " segundos "
nginx.org/proxy-send-timeout : " segundos s"
tempo_limite_de_envio_proxy
nginx.ingress.kubernetes.io/rewrite-target : " URI "
nginx.org/rewrites : "serviceName= svc rewrite= URI "
reescrever
nginx.ingress.kubernetes.io/server-snippet : |
nginx.org/server-snippets : |
N/D
nginx.ingress.kubernetes.io/ssl-redirect : "verdadeiro|falso"
ingresso.kubernetes.io/ssl-redirect : "Verdadeiro|Falso"
N/D2

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
nginx.ingress.kubernetes.io/affinity : "cookie" nginx.ingress.kubernetes.io/session-cookie-name : " cookie_name " nginx.ingress.kubernetes.io/session-cookie-expires : " segundos " nginx.ingress.kubernetes.io/session-cookie-path : "/ route "
nginx.com/sticky-cookie-services : "serviceName= example-svc cookie_name expires= time path=/ route "

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).

Configuração global com ConfigMaps

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).

Controlador de entrada da comunidade NGINX Ingress Controller
desabilitar-log-de-acesso
acesso-log-off
nível de log de erro
nível de log de erro
hsts
hsts
hsts-inclui-subdomínios
hsts-inclui-subdomínios
hsts-idade-máxima
hsts-idade-máxima
trecho http
trechos http
manter-se vivo
tempo limite de manutenção de atividade
solicitações de manutenção de atividade
solicitações de keepalive
balanceamento de carga
método lb
trecho de localização
trechos de localização
log-format-escape-json : "verdadeiro"
log-format-escaping : "json"
fluxo de formato de log
formato de log de fluxo
formato-de-log-upstream
formato de log
trecho principal
trechos principais
max-trabalhadores-conexões 
conexões de trabalhadores
max-worker-arquivos-abertos
trabalhador-rlimit-nofile
tamanho do corpo proxy
tamanho-máximo-do-corpo-do-cliente
buffer de proxy
buffer de proxy
proxy-buffers-number : " número " proxy-buffer-size : " tamanho "
proxy-buffers : número tamanho
tempo limite de conexão proxy
tempo limite de conexão proxy
tempo limite de leitura do proxy
tempo limite de leitura do proxy
tempo limite de envio de proxy
tempo limite de envio de proxy
nome-do-servidor-hash-tamanho-do-bucket
nomes-de-servidores-hash-bucket-tamanho
nome-do-servidor-hash-tamanho-máximo
nomes-de-servidores-hash-tamanho-máximo
snippet do servidor
trechos do servidor
tokens de servidor
tokens de servidor
cifras ssl
cifras ssl
ssl-dh-param
arquivo ssl-dhparam
protocolos ssl
protocolos ssl
redirecionamento ssl
redirecionamento ssl
upstream-keepalive-conexões
manter vivo
usar-http2
http2
usar-protocolo-proxy
protocolo proxy
variáveis-hash-bucket-tamanho
variáveis-hash-bucket-tamanho
afinidade-cpu-trabalhador
afinidade-cpu-trabalhador
processos de trabalho
processos de trabalho
tempo limite de desligamento do trabalhador
tempo limite de desligamento do trabalhador

Resumo

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."