Anunciando o NGINX Plus R16

[ngx_snippet nome='tabela-estilo-blog']
Temos o prazer de anunciar que o NGINX Plus Release 16 (R16) já está disponível. O lançamento de hoje é um dos mais importantes para o avanço da visão técnica do NGINX. Com o R16, o NGINX Plus agora funciona como uma única camada elástica de entrada e saída para todos os seus aplicativos. Isso significa que você pode consolidar a funcionalidade de um balanceador de carga, gateway de API e WAF em um único pacote de software que abrange qualquer nuvem.

Muitas empresas com as quais conversamos hoje têm cada um desses componentes, mas geralmente de fornecedores diferentes. Isso aumenta o custo e a complexidade, pois as equipes de operações precisam gerenciar cada solução pontual separadamente. Isso também reduz o desempenho e a confiabilidade, pois cada salto extra acrescenta latência e pontos de falha.

Com os novos recursos do NGINX Plus R16, você pode começar a consolidar e simplificar sua infraestrutura, caminhando em direção à arquitetura de uma camada de entrada/saída elástica para aplicativos legados e modernos. O NGINX Plus R16 inclui novos recursos de cluster, balanceamento de carga UDP aprimorado e mitigação de DDoS que o tornam uma substituição mais completa para o dispendioso hardware F5 BIG-IP e outras infraestruturas de balanceamento de carga. O novo suporte para limitação de taxa global torna o NGINX Plus uma alternativa leve para muitas soluções de gateway de API. Por fim, o novo suporte para balanceamento de carga Random with Two Choices torna o NGINX Plus a escolha ideal para balanceamento de carga de tráfego de microsserviços em ambientes escalonados ou distribuídos, como o Kubernetes.

Resumo dos novos recursos do NGINX Plus R16

Os novos recursos do NGINX Plus R16 incluem:

• Limitação de taxa com reconhecimento de cluster – No NGINX Plus R15, introduzimos o módulo de compartilhamento de estado , permitindo que os dados sejam sincronizados em um cluster NGINX Plus. Nesta versão, o compartilhamento de estado é estendido ao recurso de limitação de taxa , permitindo que você especifique limites de taxa globais em um cluster NGINX Plus. A limitação de taxa global é um recurso importante para gateways de API e é um caso de uso extremamente popular para o NGINX Plus.
• Armazenamento de chave-valor com reconhecimento de cluster – No NGINX Plus R13, introduzimos um armazenamento de chave-valor que pode ser usado, por exemplo, para criar uma lista de negação de endereço IP dinâmico ou gerenciar redirecionamentos HTTP . Nesta versão, o armazenamento de chave-valor agora pode ser sincronizado em um cluster e inclui um novo parâmetro de tempo limite , para que pares de chave-valor individuais possam ser removidos automaticamente. Com o novo suporte de sincronização, o armazenamento de chave-valor agora pode ser usado para fornecer mitigação dinâmica de DDoS , distribuir tokens de sessão autenticados ou criar um cache de conteúdo distribuído (CDN).
• Balanceamento de carga aleatório com duas opções – Ao agrupar balanceadores de carga, é importante usar um algoritmo de balanceamento de carga que não sobrecarregue inadvertidamente servidores de backend individuais. O balanceamento de carga aleatório com duas opções é extremamente eficiente para clusters dimensionados e será o método padrão na próxima versão do NGINX Ingress Controller para Kubernetes.
• Balanceamento de carga UDP aprimorado – No NGINX Plus R9, introduzimos pela primeira vez o balanceamento de carga UDP. Essa implementação inicial foi limitada a aplicativos UDP que esperam um único pacote UDP do cliente para cada interação com o servidor (como DNS e RADIUS). O NGINX Plus R16 pode manipular vários pacotes UDP do cliente, o que nos permite oferecer suporte a protocolos UDP mais complexos, como OpenVPN, voz sobre IP (VoIP) e infraestrutura de desktop virtual (VDI).
• Suporte ao AWS PrivateLink – O AWS PrivateLink é uma tecnologia da Amazon para criar túneis VPN seguros em uma Nuvem Privada Virtual. Com esta versão, agora você pode autenticar, rotear, balancear tráfego e otimizar o fluxo de tráfego dentro de um data center do AWS PrivateLink. Esta funcionalidade é construída sobre o novo suporte ao protocolo PROXY v2 .

