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

Brian EhlertDiretor de Gestão de Produtos

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). Talvez você esteja se perguntando: e daí?

A resposta para esse “e daí?” tem algumas nuances, e vamos explicá-la respondendo a três perguntas inter-relacionadas:

• Por que os lançamentos do Kubernetes são tão importantes?
• O que é a API Ingress e por que a atualização para networking.k8s.io/v1 é importante?
• Como o NGINX Ingress Controller 2.0 afeta os clientes atuais?

Continue lendo para conferir as respostas e acompanhe Seu plano de batalha para quando as versões do Kubernetes atacarem em 11 de janeiro de 2022.

Por que as versões do Kubernetes são tão importantes?

A resposta a essa pergunta é simples, mas ao mesmo tempo complexa. O gerenciamento de compatibilidade do Kubernetes é desafiador porque os operadores do Kubernetes precisam gerenciar três categorias de versionamento:

1. A própria plataforma Kubernetes – A cada nova versão, a equipe do Kubernetes deixa de oferecer manutenção para uma versão mais antiga. Continuar usando uma versão desse tipo é problemático para sua estratégia de gerenciamento de riscos e dificulta a solução de problemas, pois a ajuda da equipe do Kubernetes deixa de estar disponível. Atualmente, o projeto Kubernetes mantém ramificações de versão 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 a patches, enquanto a versão 1.18 e as anteriores receberam aproximadamente 9 meses de suporte a patches. (O período mais curto para a versão 1.18 e as anteriores se deve ao fato de que o Kubernetes costumava lançar quatro versões por ano, em vez das três atuais).
2. As APIs do Kubernetes – Novas APIs são criadas e as obsoletas são descontinuadas a cada versão do Kubernetes, e as alterações nas APIs afetam os recursos e as ferramentas correspondentes. Ao atualizar sua plataforma Kubernetes, talvez também seja necessário atualizar as APIs.
3. As ferramentas que você implantou no Kubernetes – Uma alteração significativa no Kubernetes ou em suas APIs pode afetar o funcionamento adequado das suas ferramentas – como um controlador de Ingress – e dos recursos correspondentes.

Portanto, você precisa acompanhar três cronogramas: um para o Kubernetes, um para a API Ingress e um para o NGINX Ingress Controller. Para evitar problemas no Kubernetes, é preciso encontrar o ponto ideal em que a versão do Kubernetes seja compatível com as APIs e com o NGINX Ingress Controller. Atualizar qualquer um dos três componentes sem verificar a compatibilidade pode ter consequências drásticas. Se 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 Ingress permite que um controlador Ingress exponha seus aplicativos Kubernetes com segurança. A API networking.k8s.io/v1 (também conhecida como API Ingress v1) foi introduzida no Kubernetes 1.19. Naquela época, o Kubernetes oferecia suporte tanto à v1beta1 quanto à v1 – e apresentava automaticamente uma versão como se fosse a outra. Essa compatibilidade de versões da API que ocorre nos bastidores traz benefícios operacionais, mas pode dificultar seus esforços de planejamento.

Com o lançamento do Kubernetes 1.22, v1 passou a ser a única versão da API Ingress. Isso é importante porque, à medida que a API Ingress v1 se torna “a versão oficial”, todas as versões beta (extensions/v1beta1 e networking.k8s.io/v1beta1) são descontinuadas. Embora isso cause transtornos para as organizações que ainda não adotaram a API Ingress v1, nós da NGINX vemos essa mudança como um bom sinal. A saída da API Ingress da fase beta indica que ela alcançou a maturidade e se tornou uma API plenamente desenvolvida. Mas por que essa mudança é importante? Bem, isso nos leva de volta ao gerenciamento de versões. Digamos que você atualize um cluster existente para o Kubernetes 1.22, mas continue usando recursos relacionados ao Ingress na versão v1beta1 … parabéns, você acabou de inutilizar seus recursos do Ingress!

Como o NGINX Ingress Controller 2.0 afeta os clientes atuais?

