Anunciando o NGINX Plus R16

Liam CrillyDiretor Sênior de Gestão de Produtos

[ngx_snippet name=’table-style-blog’]
Temos o prazer de anunciar que o NGINX Plus Release 16 (R16) já está disponível. A versão lançada hoje é uma das mais importantes para o avanço da visão técnica da NGINX. Com o R16, o NGINX Plus passa a funcionar como uma camada única e elástica de entrada e saída para todas as suas aplicações. Isso significa que você pode consolidar as funcionalidades de um balanceador de carga, um gateway de API e um WAF em um único pacote de software compatível com qualquer nuvem.

Muitas das empresas com as quais conversamos atualmente têm cada um desses componentes, mas geralmente de fornecedores diferentes. Isso aumenta os custos e a complexidade, pois as equipes de operações precisam gerenciar cada solução pontual separadamente. Também reduz o desempenho e a confiabilidade, já que cada salto adicional aumenta a latência e os pontos de falha.

Com os novos recursos do NGINX Plus R16, você pode começar a consolidar e simplificar sua infraestrutura, avançando em direção à criação de uma camada elástica de entrada/saída para aplicações legadas e modernas. O NGINX Plus R16 inclui novos recursos de clustering, balanceamento de carga UDP aprimorado e mitigação de DDoS, que o tornam uma alternativa mais completa aos dispendiosos equipamentos F5 BIG-IP e a outras infraestruturas de balanceamento de carga. O novo suporte à limitação global de taxa também torna o NGINX Plus uma alternativa leve a muitas soluções de gateway de API. Por fim, o novo suporte ao balanceamento de carga Random with Two Choices torna o NGINX Plus a escolha ideal para balancear o tráfego de microsserviços em ambientes escaláveis 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, que permite sincronizar dados em um cluster do NGINX Plus. Nesta versão, o compartilhamento de estado foi estendido ao recurso de limitação de taxa, permitindo definir limites de taxa globais em um cluster do NGINX Plus. A limitação de taxa global é um recurso importante para gateways de API e um caso de uso extremamente popular do 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 dinâmica de bloqueio de endereços IP ou gerenciar redirecionamentos HTTP. Nesta versão, o armazenamento de chave-valor agora pode ser sincronizado em todo o cluster e inclui um novo parâmetro timeout, permitindo que pares individuais de chave-valor sejam removidos automaticamente. Com o novo suporte à sincronização, o armazenamento de chave-valor agora pode ser usado para oferecer mitigação dinâmica de DDoS, distribuir tokens de sessão autenticados ou criar uma rede distribuída de entrega de conteúdo (CDN).
• Balanceamento de carga Random with Two Choices – Ao agrupar balanceadores de carga em clusters, é importante usar um algoritmo de balanceamento de carga que não sobrecarregue inadvertidamente servidores de backend individuais. O balanceamento de carga Random with Two Choices é extremamente eficiente para clusters escaláveis e será o método padrão na próxima versão do NGINX Ingress Controller for Kubernetes.
• Balanceamento de carga UDP aprimorado – No NGINX Plus R9, introduzimos pela primeira vez o balanceamento de carga UDP. Essa implementação inicial era limitada a aplicações 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 processar vários pacotes UDP do cliente, permitindo oferecer suporte a protocolos UDP mais complexos, como OpenVPN, voz sobre IP (VoIP) e infraestrutura de desktop virtual (VDI).
• Suporte ao AWS PrivateLink – AWS PrivateLink é a tecnologia da Amazon para criar túneis VPN seguros para uma nuvem privada virtual. Com esta versão, agora você pode autenticar, rotear e balancear a carga do tráfego, além de otimizar o fluxo do tráfego em um data center do AWS PrivateLink. Essa funcionalidade se baseia no novo suporte ao protocolo PROXY v2.

Aprimoramentos adicionais incluem suporte a tokens opacos de sessão do OpenID Connect, ao módulo dinâmico Encrypted Session, atualizações do 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 várias melhorias significativas ao NGINX Ingress Controller oficial para Kubernetes, um importante caso de uso 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 à disposição para apresentar em detalhes todos os novos recursos.

Mudanças importantes de comportamento