Melhorias adicionais incluem suporte para tokens de sessão opacos do OpenID Connect, o módulo dinâmico Encrypted Session, atualizações para o módulo NGINX JavaScript e muito mais. O NGINX Plus R16 é baseado no NGINX Open Source 1.15.2 e inclui todos os recursos da versão de código aberto.

Durante o desenvolvimento do NGINX Plus R16 , também adicionamos uma série de melhorias significativas ao NGINX Ingress Controller oficial para Kubernetes, um caso de uso proeminente do NGINX Plus.

Saiba mais sobre o NGINX Plus R16 e tudo relacionado ao NGINX na NGINX Conf 2018 . Teremos sessões dedicadas, demonstrações e especialistas disponíveis para nos aprofundar em todos os novos recursos.

Mudanças importantes no comportamento

• As APIs Upstream Conf e Status, substituídas e obsoletas pela API unificada NGINX Plus , foram removidas. Em agosto de 2017, o NGINX Plus R13 introduziu a novíssima API NGINX Plus para reconfiguração dinâmica de grupos upstream e métricas de monitoramento, substituindo as APIs Upstream Conf e Status que implementavam essas funções anteriormente. Conforme anunciado na época , as APIs obsoletas continuaram disponíveis e com suporte por um período significativo de tempo, que agora acabou. Se sua configuração incluir as diretivas upstream_conf e/ou status , você deverá substituí-las pela diretiva api como parte da atualização para o R16.

  Para obter orientação e assistência na migração para a nova API NGINX Plus , consulte o guia de transição em nosso blog ou entre em contato com nossa equipe de suporte.

• Suporte descontinuado para versões de SO em fim de vida útil – O NGINX Plus não é mais suportado no Ubuntu 17.10 (Artful) , FreeBSD 10.3 ou FreeBSD 11.0.

  Para obter mais informações sobre as plataformas suportadas, consulte as especificações técnicas do NGINX Plus e dos módulos dinâmicos .

• O plug-in NGINX New Relic foi atualizado para usar a nova API NGINX Plus e agora é um projeto de código aberto. O plug-in atualizado funciona com todas as versões do NGINX Plus a partir da R13, mas não é mais suportado ou mantido pela NGINX, Inc.

Novos recursos em detalhes

Limitação de taxa com reconhecimento de cluster

O NGINX Plus R15 introduziu o módulo zone_sync que permite que o estado de tempo de execução seja compartilhado entre todos os nós do NGINX Plus em um cluster.

O primeiro recurso sincronizado foi a persistência da sessão de aprendizagem persistente . O NGINX Plus R16 estende o compartilhamento de estado ao recurso de limitação de taxa . Quando implantado em um cluster, o NGINX Plus agora pode aplicar um limite de taxa consistente às solicitações recebidas, independentemente do nó membro do cluster em que a solicitação chega. Comumente conhecido como limitação de taxa global , a aplicação de um limite de taxa consistente em um cluster é particularmente relevante para casos de uso de gateway de API, entregando APIs a um acordo de nível de serviço (SLA) que impede que os clientes excedam um limite de taxa especificado.

O compartilhamento de estado do NGINX Plus não requer nem faz uso de um nó primário – todos os nós são pares e trocam dados em uma topologia de malha completa. Um cluster de compartilhamento de estado NGINX Plus deve atender a três requisitos:

• Conectividade de rede entre todos os nós do cluster
• Relógios sincronizados
• Configuração em cada nó que habilita o módulo zone_sync , como no snippet a seguir.

fluxo { resolver 10.0.0.53 válido=20s; servidor { ouvir 10.0.0.1:9000; sincronização_de_zona ; servidor_de_sincronização_de_zona nginx-cluster.example.com:9000 resolver; } }

A diretiva zone_sync permite a sincronização de zonas de memória compartilhada em um cluster. A diretiva zone_sync_server identifica as outras instâncias do NGINX Plus no cluster. O NGINX Plus oferece suporte à descoberta de serviços DNS para que os nós do cluster possam ser identificados pelo nome do host, tornando a configuração idêntica em todos os nós. Observe que esta é uma configuração mínima, sem os controles de segurança necessários para implantação em produção. Para mais detalhes, consulte o anúncio do NGINX Plus R15 e a documentação de referência do módulo zone_sync .

Depois que essa configuração estiver em vigor em todos os nós, os limites de taxa poderão ser aplicados em um cluster simplesmente adicionando o novo parâmetro de sincronização à diretiva limit_req_zone . Com a configuração a seguir, o NGINX Plus impõe um limite de taxa de 100 solicitações por segundo para cada cliente, com base no endereço IP do cliente.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # Servidor com reconhecimento de cluster { listen 80; location / { limit_req zone=per_ip; # Aplicar limite de taxa aqui proxy_pass http://my_backend; } }