Como o NGINX Ingress Controller está fortemente vinculado à API Ingress, o lançamento da versão v1 teve um impacto significativo sobre o nosso produto – e também sobre vocês, nossos clientes –, por isso alteramos o número da versão do NGINX Ingress Controller de 1.x para 2.x. Reformulamos a arquitetura do NGINX Ingress Controller 2.0 para aproveitar a API Ingress v1, tornando-o totalmente compatível com o Kubernetes 1.22.

Se você usa o NGINX Ingress Controller, precisa tomar imediatamente algumas medidas específicas para cada versão a fim de evitar problemas no Kubernetes, nos seus recursos de Ingress ou no NGINX Ingress Controller:

• Kubernetes 1.18 e versões anteriores:
  • Certifique-se de usar o NGINX Ingress Controller 1.12 para aproveitar o conjunto mais completo de recursos disponíveis. (Ao atualizar para o NGINX Ingress Controller 2.0, você também precisará atualizar para o Kubernetes 1.19 ou posterior.)
  • Planeje a migração para uma versão mais recente do Kubernetes (e do NGINX Ingress Controller) nos próximos meses, pois o Kubernetes 1.18 deixará de ser compatível 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 é compatível com todas as versões atuais da API do Ingress (tanto as versões v1beta1 quanto a v1), permitindo que você faça a conversão no local.
  • Se ainda não tiver feito isso, migre imediatamente seus recursos Ingress e IngressClass para networking.k8s.io/v1.
    • Se você estiver usando a anotação obsoleta kubernetes.io/ingress.class nos seus recursos Ingress, recomendamos migrar 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 nem oferecem suporte à Ingress API v1.

Uma história (não tão) breve do NGINX Ingress Controller

Desde seu primeiro lançamento, em 2016, o NGINX Ingress Controller evoluiu de uma ferramenta incipiente para uma solução poderosa de rede para Kubernetes. Veja como ele evoluiu desde o lançamento até os dias atuais.

2016 (v0.5.0)