• As APIs Upstream Conf e Status, substituídas e descontinuadas pela API unificada do NGINX Plus, foram removidas. Em agosto de 2017, o NGINX Plus R13 apresentou a nova API do NGINX Plus para reconfiguração dinâmica de grupos upstream e monitoramento de métricas, substituindo as APIs Upstream Conf e Status, que anteriormente implementavam essas funções. Conforme anunciado na época, as APIs descontinuadas continuaram disponíveis e com suporte por um período considerável, que agora chegou ao fim. Se a sua configuração incluir as diretivas upstream_conf e/ou status, você deverá substituí-las pela diretiva api como parte da atualização para a R16. Para obter orientações e assistência na migração para a nova API do 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 sistemas operacionais que chegaram ao fim da vida útil – O NGINX Plus não é mais compatível com Ubuntu 17.10 (Artful), FreeBSD 10.3 ou FreeBSD 11.0. Para obter mais informações sobre as plataformas compatíveis, 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 do 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 conta mais com suporte nem manutenção da 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 compartilhar o estado de execução entre todos os nós do NGINX Plus em um cluster.

O primeiro recurso sincronizado foi a persistência de sessão sticky‑learn. 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 uniforme às solicitações recebidas, independentemente do nó do cluster ao qual a solicitação chega. Conhecida como limitação de taxa global, a aplicação de um limite de taxa uniforme em todo o cluster é particularmente relevante para casos de uso de gateway de API, permitindo disponibilizar APIs de acordo com um contrato de nível de serviço (SLA) que impede os clientes de exceder um limite de taxa especificado.

O compartilhamento de estado do NGINX Plus não exige nem utiliza 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 do 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 habilite o módulo zone_sync, como no trecho a seguir.

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

The zone_sync directive enables synchronization of shared memory zones in a cluster. The zone_sync_server directive identifies the other NGINX Plus instances in the cluster. NGINX Plus supports DNS service discovery so cluster nodes can be identified by hostname, making the configuration identical on all nodes. Note that this is a minimal configuration, without the necessary security controls for production deployment. For more details, see the NGINX Plus R15 announcement and the reference documentation for the zone_sync module.

Depois que essa configuração estiver implementada em todos os nós, os limites de taxa poderão ser aplicados em todo o cluster simplesmente adicionando o novo parâmetro sync à 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 a cada cliente, com base no endereço IP do cliente.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        proxy_pass http://my_backend;
    }
}

Além disso, a solução de cluster com compartilhamento de estado é independente da keepalivedsolução de alta disponibilidade baseada em para resiliência da rede. Portanto, ao contrário dessa solução, um cluster com compartilhamento de estado pode abranger diferentes locais físicos.

Armazenamento de chave-valor com reconhecimento de cluster

O NGINX Plus R13 introduziu um armazenamento de chave-valor leve e em memória como um módulo nativo do NGINX. Esse módulo acompanha o NGINX Plus, permitindo configurar soluções que exigem armazenamento simples de banco de dados sem instalar componentes de software adicionais. Além disso, o armazenamento de chave-valor é controlado pela API do NGINX Plus, permitindo criar, modificar e excluir entradas por meio de uma interface REST.

Os casos de uso do armazenamento de chave-valor do NGINX Plus incluem a inclusão dinâmica de endereços IP em listas de bloqueio, a limitação dinâmica de largura de banda, e o armazenamento em cache de tokens de autenticação.

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

Assim como ocorre com os outros recursos compatíveis com clusters, para configurar a sincronização do armazenamento de chave-valor, basta adicionar o parâmetro sync à diretiva keyval_zone de um cluster que já tenha sido configurado para compartilhamento de estado (com as diretivas zone_sync e zone_sync_server).

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

Como usar o armazenamento de chave-valor do NGINX Plus para proteção dinâmica contra DDoS

Você pode combinar os novos recursos de clustering do NGINX Plus para criar uma solução sofisticada de proteção contra ataques DDoS. Quando um conjunto de instâncias do NGINX Plus é implantado em um cluster ativo-ativo ou distribuído por uma rede de longa distância, o tráfego mal-intencionado pode chegar a qualquer uma dessas instâncias. Essa 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 descrito a seguir.

• Um limite de taxa com reconhecimento de cluster identifica clientes que enviam mais de 100 solicitações por segundo, independentemente de qual nó do 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 de “quarentena” por meio de uma chamada à API do NGINX Plus. A quarentena é sincronizada em todo o cluster.
• As solicitações subsequentes de clientes na lista de bloqueio ficam sujeitas a um limite de largura de banda muito baixo, independentemente de qual nó do NGINX Plus as receba. Limitar a largura de banda é preferível a rejeitar as solicitações de imediato, pois isso não deixa claro para o cliente que a mitigação de DDoS está em vigor.
• Após dez minutos, o cliente é removido automaticamente da lista de bloqueio.

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

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "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;
        # directives to control access to the API
    }
}

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