Além disso, a solução de cluster de compartilhamento de estado é independente da solução de alta disponibilidade baseada em keepalived para resiliência de rede. Portanto, diferentemente dessa solução, um cluster de compartilhamento de estado pode abranger locais físicos.

Armazenamento de valor-chave com reconhecimento de cluster

O NGINX Plus R13 introduziu um armazenamento de chave-valor leve na memória como um módulo NGINX nativo. Este módulo é fornecido com o NGINX Plus, permitindo que soluções que exigem armazenamento de banco de dados simples sejam configuradas sem instalar componentes de software adicionais. Além disso, o armazenamento de chave-valor é controlado pela API NGINX Plus para que as entradas possam ser criadas, modificadas e excluídas por meio de uma interface REST.

Os casos de uso para o armazenamento de chave-valor do NGINX Plus incluem lista de negação de endereço IP dinâmico , limitação de largura de banda dinâmica e armazenamento em cache de tokens de autenticação .

Com o NGINX Plus R16, o armazenamento de chave-valor agora reconhece o cluster para que as entradas sejam sincronizadas em todos os nós de um cluster. Isso significa que as soluções que usam o armazenamento de chave-valor NGINX Plus podem ser implantadas em todos os tipos de ambientes em cluster – ativo-passivo, ativo-ativo e também amplamente distribuídos.

Quanto aos outros recursos de reconhecimento de cluster, você configura a sincronização do armazenamento de chave-valor simplesmente adicionando o parâmetro sync à diretiva keyval_zone para um cluster que já foi configurado para compartilhamento de estado (com as diretivas zone_sync e zone_sync_server ).

O armazenamento de chave-valor também foi estendido com a capacidade de definir um valor de tempo limite para cada par de chave-valor adicionado ao armazenamento de chave-valor. Essas entradas expiram automaticamente e são removidas do armazenamento de chave-valor quando o período de tempo limite especificado expira. O parâmetro timeout é obrigatório ao configurar um armazenamento de chave-valor sincronizado.

Usando o NGINX Plus Key-Value Store para proteção dinâmica contra DDoS

Você pode combinar os novos recursos de cluster do NGINX Plus para criar uma solução sofisticada de proteção contra ataques DDoS. Quando um pool de instâncias do NGINX Plus é implantado em um cluster ativo-ativo ou distribuído em uma rede de longa distância, o tráfego malicioso pode chegar a qualquer uma dessas instâncias. Esta solução usa um limite de taxa sincronizado e um armazenamento de chave-valor sincronizado para responder dinamicamente a ataques DDoS e mitigar seus efeitos, conforme a seguir.

• Um limite de taxa com reconhecimento de cluster captura clientes que enviam mais de 100 solicitações por segundo, independentemente de qual nó NGINX Plus recebe a solicitação.
• Quando um cliente excede o limite de taxa, seu endereço IP é adicionado a um armazenamento de chave-valor “sin bin” ao fazer uma chamada para a API NGINX Plus . O sin bin é sincronizado no cluster.
• Outras solicitações de clientes no bin sin estão sujeitas a um limite de largura de banda muito baixo, independentemente de qual nó NGINX Plus as recebe. Limitar a largura de banda é preferível a rejeitar solicitações imediatamente, porque não sinaliza claramente ao cliente que a mitigação de DDoS está em vigor.
• Após dez minutos, o cliente é automaticamente removido da lixeira.

A configuração a seguir mostra uma implementação simplificada desta solução dinâmica de mitigação de DDoS.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Taxa com reconhecimento de cluster limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # "Sin bin" com reconhecimento de cluster com 
# TTL de 10 minutos
keyval $remote_addr $in_sinbin zone=sinbin; # Preencha $in_sinbin com 
# endereços IP de clientes correspondentes

server {
listen 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # Restringir largura de banda de clientes ruins
}

limit_req zone=per_ip; # Aplicar o limite de taxa aqui
error_page 429 = @send_to_sinbin; # Clientes excessivos são movidos para 
# este local
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # Define o URI do 
# "sin bin" key-val
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# diretivas para controlar o acesso à API
}
}

Balanceamento de carga aleatório com duas opções

