BLOG | NGINX

Controlador NGINX Ingress versão 2.0: O que você precisa saber

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Brian Ehlert Miniatura
Brian Ehlert
Publicado em 27 de dezembro de 2021

Em outubro, lançamos o F5 NGINX Ingress Controller versão 2.0 ( nginxinc/kubernetes-ingress ) , adicionando suporte ao Kubernetes 1.22 e à versão 1 da API Ingress ( networking.k8s.io/v1 ). Você deve estar se perguntando: e daí?

Esse “e daí” é matizado e responderemos a ele respondendo a três perguntas inter-relacionadas:

Continue lendo para obter as respostas e fique atento ao Seu plano de batalha para quando as versões do Kubernetes atacarem em 11 de janeiro de 2022 .

Por que os lançamentos do Kubernetes são tão importantes?

A resposta a essa pergunta é simples, mas complicada. O gerenciamento de compatibilidade para o Kubernetes é desafiador porque os operadores do Kubernetes precisam gerenciar três categorias de controle de versão:

  1. A plataforma Kubernetes em si – A cada novo lançamento, a equipe do Kubernetes para de manter uma versão mais antiga. Continuar usando essa versão é problemático para sua estratégia de gerenciamento de riscos e dificulta a solução de problemas porque a ajuda da equipe do Kubernetes não está mais disponível. Atualmente, o projeto Kubernetes mantém ramificações de lançamento para as três versões secundárias mais recentes (1.20, 1.21 e 1.22). O Kubernetes 1.19 e versões posteriores recebem aproximadamente 1 ano de suporte de patch, enquanto a versão 1.18 e versões anteriores recebem aproximadamente 9 meses de suporte de patch. (O menor período de tempo para a versão 1.18 e anteriores se deve ao fato de que o Kubernetes costumava lançar quatro versões por ano, em vez das três atuais).

  2. APIs do Kubernetes – Novas APIs nascem e as obsoletas são descontinuadas a cada lançamento do Kubernetes, e as alterações nas APIs impactam os recursos e ferramentas correspondentes. Ao atualizar sua plataforma Kubernetes, talvez seja necessário atualizar as APIs também.

  3. As ferramentas que você implantou no Kubernetes – Uma grande mudança no Kubernetes ou em suas APIs pode afetar se suas ferramentas – como um controlador Ingress – e os recursos correspondentes continuam funcionando corretamente.

Então você precisa rastrear três cronogramas: um para o Kubernetes, um para a API Ingress e um para o NGINX Ingress Controller. Para evitar quebrar o Kubernetes, você precisa encontrar o ponto ideal em que a versão do Kubernetes seja compatível com as APIs e o NGINX Ingress Controller. Atualizar qualquer um dos três componentes sem verificar a compatibilidade pode ter consequências drásticas. Se todos os três componentes não forem compatíveis entre si… parabéns, você quebrou seus aplicativos!

O que é a API Ingress e por que networking.k8s.io/v1 é importante?

A API do Ingress possibilita que um controlador do Ingress exponha com segurança seus aplicativos do Kubernetes. A API networking.k8s.io/v1 (também conhecida como A API Ingress v1) foi introduzida com o Kubernetes 1.19. Naquela época, o Kubernetes suportava tanto a v1beta1 quanto a v1 – e automaticamente apresentava uma versão como a outra. Essa compatibilidade “oculta” das versões da API beneficia você operacionalmente, mas pode atrapalhar seus esforços de planejamento.

Com o lançamento do Kubernetes 1.22, a v1 se tornou a única versão da API do Ingress. Isso é significativo porque, à medida que a API do Ingress v1 se torna "a única", todas as versões beta ( extensions/v1beta1 e networking.k8s.io/v1beta1 ) se tornam obsoletas. Embora isso seja prejudicial para organizações que ainda não adotaram a Ingress API v1, na NGINX vemos essa mudança como um bom sinal. A promoção da API Ingress de beta sinaliza a graduação para uma API madura e totalmente realizada. Agora, por que essa mudança importa? Bem, isso se relaciona com o gerenciamento de versões. Digamos que você atualize um cluster existente para o Kubernetes 1.22, mas continue usando recursos relacionados ao Ingress v1beta1 ... parabéns, você quebrou seus recursos do Ingress!

Como o NGINX Ingress Controller 2.0 afeta os clientes atuais?

Como o NGINX Ingress Controller é fortemente acoplado à API do Ingress, o lançamento da v1 nos impactou significativamente como produto — e também a vocês, nossos clientes — e é por isso que aumentamos o número da versão do NGINX Ingress Controller de 1. x para 2. x . Nós reestruturamos o NGINX Ingress Controller 2.0 para aproveitar a Ingress API v1, tornando-o totalmente compatível com o Kubernetes 1.22.