É cada vez mais comum que os ambientes de entrega de aplicações e de APIs usem uma camada de balanceamento de carga escalável ou distribuída para receber solicitações de clientes e encaminhá-las a um ambiente de aplicações compartilhado. Quando vários balanceadores de carga encaminham solicitações ao mesmo conjunto de servidores de backend, é importante usar um método de balanceamento de carga que não sobrecarregue inadvertidamente servidores de backend específicos.

Clusters do NGINX Plus implantados em uma configuração ativo-ativo, 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, pois cada balanceador de carga não tem conhecimento completo de todas as solicitações enviadas aos servidores de backend.

O balanceamento de carga dentro de um cluster em contêineres apresenta as mesmas características de uma implantação ativa-ativa com escalabilidade horizontal. Os controladores Ingress do Kubernetes implantados em um conjunto de réplicas com várias instâncias do recurso Ingress também enfrentam o desafio de distribuir a carga de forma eficiente entre os pods que fornecem cada um dos serviços no cluster.

Topologias de cluster que se beneficiam do balanceamento de carga Aleatório com Duas Escolhas

A variação da carga de trabalho tem um enorme impacto na eficácia do balanceamento de carga distribuído. Quando cada solicitação impõe a mesma carga ao 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 faz exatamente isso. Porém, quando a carga no servidor de backend é variável (por incluir operações de leitura e gravação, por exemplo), o desempenho passado é um indicador pouco confiável do desempenho futuro.

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

Uma variação simples do balanceamento de carga aleatório, mas que comprovadamente melhora a distribuição da carga, consiste em selecionar aleatoriamente dois servidores de backend e enviar a solicitação para aquele com a menor carga. O objetivo de comparar duas opções aleatórias é evitar 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 a maior carga, cada balanceador de carga pode operar de forma independente e, ainda assim, evitar o envio de picos de tráfego para servidores de backend específicos. Como resultado, esse método oferece os benefícios e a eficiência computacional do balanceamento de carga aleatório, mas com uma distribuição de carga comprovadamente melhor.

NGINX Plus R16 apresenta dois novos métodos de balanceamento de carga: Aleatório e Aleatório com Duas Opções. Para o segundo método, você também pode especificar qual métrica indicativa de carga o NGINX Plus compara para decidir qual dos dois backends selecionados recebe 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 trecho 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; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

Observe que o método Aleatório com Duas Escolhas é adequado apenas para ambientes distribuídos nos quais vários balanceadores de carga encaminham 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 único balanceador de carga tem uma visão completa de todas as solicitações, e os métodos Round Robin, Menor Número de Conexões e Menor Tempo oferecem os melhores resultados.

Balanceamento de carga UDP aprimorado

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

Com o NGINX Plus R16, há suporte a vários pacotes de entrada, o que permite usar proxy e balanceamento de carga em aplicações UDP mais complexas. Entre elas estão OpenVPN, VoIP, soluções de desktop virtual e sessões de Datagram Transport Layer Security (DTLS). Além disso, o processamento de todas as aplicações UDP pelo NGINX Plus — sejam elas simples ou complexas — também é significativamente mais rápido.

O NGINX Plus é o único balanceador de carga de software que distribui a carga entre quatro dos protocolos 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 passa a oferecer suporte ao cabeçalho do protocolo PROXY v2 (PPv2), além da capacidade de inspecionar valores personalizados de tipo-comprimento-valor (TLV) no cabeçalho.

O protocolo PROXY é usado por proxies de camada 7, como o NGINX Plus e os balanceadores de carga da Amazon, para transmitir informações de conexão a servidores upstream localizados atrás de outro conjunto de proxies de camada 7 ou de dispositivos NAT. Isso é necessário porque algumas informações de conexão, como o endereço IP e a porta de origem, podem ser perdidas quando os proxies retransmitem conexões, e nem sempre é possível recorrer à inserção de cabeçalhos HTTP para transmitir essas informações. As versões anteriores do NGINX Plus eram compatíveis com o cabeçalho PPv1; o NGINX Plus R16 adiciona compatibilidade com o cabeçalho PPv2.

Como usar o PPv2 com o Amazon Network Load Balancer

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

Como usar o PPv2 com o AWS PrivateLink

AWS PrivateLink é a tecnologia da Amazon para criar túneis VPN seguros em uma nuvem privada virtual (VPC). Ela é comumente usada para publicar um serviço de provedor (em execução na VPC do provedor) e disponibilizá-lo para uma ou mais VPCs de clientes. As conexões com o serviço de provedor são originadas de um NLB em execução na VPC do provedor.