É cada vez mais comum que ambientes de entrega de aplicativos e de API usem uma camada de balanceamento de carga dimensionada ou distribuída para receber solicitações de clientes e passá-las para um ambiente de aplicativo compartilhado. Quando vários balanceadores de carga passam solicitações para o mesmo conjunto de servidores de back-end, é importante usar um método de balanceamento de carga que não sobrecarregue inadvertidamente os servidores de back-end individuais.

Clusters NGINX Plus implantados em uma configuração ativa-ativa ou ambientes distribuídos com vários pontos de entrada são cenários comuns que podem desafiar os métodos tradicionais de balanceamento de carga porque cada balanceador de carga não pode ter conhecimento total de todas as solicitações que foram enviadas aos servidores de back-end.

O balanceamento de carga dentro de um cluster em contêiner tem as mesmas características de uma implantação ativa-ativa dimensionada. Os controladores de entrada do Kubernetes implantados em um conjunto de réplicas com várias instâncias do recurso de entrada também enfrentam o desafio de como distribuir efetivamente a carga para os pods que entregam cada um dos serviços no cluster.

A variação da carga de trabalho tem um grande impacto na eficácia do balanceamento de carga distribuído. Quando cada solicitação impõe a mesma carga no servidor de backend, medir a rapidez com que cada servidor respondeu às solicitações anteriores é uma maneira eficaz de decidir para onde enviar a próxima solicitação. Exclusivo do NGINX Plus é o método de balanceamento de carga Least Time , que faz exatamente isso. Mas quando a carga no servidor de backend é variável (porque inclui operações de leitura e gravação, por exemplo), o desempenho passado é um indicador ruim do desempenho futuro.

A maneira mais simples de balancear a carga em um ambiente distribuído é escolher um servidor de backend aleatoriamente. Com o tempo, a carga se estabiliza, mas é uma abordagem rudimentar que provavelmente enviará picos de tráfego para servidores individuais de tempos em tempos.

Uma variação simples do balanceamento de carga aleatório, mas que comprovadamente melhora a distribuição de carga, é selecionar dois servidores de backend aleatoriamente e então enviar a solicitação para aquele com a menor carga. O objetivo de comparar duas escolhas aleatórias é evitar tomar uma decisão ruim de balanceamento de carga, mesmo que a decisão tomada não seja a ideal. Ao evitar o servidor de backend com maior carga, cada balanceador de carga pode operar de forma independente e ainda evitar o envio de picos de tráfego para servidores de backend individuais. Como resultado, esse método tem os benefícios e a eficiência computacional do balanceamento de carga aleatório, mas com uma distribuição de carga comprovadamente melhor.

O NGINX Plus R16 apresenta dois novos métodos de balanceamento de carga: Aleatório e Aleatório com Duas Escolhas. Para o último, você pode especificar ainda qual métrica indicadora de carga o NGINX Plus compara para decidir qual dos dois backends selecionados receberá a solicitação. A tabela a seguir lista as métricas disponíveis.

* Todas as métricas baseadas em tempo são exclusivas do NGINX Plus

O snippet a seguir mostra um exemplo simples de configuração de balanceamento de carga Random with Two Choices com a diretiva random two ( HTTP , Stream ).

