BLOG | NGINX

Anunciando o lançamento do NGINX Gateway Fabric 1.2.0

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Akash Ananthanarayanan
Akash Ananthanarayanan
Publicado em 29 de março de 2024
Miniatura de Mike Stefaniak
Mike Stefaniak
Publicado em 29 de março de 2024

Estamos felizes em compartilhar as últimas notícias sobre o NGINX Gateway Fabric, que é nossa implementação em conformidade com a API do Kubernetes Gateway. Recentemente, atualizamos para a versão 1.2.0, com vários novos recursos e melhorias interessantes. Esta versão se concentra em aprimorar os recursos da plataforma e garantir que ela atenda às demandas dos nossos usuários. Incluímos suporte ao F5 NGINX Plus e expandimos nossa superfície de API para cobrir os casos de uso mais demandados. Acreditamos que essas melhorias criarão uma melhor experiência para todos os nossos usuários e os ajudarão a atingir seus objetivos com mais eficiência.

Figura 1: Visão geral do design e da arquitetura do NGINX Gateway Fabric

Visão geral do NGINX Gateway Fabric 1.2.0:

  • Suporte ao NGINX Plus – O NGINX Gateway Fabric agora oferece suporte ao NGINX Plus para o plano de dados, o que oferece disponibilidade aprimorada, métricas detalhadas e painéis de observabilidade em tempo real.
  • BackendTLSPolicy – A verificação TLS permite que o NGINX Gateway Fabric confirme a identidade do aplicativo de backend, protegendo contra possível sequestro da conexão por aplicativos maliciosos. Além disso, o TLS criptografa o tráfego dentro do cluster, garantindo uma comunicação segura entre o cliente e o aplicativo de backend.
  • URLRewrite – O NGINX Gateway Fabric agora oferece suporte a reescritas de URL em objetos de rota. Com esse recurso, você pode modificar facilmente a URL da solicitação original e redirecioná-la para um destino mais apropriado. Dessa forma, à medida que seus aplicativos de backend passam por alterações de API, você pode manter as APIs que expõe aos seus clientes consistentes.
  • Telemetria de produto – Com a telemetria de produto agora presente no NGINX Gateway Fabric, podemos ajudar a melhorar ainda mais a eficiência operacional da sua infraestrutura, aprendendo sobre como você usa o produto em seu ambiente. Além disso, estamos planejando compartilhar esses insights regularmente com a comunidade durante nossas reuniões.

Analisaremos mais detalhadamente os novos recursos abaixo.

O que há de novo no NGINX Gateway Fabric 1.2.0?

Suporte NGINX Plus

A versão 1.2.0 do NGINX Gateway Fabric foi lançada com suporte ao NGINX Plus, oferecendo aos usuários muitos novos benefícios. Com a nova atualização, os usuários agora podem aproveitar os recursos avançados do NGINX Plus em suas implantações, incluindo métricas adicionais do Prometheus, recargas upstream dinâmicas e o painel do NGINX Plus. Esta atualização também permite que você obtenha suporte diretamente do NGINX para seu ambiente.

Métricas adicionais do Prometheus

Ao usar o NGINX Plus como seu plano de dados, métricas avançadas adicionais serão exportadas junto com as métricas que você normalmente obteria com o NGINX Open Source. Alguns destaques incluem métricas sobre solicitações http, fluxos, conexões e muito mais. Para obter a lista completa, você pode verificar o exportador Prometheus do NGINX para uma lista conveniente , mas observe que o exportador não é estritamente necessário para o NGINX Gateway Fabric. Com qualquer instalação do Prometheus ou do scraper compatível com o Prometheus, você pode extrair essas métricas para sua pilha de observabilidade e criar painéis e alertas usando uma camada consistente em sua arquitetura. As métricas do Prometheus estão automaticamente disponíveis no NGINX Gateway Fabric por meio da porta HTTP 9113. Você também pode alterar a porta padrão atualizando o modelo do Pod. Se você estiver procurando por uma configuração simples, visite nossa página do GitHub para obter mais informações sobre como implantar e configurar o Prometheus para começar a coletar. Como alternativa, se você quiser apenas visualizar as métricas e pular a configuração, você pode usar o painel do NGINX Plus, explicado na próxima seção. Após instalar o Prometheus no seu cluster, você pode acessar seu painel executando o encaminhamento de porta em segundo plano. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

Conexões Prometheus Graph com NGINX Gateway Fabric aceitas

Figura 2: Gráfico Prometheus mostrando conexões de NGINX Gateway Fabric aceitas