Em muitos casos, o Serviço do Provedor precisa saber a origem de cada conexão, mas o endereço IP de origem no cabeçalho PPv2 é praticamente irrelevante, pois corresponde a um endereço interno e não roteável na VPC do Cliente. O NLB do AWS PrivateLink adiciona o ID da VPC de origem ao cabeçalho usando o registro TLV do PPv2 0xEA.

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

Outros novos recursos do NGINX Plus R16

Tokens de sessão opacos do OpenID Connect

A implementação de referência do OpenID Connect do NGINX Plus foi ampliada 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 string aleatória é enviada em seu lugar. Quando o cliente apresenta a string aleatória, ela é trocada pelo JWT e validada. Esse caso de uso passou de protótipo/experimental para nível de produção, agora que as entradas no repositório 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 oferece suporte à criptografia e descriptografia de variáveis do NGINX com base em AES‑256 com MAC. Agora, ele está disponível no repositório do NGINX Plus como um módulo dinâmico compatível com o NGINX Plus.

Aprimoramentos do módulo JavaScript do NGINX

Os módulos JavaScript do NGINX no R16 incluem várias extensões ao escopo do 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 separados para solicitação (req) e resposta (res). 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 retrocompatível – o código JavaScript existente continuará funcionando sem alterações –, mas recomendamos que você modifique o código JavaScript existente para aproveitar essa simplificação e também a utilize no código que escrever futuramente.

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 registro de alterações.

Nova variável $ssl_preread_protocol Variable

A nova variável $ssl_preread_protocol permite distinguir entre SSL/TLS e outros protocolos ao encaminhar tráfego usando um proxy TCP (stream). A variável contém a versão mais recente do protocolo SSL/TLS compatível com o cliente. Isso é útil para evitar restrições de firewall, por exemplo, executando serviços SSL/TLS e SSH na mesma porta.

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

Aprimoramentos do Kubernetes Ingress Controller

O NGINX Plus pode gerenciar o tráfego em uma ampla variedade de ambientes, e um caso de uso importante é como um balanceador de carga de entrada para Kubernetes. A NGINX desenvolve uma solução de controlador de entrada que configura automaticamente o NGINX Plus, e essa integração conta com suporte completo para 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 versões oficiais são lançadas periodicamente.)

O NGINX Plus pode encerrar SSL, rotear e balancear a carga do tráfego do Kubernetes

Durante o desenvolvimento do NGINX Plus R16, várias melhorias significativas foram adicionadas ao NGINX Ingress Controller oficial para Kubernetes:

• Suporte ao Prometheus permite que os usuários exportem métricas do NGINX e do NGINX Plus diretamente para o Prometheus no Kubernetes.
• O suporte a charts do Helm simplifica a instalação e o gerenciamento do controlador Ingress.
• Suporte ao balanceamento de carga do tráfego gRPC oferece alta disponibilidade e escalabilidade para aplicações baseadas em gPRC. (Adicionado na versão 1.2.0.)
• As verificações ativas de integridade dos pods do Kubernetes detectam rapidamente falhas nos pods e na conectividade de rede.
• Configuração multilocatário e mesclável permite a separação de responsabilidades, possibilitando que as equipes gerenciem de forma independente diferentes caminhos da mesma aplicação web, enquanto a equipe de operações mantém o controle sobre o listener de frontend e a configuração de SSL.
• Autenticação JWT granular, aplicada individualmente a cada caminho, oferece maior controle sobre a autenticação em aplicações avançadas.
• O gerenciamento direto de modelos de configuração facilita muito o desenvolvimento e o teste de alterações personalizadas na configuração do NGINX.

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

Para mais detalhes, consulte Anúncio do 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 global de taxa, um novo algoritmo de balanceamento de carga e várias correções de bugs. Se você estiver usando o NGINX Plus, recomendamos enfaticamente que faça a atualização para a R16 o mais rápido possível. Você terá acesso a diversas correções e melhorias, além de facilitar o suporte da NGINX, Inc. quando precisar abrir um chamado.

Analise atentamente os novos recursos e as mudanças de comportamento descritos nesta publicação do blog antes de prosseguir com a atualização.

Se você ainda não experimentou o NGINX Plus, recomendamos que o experimente – para aceleração da Web, balanceamento de carga e entrega de aplicações, ou como um servidor Web com suporte completo e APIs avançadas de monitoramento e gerenciamento. Você pode começar gratuitamente hoje mesmo com uma avaliação gratuita de 30 dias. Veja por si mesmo como o NGINX Plus pode ajudar você a disponibilizar e escalar suas aplicações.

Sobre o autor

Liam CrillyDiretor Sênior de Gestão de Produtos

Mais publicações de Liam Crilly