Se você usar o NGINX Ingress Controller, precisará tomar algumas ações dependentes da versão imediatamente para evitar interromper o Kubernetes, seus recursos do Ingress ou o NGINX Ingress Controller:

  • Kubernetes 1.18 e anteriores:

    • Certifique-se de usar o NGINX Ingress Controller 1.12 para poder aproveitar o conjunto de recursos mais completo disponível. (Ao atualizar para o NGINX Ingress Controller 2.0, você também precisará atualizar para o Kubernetes 1.19 ou posterior.)

    • Faça um plano para migrar para uma versão mais recente do Kubernetes (e do NGINX Ingress Controller) nos próximos meses, pois o Kubernetes 1.18 não terá suporte após o próximo lançamento do Kubernetes.

  • Kubernetes 1.19–1.21:

    • Atualize para o NGINX Ingress Controller 2.0.

    • Se você ainda não migrou seus recursos relacionados ao Ingress para networking.k8s.io/v1 (consulte as notas de versão do NGINX Ingress Controller 2.0 ), crie seu plano agora. O Kubernetes 1.19–1.21 oferece suporte a todas as versões atuais da API do Ingress ( v1beta1 s e v1 ), oferecendo a você a oportunidade de converter no local.

    • Se você ainda não fez isso, mova imediatamente seus recursos Ingress e IngressClass para networking.k8s.io/v1 .

      • Se você estiver usando a anotação obsoleta kubernetes.io/ingress.class em seus recursos do Ingress, recomendamos alternar para o campo ingressClassName .

      • Use nossa documentação e exemplos (disponíveis com networking.k8s.io/v1 e o campo ingressClassName do recurso Ingress) para planejar suas atualizações.

  • Kubernetes 1.22:

    • Certifique-se de que você já esteja executando o NGINX Ingress Controller 2.0, pois as versões anteriores do NGINX Ingress Controller não são compatíveis com o Kubernetes 1.22 e não oferecem suporte à Ingress API v1.

Uma (não tão) breve história do controlador de entrada NGINX

Desde seu primeiro lançamento em 2016, o NGINX Ingress Controller evoluiu de uma ferramenta incipiente para uma potência para redes Kubernetes. Aqui está uma olhada em sua evolução desde o lançamento até o presente.

2016 ( v0.5.0 )

O engenheiro do NGINX, Michael Pleshakov, publica a primeira entrada em nosso repositório GitHub ( nginxinc/kubernetes-ingress ) , tornando possível usar o NGINX e o F5 NGINX Plus como um controlador Kubernetes Ingress (KIC).

O NGINX Ingress Controller faz sua primeira aparição pública na KubeCon EU 2016 . Confira a gravação: Dia 1, Criando uma solução avançada de balanceamento de carga para Kubernetes com NGINX; KubeCon EU 2016 .

2017 ( v1.0.0 )

O projeto atinge a prontidão para produção, incluindo suporte essencial para JSON Web Tokens (JWTs) na versão baseada no NGINX Plus .

Na NGINX Conf 2017, Michael Pleshakov demonstra recursos de produção, incluindo balanceamento de carga avançado em Using NGINX Plus as an Ingress Controller for Load Balancing Applications on Kubernetes .

2018

O NGINX Ingress Controller apresenta grandes melhorias nas áreas de visibilidade, facilidade de uso e flexibilidade:

Na NGINX Conf 2018, Michael Pleshakov sobe ao palco para falar sobre o uso do NGINX como um controlador de entrada do Kubernetes , onde ele compartilha como implantar o controlador de entrada do NGINX com o Helm, configurar o balanceamento de carga HTTP e TCP/UDP, monitorar com o Prometheus e solucionar problemas.

2019

Lançamos nossa alternativa aos recursos padrão do Kubernetes Ingress, tornando mais fácil e confiável executar recursos avançados.

Em The Next Generation of NGINX Ingress Controller , Michael Pleshakov retorna à NGINX Conf 2019 para demonstrar VS/VSR para casos de uso, incluindo implantações azul-verde e testes A/B.

2020

Além de inúmeras melhorias nos recursos do NGINX Ingress, o tema principal deste ano é a integração com ferramentas do ecossistema e produtos NGINX.

Em Aplicativos de produção seguros com NGINX e OpenShift , o engenheiro de marketing técnico Amir Rawdat demonstra como usar o NGINX Ingress Operator, aproveitar o controle de acesso baseado em função (RBAC) para provisionamento multifuncional, proteger aplicativos em contêineres com o NGINX App Protect e validar clientes com JWTs.

2021

Segurança é um tema principal, juntamente com mais integrações de ecossistemas.

Em sua sessão NGINX Sprint 2.0 , Master Microservices with End-to-End Encryption , o engenheiro de software Aidan Carson demonstra como proteger a borda com o NGINX Ingress Controller, configurar o controle de acesso seguro entre serviços com o NGINX Service Mesh e usar ambos os produtos para proteger o tráfego de saída com mTLS.

Próximo passo: Experimente o NGINX Ingress Controller

Se você decidiu que um controlador Ingress de código aberto é a escolha certa para seus aplicativos, você pode começar rapidamente com o NGINX Open Source‑based NGINX Ingress Controller em nosso repositório GitHub .

Para grandes implantações de produção, esperamos que você experimente nosso controlador comercial NGINX Ingress baseado no NGINX Plus. Ele está disponível para um teste gratuito de 30 dias que inclui o NGINX App Protect.

Leia mais postagens de blog sobre F5 NGINX›

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