A configuração acima funcionará mesmo se você estiver usando o NGINX Open Source padrão como seu plano de dados também! No entanto, você não verá nenhuma das métricas adicionais fornecidas pelo NGINX Plus. À medida que o tamanho e o escopo do seu cluster aumentam, recomendamos analisar como as métricas do NGINX Plus podem ajudar a resolver rapidamente seus problemas de planejamento de capacidade, incidentes e até mesmo falhas de aplicativos de back-end.

Recargas dinâmicas de upstream

Recarregamentos upstream dinâmicos, habilitados pelo NGINX Gateway Fabric automaticamente quando instalados com o NGINX Plus, permitem que o NGINX Gateway Fabric faça atualizações nas configurações do NGINX sem um recarregamento do NGINX. Tradicionalmente, quando ocorre uma recarga do NGINX, as conexões existentes são manipuladas pelos antigos processos de trabalho, enquanto os novos processos de trabalho configurados manipulam os novos. Quando todas as conexões antigas são concluídas, os trabalhadores antigos são interrompidos e o NGINX continua apenas com os trabalhadores recém-configurados. Dessa forma, as alterações de configuração são tratadas com elegância, mesmo no NGINX Open Source. No entanto, quando o NGINX está sob alta carga, manter tanto os workers antigos quanto os novos pode criar uma sobrecarga de recursos que pode causar problemas, especialmente ao tentar executar o NGINX Gateway Fabric da forma mais enxuta possível. As recargas dinâmicas upstream apresentadas no NGINX Plus contornam esse problema ao fornecer um ponto de extremidade de API para alterações de configuração que o NGINX Gateway Fabric usará automaticamente se presentes, reduzindo a necessidade de sobrecarga de recursos extras para lidar com trabalhadores antigos e novos durante o processo de recarga. À medida que você começar a fazer alterações com mais frequência no NGINX Gateway Fabric, as recargas ocorrerão com mais frequência. Se você estiver curioso sobre a frequência ou quando as recargas ocorrem na sua instalação atual do NGF, você pode consultar a métrica do Prometheus nginx_gateway_fabric_nginx_reloads_total . Para uma análise completa e aprofundada do problema, confira o artigo de Nick Shadrin aqui ! Veja um exemplo da métrica em um ambiente com duas implantações do NGINX Gateway Fabric no painel do Prometheus:

Gráfico do Prometheus com o total de recargas do NGINX Gateway Fabric

Figura 3: Gráfico do Prometheus mostrando o total de recargas do NGINX Gateway Fabric

Painel NGINX Plus

Conforme mencionado anteriormente, se você estiver procurando uma maneira rápida de visualizar as métricas do NGINX Plus sem uma instalação do Prometheus ou uma pilha de observabilidade, o painel do NGINX Plus oferece monitoramento em tempo real das métricas de desempenho que você pode usar para solucionar incidentes e ficar de olho na capacidade dos recursos. O painel oferece diferentes visualizações para todas as métricas fornecidas pelo NGINX Plus imediatamente e é facilmente acessível em uma porta interna. Se você quiser dar uma olhada rápida em como são os recursos do painel, confira nosso site de demonstração do painel em demo.nginx.com . Para acessar o painel do NGINX Plus na sua instalação do NGINX Gateway Fabric, você pode encaminhar conexões para a porta 8765 na sua máquina local por meio do encaminhamento de porta: kubectl port-forward -n nginx-gateway 8765:8765 Em seguida, abra seu navegador preferido e digite http://localhost:8765/dashboard.html na barra de endereços.

Painel NGINX Plus

Figura 4: Visão geral do painel do NGINX Plus

Política TLS de Backend

Esta versão agora vem com o tão aguardado suporte para o BackendTLSPolicy . O BackendTLSPolicy introduz comunicação TLS criptografada entre o NGINX Gateway Fabric e o aplicativo, aumentando muito a segurança do canal de comunicação. Aqui está um exemplo que mostra como aplicar a política especificando configurações como cifras e protocolos TLS ao validar certificados de servidor em relação a uma autoridade de certificação (CA) confiável. O BackendTLSPolicy permite que os usuários protejam seu tráfego entre o NGF e seus backends. Você também pode definir a versão mínima do TLS e os conjuntos de criptografia. Isso protege contra aplicativos maliciosos que sequestram a conexão e criptografa o tráfego dentro do cluster. Para configurar a terminação TLS de backend, primeiro crie um ConfigMap com a certificação CA que você deseja usar. Para obter ajuda com o gerenciamento de certificados internos do Kubernetes, confira este guia .


tipo: ConfigMap
apiVersion: v1
metadados:
nome: backend-cert
dados:
ca.crt: 
< -----INÍCIO DO CERTIFICADO-----
-----FIM DO CERTIFICADO-----
>