upstream my_backend { zone my_backend 64k; server 10.0.0.1; server 10.0.0.2; server 10.0.0.3; #... random two least_time=last_byte; # Escolha o tempo de resposta mais rápido entre duas escolhas aleatórias } server { listen 80; location / { proxy_pass http://my_backend; # Balanceamento de carga para o grupo upstream } }

Observe que o método Aleatório com Duas Escolhas é adequado apenas para ambientes distribuídos onde vários balanceadores de carga estão passando solicitações para o mesmo conjunto de backends. Não o utilize quando o NGINX Plus estiver implantado em um único host ou em uma implantação ativa-passiva. Nesses casos, o balanceador de carga único tem uma visão completa de todas as solicitações, e os métodos Round Robin, Least Connections e Least Time fornecem os melhores resultados.

Balanceamento de carga UDP aprimorado

O NGINX Plus R9 introduziu suporte para proxy e balanceamento de carga de tráfego UDP , permitindo que o NGINX Plus fique à frente de aplicativos UDP populares, como DNS, syslog, NTP e RADIUS, para fornecer alta disponibilidade e escalabilidade dos servidores de aplicativos. A implementação inicial foi limitada a aplicativos UDP que esperam um único pacote UDP do cliente para cada interação com o servidor.

Com o NGINX Plus R16 , vários pacotes de entrada são suportados, o que significa que aplicativos UDP mais complexos podem ser proxyados e ter carga balanceada. Isso inclui OpenVPN, VoIP, soluções de desktop virtual e sessões de Datagram Transport Layer Security (DTLS). Além disso, o processamento de todos os aplicativos UDP pelo NGINX Plus – simples ou complexos – também é significativamente mais rápido.

O NGINX Plus é o único balanceador de carga de software que balanceia a carga de quatro dos protocolos da Web mais populares – UDP, TCP, HTTP e HTTP/2 – na mesma instância e ao mesmo tempo.

Suporte ao Protocolo PROXY v2

O NGINX Plus R16 adiciona suporte ao cabeçalho do protocolo PROXY v2 (PPv2) e a capacidade de inspecionar valores de tipo-comprimento-valor (TLV) personalizados no cabeçalho.

O protocolo PROXY é usado por proxies da Camada 7, como o NGINX Plus e os balanceadores de carga da Amazon, para transmitir informações de conexão para servidores upstream localizados atrás de outro conjunto de proxies da Camada 7, ou dispositivos NAT. Isso é necessário porque algumas informações de conexão, como o endereço IP de origem e a porta, podem ser perdidas quando os proxies retransmitem conexões, e nem sempre é possível confiar na injeção de cabeçalho HTTP para transmitir essas informações. Versões anteriores do NGINX Plus suportavam o cabeçalho PPv1; o NGINX Plus R16 adiciona suporte ao cabeçalho PPv2.

Usando PPv2 com o Amazon Network Load Balancer

Um caso de uso para o cabeçalho PPv2 são conexões retransmitidas pelo Network Load Balancer (NLB) da Amazon, que podem parecer originadas de um endereço IP privado no balanceador de carga. O NLB prefixa cada conexão com um cabeçalho PPv2 que identifica o verdadeiro endereço IP de origem e a porta da conexão do cliente. A verdadeira fonte pode ser obtida da variável $proxy_protocol_addr , e você pode usar o módulo realip para substituir as variáveis de fonte internas do NGINX com os valores do cabeçalho PPv2.

Usando PPv2 com AWS PrivateLink

AWS PrivateLink é a tecnologia da Amazon para criar túneis VPN seguros em uma Nuvem Privada Virtual (VPC). Ele é comumente usado para publicar um serviço de provedor (em execução no VPC do provedor) e disponibilizá-lo para um ou mais VPCs do cliente. As conexões com o serviço do provedor se originam de um NLB em execução na VPC do provedor.

Em muitos casos, o Provider Service precisa saber de onde cada conexão se origina, mas o endereço IP de origem no cabeçalho PPv2 é essencialmente sem sentido, correspondendo a um endereço interno e não roteável no Client VPC. O AWS PrivateLink NLB adiciona o ID do VPC de origem ao cabeçalho usando o registro PPv2 TLV 0xEA .

O NGINX Plus pode inspecionar registros PPv2 TLV e extrair o ID da VPC de origem para conexões AWS PrivateLink usando a variável $proxy_protocol_tlv_0xEA . Isso possibilita autenticar, rotear e controlar o tráfego em um data center do AWS PrivateLink.

Outros novos recursos no NGINX Plus R16

Tokens de sessão opacos OpenID Connect

A implementação de referência do NGINX Plus OpenID Connect foi estendida para oferecer suporte a tokens de sessão opacos. Nesse caso de uso, o token de identidade JWT não é enviado ao cliente. Em vez disso, ele é armazenado no repositório de chave-valor do NGINX Plus e uma sequência aleatória é enviada em seu lugar. Quando o cliente apresenta a string aleatória, ela é trocada pelo JWT e validada. Este caso de uso foi atualizado de protótipo/experimental para nível de produção, agora que as entradas no armazenamento de chave-valor podem ter um valor de tempo limite e ser sincronizadas em um cluster.

Módulo Dinâmico de Sessão Criptografada

O módulo da comunidade Encrypted Session fornece suporte de criptografia e descriptografia para variáveis NGINX com base em AES‑256 com MAC. Ele agora está disponível no repositório NGINX Plus como um módulo dinâmico suportado para NGINX Plus .

Melhorias no módulo JavaScript do NGINX

Os módulos JavaScript do NGINX no R16 incluem uma série de extensões ao escopo de suporte à linguagem JavaScript. O módulo HTTP JavaScript foi simplificado para que um único objeto ( r ) agora acesse os atributos de solicitação e resposta associados a cada solicitação. Anteriormente, havia objetos de solicitação ( req ) e resposta ( res ) separados. Essa simplificação torna o módulo HTTP JavaScript consistente com o módulo Stream JavaScript que tem um único objeto de sessão( s ). Essa alteração é totalmente compatível com versões anteriores – o código JavaScript existente continuará funcionando como está – mas recomendamos que você modifique o código JavaScript existente para aproveitar essa simplificação, bem como usá-lo no código que você escrever no futuro.

O suporte à linguagem JavaScript agora inclui:

• Métodos de string: bytesFrom () , padStart() e padEnd()
• Métodos adicionais: getrandom() e getentropy()
• Literais binários

A lista completa de alterações no módulo JavaScript está documentada no changelog .

Nova variável $ssl_preread_protocol

A nova variável $ssl_preread_protocol permite que você diferencie entre SSL/TLS e outros protocolos ao encaminhar tráfego usando um proxy TCP (stream). A variável contém a versão mais alta do protocolo SSL/TLS suportada pelo cliente. Isso é útil se você quiser evitar restrições de firewall (por exemplo) executando serviços SSL/TLS e SSH na mesma porta.

Para mais detalhes, consulte Executando protocolos SSL e não SSL na mesma porta em nosso blog.

Melhorias no controlador de entrada do Kubernetes

O NGINX Plus pode gerenciar tráfego em uma ampla variedade de ambientes, e um caso de uso significativo é como um balanceador de carga de entrada para Kubernetes . A NGINX desenvolve uma solução de controlador Ingress que configura automaticamente o NGINX Plus, e essa integração é totalmente suportada por todos os assinantes do NGINX Plus. (Todos os usuários do NGINX Open Source e clientes do NGINX Plus podem encontrar a implementação de código aberto no GitHub, e lançamentos formais são feitos periodicamente.)

Durante o desenvolvimento do NGINX Plus R16 , uma série de melhorias significativas foram adicionadas ao NGINX Ingress Controller oficial para Kubernetes:

• O suporte do Prometheus permite que os usuários exportem métricas do NGINX e do NGINX Plus diretamente para o Prometheus no Kubernetes.
• O suporte para gráficos Helm simplifica a instalação e o gerenciamento do controlador Ingress.
• O suporte para balanceamento de carga de tráfego gRPC fornece alta disponibilidade e escalabilidade para aplicativos baseados em gPRC. (Adicionado na versão 1.2.0.)
• Verificações de integridade ativas de pods do Kubernetes detectam rapidamente falhas em pods e na conectividade de rede.
• A configuração multilocatário e mesclável permite a separação de preocupações, permitindo que as equipes gerenciem de forma independente diferentes caminhos do mesmo aplicativo da Web, enquanto as operações mantêm o controle do ouvinte de front-end e da configuração SSL.
• A autenticação JWT detalhada , por caminho, oferece controle mais profundo sobre a autenticação para aplicativos avançados.
• O gerenciamento direto de modelos de configuração torna muito mais fácil desenvolver e testar alterações personalizadas na configuração do NGINX.

O NGINX Ingress Controller pode ser estendido ainda mais usando ConfigMaps (para incorporar a configuração do NGINX) ou por meio da edição dos modelos base , permitindo que os usuários acessem todos os recursos do NGINX ao criar políticas de gerenciamento de tráfego para seus aplicativos em execução no Kubernetes.

Para mais detalhes, consulte Anunciando o NGINX Ingress Controller para Kubernetes versão 1.3.0 em nosso blog.

Atualize ou experimente o NGINX Plus

O NGINX Plus R16 inclui recursos adicionais de clustering, limitação de taxa global, um novo algoritmo de balanceamento de carga e diversas correções de bugs . Se você estiver executando o NGINX Plus, recomendamos fortemente que atualize para o R16 o mais rápido possível. Você receberá uma série de correções e melhorias, e isso ajudará a NGINX, Inc. a ajudá-lo quando precisar abrir um tíquete de suporte.

Revise cuidadosamente os novos recursos e mudanças de comportamento descritos nesta postagem do blog antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus , recomendamos que experimente – para aceleração web, balanceamento de carga e entrega de aplicativos, ou como um servidor web totalmente suportado com APIs aprimoradas de monitoramento e gerenciamento. Você pode começar hoje mesmo com um teste gratuito de 30 dias . Veja você mesmo como o NGINX Plus pode ajudar você a entregar e dimensionar seus aplicativos.