O engenheiro da NGINX Michael Pleshakov publica a primeira contribuição em nosso repositório do GitHub (nginxinc/kubernetes-ingress), possibilitando o uso do NGINX e do F5 NGINX Plus como controlador de Ingress do Kubernetes (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 o NGINX; KubeCon EU 2016.

2017 (v1.0.0)

O projeto atinge a maturidade necessária para uso em produção, incluindo suporte essencial a JSON Web Tokens (JWTs) na versão baseada no NGINX Plus.

Na NGINX Conf 2017, Michael Pleshakov demonstra recursos para ambientes de produção, incluindo balanceamento de carga avançado, em Como usar o NGINX Plus como controlador de Ingress para balancear a carga de aplicações no Kubernetes.

2018

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

• Maio (v1.2.0) – O projeto adota a nova API do NGINX Plus, e as imagens do nginx-ingress são transferidas para o NGINX Docker Hub. Esta versão estreia o suporte a gRPC, verificações passivas de integridade, charts do Helm e Prometheus.
• Agosto (v1.3.0) – Os clientes do NGINX Plus agora podem exportar métricas para o Prometheus e aproveitar as verificações ativas de integridade, e todos se beneficiam das melhorias nos charts do Helm, nos recursos de Ingress mescláveis e no gerenciamento simplificado de templates personalizados (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.3.0).
• Novembro (v1.4.0) – Foi adicionado suporte a TCP/UDP, possibilitando o gerenciamento de tráfego da Camada 4. Outros recursos incluem maior facilidade para desenvolver anotações personalizadas e suporte ao algoritmo de balanceamento de carga Aleatório com Duas Escolhas (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.4.0).

Na NGINX Conf 2018, Michael Pleshakov sobe ao palco para apresentar Como usar o NGINX como um controlador de entrada do Kubernetes, compartilhando como implantar o NGINX Ingress Controller 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 de Ingress do Kubernetes, tornando a implementação de funcionalidades avançadas mais fácil e confiável.

• Maio (v1.5.0) – Os recursos VirtualServer e VirtualServerRoute (VS/VSR) são apresentados como uma nova abordagem de configuração. VS/VSR são os primeiros recursos do NGINX Ingress, oferecendo um estilo de configuração nativo, com tipagem segura e indentação, que simplifica a implementação do balanceamento de carga do Ingress (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.5.0<.htmla>).
• Dezembro (v1.6.0) – A documentação é disponibilizada em docs.nginx.com. Os recursos VS/VSR passam a oferecer suporte mais avançado ao balanceamento de carga e ficam prontos para uso em produção. O suporte ao OpenTracing é adicionado para aprimorar o monitoramento e a depuração, assim como a capacidade de execução como um usuário que não seja root, a fim de aumentar a segurança (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.6.0).

Em A próxima geração do NGINX Ingress Controller, Michael Pleshakov retorna à NGINX Conf 2019 para demonstrar o uso de VS/VSR em casos como implantações blue-green e testes A/B.

2020

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

• Abril (v1.7.0) – Lançamos o NGINX Ingress Operator para oferecer uma maneira rápida, fácil e certificada de implantar o NGINX Ingress Controller em ambientes OpenShift 4.x. Os recursos do NGINX Ingress continuam a evoluir, com suporte a protocolos adicionais, circuit breakers e melhorias na validação e na geração de relatórios (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.7.0).
• Julho (v1.8.0) – A integração com o F5 NGINX App Protect WAF permite que os clientes implantem um WAF leve e flexível no mesmo contêiner que o controlador Ingress. Foi adicionada a personalização dos recursos do NGINX Ingress por meio de snippets ou modelos personalizados, e recursos como reescritas de URI e listas de controle de acesso oferecem um controle mais granular (consulte Anúncio do NGINX Ingress Controller para Kubernetes versão 1.8.0).
• Outubro (v1.9.0) – A integração com o F5 NGINX Service Mesh permite gerenciar o tráfego norte-sul e leste-oeste na mesma configuração. Painéis do Grafana foram adicionados para facilitar a visualização de dados históricos (consulte Anúncio do NGINX Ingress Controller versão 1.9.0).

Em Proteja aplicações em produção 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ções (RBAC) para o provisionamento multifuncional, proteger aplicações em contêineres com o NGINX App Protect e validar clientes com JWTs.

2021

A segurança é um tema central, juntamente com mais integrações ao ecossistema.

• Fevereiro (v1.10.0) – A autenticação OpenID Connect (OIDC) é a principal novidade, facilitando o uso da autenticação JWT para oferecer uma opção robusta de logon único (SSO) (consulte Logon único fácil e robusto com OpenID Connect e NGINX Ingress Controller).
• Março (v1.11.0) – Grandes melhorias nas políticas de WAF e balanceamento de carga oferecem mais recursos e flexibilidade, incluindo verificações de integridade e relatórios de status (consulte Balanceamento de carga TCP/UDP aprimorado e configuração de WAF com o NGINX Ingress Controller).
• Julho (v1.12.0) – Os destaques desta versão estão todos relacionados à facilidade de implantação. Além da compra pelo AWS Container Marketplace, agora é possível baixar imagens pré-compiladas do F5 Container Registry (consulte O NGINX está disponível no AWS Marketplace for Containers).
• Outubro (v2.0.3) – Embora não seja um grande marco em termos de recursos, esta versão representa um marco para a interoperabilidade com a API do Kubernetes e a evolução do objeto Ingress. Essa mudança significa que o NGINX Ingress Controller 2.0 (e versões posteriores) é compatível com o Kubernetes 1.19 e versões posteriores. O NGINX Ingress Controller 2.0 também é a única versão que pode ser implantada com o Kubernetes 1.22 e versões posteriores.

Em sua sessão no NGINX Sprint 2.0, Domine microsserviços com criptografia de ponta a ponta, 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 de Ingress de código aberto é a escolha certa para seus aplicativos, pode começar rapidamente a usar o NGINX Ingress Controller baseado no NGINX Open Source em nosso repositório no GitHub.

Para implantações de produção de grande porte, esperamos que você experimente nosso NGINX Ingress Controller comercial baseado no NGINX Plus. Ele está disponível para uma avaliação gratuita de 30 dias que inclui o NGINX App Protect.

Sobre o autor

Brian EhlertDiretor de Gestão de Produtos

Mais publicações de Brian Ehlert