Em seguida, criamos o BackendTLSPolicy, que tem como alvo nosso serviço secure-app e faz referência ao ConfigMap criado na etapa anterior:


apiVersion: gateway.networking.k8s.io/v1alpha2
tipo: BackendTLSPolicy
metadados:
nome: backend-tls
especificação:
targetRef:
grupo: ''
tipo: Serviço
nome: secure-app
namespace: default
tls:
caCertRefs:
- nome: backend-cert
grupo: ''
tipo: ConfigMap
nome do host: secure-app.example.com

Reescrever URL

Com um filtro URLRewrite, você pode modificar a URL original de uma solicitação recebida e redirecioná-la para uma URL diferente sem impacto algum no desempenho. Isso é particularmente útil quando seus aplicativos de backend alteram sua API exposta, mas você deseja manter a compatibilidade com versões anteriores para seus clientes existentes. Você também pode usar esse recurso para expor uma URL de API consistente para seus clientes enquanto redireciona as solicitações para diferentes aplicativos com diferentes URLs de API, fornecendo uma API de “experiência” que combina a funcionalidade de várias APIs diferentes para a conveniência e o desempenho de seus clientes. Para começar, vamos criar um gateway para a estrutura de gateway NGINX. Isso nos permitirá definir ouvintes HTTP e configurar a Porta 80 para desempenho ideal.


apiVersão: gateway.networking.k8s.io/v1
tipo: Gateway
metadados:
nome: cafe
especificação:
gatewayClassName: nginx
ouvintes:
-nome: http
porta: 80
protocolo: HTTP

Vamos criar um recurso HTTPRoute e configurar filtros de solicitação para reescrever quaisquer solicitações de /coffee para /beans. Também podemos fornecer um endpoint /latte que é reescrito para incluir o prefixo /latte para o backend manipular (“/latte/126” se torna “/126”).


apiVersão: gateway.networking.k8s.io/v1
tipo: HTTPRoute
metadados:
nome: café
especificação:
parentRefs:
-nome: café
sectionName: http
nomes de host:
-"cafe.example.com"
regras:
-correspondências:
-caminho:
tipo: PathPrefix
valor: /café
filtros:
- tipo: URLRewrite
urlRewrite:
caminho:
tipo: ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- nome: café
porta: 80
- correspondências:
- caminho:
tipo: PathPrefix
valor: /latte
filtros:
- tipo: URLRewrite
urlRewrite:
caminho:
tipo: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- nome: café
porta: 80

O recurso de reescrita HTTP ajuda a garantir flexibilidade entre os endpoints no lado do cliente e como eles são mapeados com o backend. Ele também permite o redirecionamento de tráfego de uma URL para outra, o que é particularmente útil ao migrar conteúdo para um novo site ou tráfego de API. Embora o NGINX Gateway Fabric suporte reescritas baseadas em caminho, atualmente ele não oferece suporte a redirecionamentos baseados em caminho. Informe-nos se esse é um recurso que você precisa para seu ambiente.

Telemetria de produtos

Decidimos incluir a telemetria do produto como um mecanismo para coletar feedback passivamente como parte da versão 1.2. Este recurso coletará uma variedade de métricas do seu ambiente e as enviará para nossa plataforma de coleta de dados a cada 24 horas. Nenhuma PII é coletada, e você pode ver a lista completa do que é coletado aqui . Estamos comprometidos em fornecer total transparência em relação à nossa funcionalidade de telemetria. Embora documentemos todos os campos que coletamos, e você possa validar o que coletamos pelo nosso código, você sempre tem a opção de desativá-lo completamente. Estamos planejando revisar regularmente observações interessantes com base nas estatísticas que coletamos com a comunidade em nossas reuniões comunitárias , então não deixe de comparecer!

Recursos

Para o changelog completo do NGINX Gateway Fabric 1.2.0, consulte as Notas de versão . Para experimentar o NGINX Gateway Fabric para Kubernetes com o NGINX Plus, comece hoje mesmo seu teste gratuito de 30 dias ou entre em contato conosco para discutir seus casos de uso . Se você quiser se envolver, ver o que está por vir ou ver o código-fonte do NGINX Gateway Fabric, confira nosso repositório no GitHub ! Temos reuniões comunitárias quinzenais às segundas-feiras às 9h, horário do Pacífico/17h, horário de Greenwich. O link da reunião, atualizações, pauta e notas estão no Calendário de Reuniões do NGINX Gateway Fabric . Os links também estão sempre disponíveis no nosso leia-me do GitHub.


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