Embora o recurso padrão do Kubernetes Ingress seja ótimo para provisionar e configurar o balanceamento de carga básico do Ingress, ele não inclui o tipo de recursos de personalização necessários para tornar o Kubernetes de nível de produção . Em vez disso, os usuários não NGINX são deixados para usar anotações, ConfigMaps e modelos personalizados que são propensos a erros, difíceis de usar, não seguros e carecem de escopo detalhado. Os recursos do NGINX Ingress são nossa resposta para esse problema.
Os recursos do NGINX Ingress estão disponíveis para as versões NGINX Open Source e NGINX Plus do NGINX Ingress Controller. Eles fornecem um estilo de configuração nativo, seguro e recuado que simplifica a implementação do balanceamento de carga do Ingress. Neste blog, nos concentramos em dois recursos introduzidos no NGINX Ingress Controller 1.11.0 que facilitam a configuração de políticas de WAF e balanceamento de carga:
O NGINX Ingress Controller 1.11.0 estende o recurso TransportServer (TS) nas seguintes áreas:
Observação: As adições ao recurso TransportServer na versão 1.11.0 são uma prévia de tecnologia em desenvolvimento ativo. Eles serão graduados para um padrão de qualidade estável e pronto para produção em uma versão futura.
No NGINX Ingress Controller , introduzimos snippets de configuração para os recursos VirtualServer e VirtualServerRoute (VS e VSR) que permitem estender nativamente as configurações do NGINX Ingress para clientes baseados em HTTP. A versão 1.11.0 apresenta snippets para recursos de TS, para que você possa aproveitar facilmente toda a gama de recursos do NGINX e do NGINX Plus para fornecer serviços baseados em TCP/UDP. Por exemplo, você pode usar snippets para adicionar diretivas de negação
e permissão
que usam endereços IP e intervalos para definir quais clientes podem acessar um serviço
apiVersão: k8s.nginx.org/v1alpha1kind: TransportServer
metadados:
nome: cafe
especificação:
host: cafe.example.com
serverSnippets: |
negar 192.168.1.1;
permitir 192.168.1.0/24;
upstreams:
-nome: tea
serviço: tea-svc
porta: 80
Para monitorar a integridade de um cluster Kubernetes, o NGINX Ingress Controller não apenas considera as sondas do Kubernetes que são locais para pods de aplicativos, mas também monitora o status da rede entre serviços upstream baseados em TCP/UDP, com verificações de integridade passivas para avaliar a integridade das transações em andamento e verificações de integridade ativas (exclusivas do NGINX Plus) para sondar endpoints periodicamente com solicitações de conexão sintéticas.
As verificações de integridade podem ser muito úteis para interromper circuitos e lidar com erros de aplicativos. Você pode personalizar a verificação de integridade usando parâmetros no campo healthCheck
do recurso TS que definem o intervalo entre as sondagens, o tempo limite da sondagem, os tempos de atraso entre as sondagens e muito mais.
Além disso, você pode definir o serviço upstream e a porta de destino das sondas de integridade do NGINX Ingress Controller. Isso é útil em situações em que a integridade do aplicativo upstream é exposta em um ouvinte diferente por outro processo ou subsistema que monitora vários componentes downstream do aplicativo.
ingressClassName
Ao atualizar e aplicar um recurso TS, é útil verificar se a configuração é válida e foi aplicada com sucesso à implantação correspondente do Ingress Controller. A versão 1.11.0 apresenta o campo ingressClassName
e o relatório de status para o recurso TS. O campo ingressClassName
garante que o recurso TS seja processado por uma implantação específica do Ingress Controller em ambientes onde você tem várias implantações.
Para exibir o status de um ou todos os recursos do TS, execute o comando kubectl
get
transportserver
; a saída inclui o estado ( Válido
ou Inválido
), o motivo da atualização mais recente e (para um único TS) uma mensagem personalizada.
$ kubectl get transportserver NOME ESTADO MOTIVO IDADE dns-tcp Válido Adicionado ou Atualizado 47m $ kubectl describe transportserver dns-tcp . . .
Status:
Mensagem: A configuração para default/dns-tcp foi adicionada ou atualizada Motivo: Estado AdicionadoOuAtualizado: Válido
Se vários recursos TS competirem pelo mesmo host/ouvinte, o NGINX Ingress Controller selecionará o recurso TS com os registros de data e hora mais antigos, garantindo um resultado determinístico nessa situação.
Os recursos do NGINX Ingress não apenas tornam a configuração mais fácil e flexível, como também permitem delegar o controle de tráfego a diferentes equipes e impor restrições de privilégios mais rígidas aos usuários que possuem sub-rotas de aplicativos, conforme definido nos recursos do VirtualServerRoute (VSR). Ao dar às equipes certas acesso aos recursos certos do Kubernetes, os recursos do NGINX Ingress oferecem controle refinado sobre os recursos de rede e reduzem possíveis danos aos aplicativos caso os usuários sejam comprometidos ou hackeados.
A versão 1.11.0 apresenta um objeto de política de
firewall de aplicativo Web (WAF) nativo para estender esses benefícios à configuração do NGINX App Protect em suas implantações do Kubernetes. A política aproveita os objetos APLogConf e APPolicy introduzidos na versão 1.8.0 e pode ser anexada aos recursos VirtualServer (VS) e VSR. Isso significa que os administradores de segurança podem ter propriedade sobre todo o escopo da configuração do Ingress com recursos do VS, ao mesmo tempo em que delegam responsabilidades de segurança a outras equipes referenciando recursos do VSR.
No exemplo a seguir, a política waf-prod
é aplicada aos usuários roteados para o upstream webapp-prod
. Para delegar responsabilidades de segurança para a rota /v2
entre namespaces de propriedade de equipes diferentes, a diretiva de rota
destacada faz referência a um recurso VSR.
apiVersão: k8s.nginx.org/v1kind: Metadados do VirtualServer: nome: webapp especificação: host: webapp.example.com políticas: - nome: waf-prod tls: segredo: app-secret upstreams: - nome: webapp-prod serviço: webapp-svc porta: 80 rotas: - caminho: /v2 rota: teste/teste - caminho: /v1 ação: senha: webapp-prod
As equipes que gerenciam o namespace de teste
podem definir seus próprios parâmetros e políticas WAF usando recursos VSR nesse namespace.
apiVersão: k8s.nginx.org/v1kind: VirtualServerRoute
metadados:
nome: teste
namespace: teste
especificação:
host: webapp.example.com
upstreams:
-nome: webapp
serviço: webapp-test-svc
porta: 80
subrotas:
- caminho: /v2
políticas:
- nome: waf-test
ação:
senha: webapp
Este exemplo separa os locatários por namespace e aplica uma política WAF diferente para o serviço webapp-test-svc
no namespace de teste
. Ele ilustra como delegar recursos a diferentes equipes e encapsulá-los com objetos simplifica o teste de novas funcionalidades sem interromper os aplicativos em produção.
Com o NGINX Ingress Controller 1.11.0, continuamos nosso compromisso de fornecer um controlador Ingress de nível de produção que seja flexível, poderoso e fácil de usar. Além das melhorias do WAF e do TS, a versão 1.11.0 inclui os seguintes aprimoramentos:
de política
antes de serem aplicados à configuração do IngressCom base nas melhorias na validação de anotações introduzidas na versão 1.10.0, agora estamos validando as seguintes anotações adicionais:
Anotação | Validação |
---|---|
nginx.org/client-max-body-size |
Deve ser um deslocamento válido |
nginx.org/fail-timeout |
Deve ser um horário válido |
nginx.org/max-conns |
Deve ser um inteiro não negativo válido |
nginx.org/max-fails |
Deve ser um inteiro não negativo válido |
nginx.org/proxy-buffer-size |
Deve ser um tamanho válido |
nginx.org/proxy-buffers |
Deve ser uma especificação de buffer de proxy válida |
nginx.org/proxy-connect-timeout |
Deve ser um horário válido |
nginx.org/proxy-max-temp-file-size |
Deve ser um tamanho válido |
nginx.org/proxy-read-timeout |
Deve ser um horário válido |
nginx.org/proxy-send-timeout |
Deve ser um horário válido |
nginx.org/upstream-zone-size |
Deve ser um tamanho válido |
Se o valor da anotação não for válido quando o recurso Ingress for aplicado, o Ingress Controller rejeitará o recurso e removerá a configuração correspondente do NGINX.
O comando kubectl
get
policy
agora relata o estado da política ( Válido
ou Inválido
) e (para um único TS) uma mensagem personalizada e o motivo da atualização mais recente.
$ kubectl get policy NOME ESTADO IDADE webapp-policy Válido 30s $ kubectl describe policy webapp-policy . . .
Status:
Mensagem: A configuração para default/webapp-policy foi adicionada ou atualizada Motivo: Estado AdicionadoOuAtualizado: Válido
O NGINX Ingress Controller agora pode ser usado como controlador Ingress para aplicativos executados dentro de uma malha de serviço Istio. Isso permite que os usuários continuem usando os recursos avançados que o NGINX Ingress Controller fornece em ambientes baseados em Istio sem recorrer a soluções alternativas. Essa integração envolve dois requisitos:
Para atender ao primeiro requisito, inclua os seguintes itens no campo de anotações
do seu arquivo de implantação do NGINX Ingress.
anotações: traffic.sidecar.istio.io/includeInboundPorts: ""
traffic.sidecar.istio.io/excludeInboundPorts: "80.443" tráfego.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16" sidecar.istio.io/inject: 'verdadeiro'
O segundo requisito é alcançado por uma alteração no comportamento do campo requestHeaders
. Em versões anteriores, com a seguinte configuração, dois cabeçalhos de Host
eram enviados para o backend: $host
e o valor especificado, bar.example.com
.
apiVersão: k8s.nginx.org/v1kind: Metadados do VirtualServer: nome: foo especificação: host: foo.example.com upstreams: - nome: foo porta: 8080 serviço: backend-svc use-cluster-ip: true rotas: - caminho: "/" ação: proxy: upstream: foo requestHeaders: set: - nome: Valor do host: bar.example.com
Na versão 1.11.0 e posteriores, somente o valor especificado é enviado. Para enviar $host
, omita completamente o campo requestHeaders
.
Os endpoints upstream na configuração do NGINX Ingress Controller agora podem ser preenchidos com endereços IP de serviço/cluster, em vez de endereços IP individuais de endpoints de pod. Para permitir que o NGINX Ingress Controller roteie o tráfego para serviços Cluster‑IP, inclua o campo use-cluster-ip:
true
na seção upstreams
da sua configuração do VS ou VSR:
upstreams: - nome: serviço de chá: tea-svc porta: 80 use-cluster-ip: true - nome: serviço de café: coffee-svc porta: 80 use-cluster-ip: verdadeiro
Para o changelog completo da versão 1.11.0, consulte as Notas de versão .
Para experimentar o NGINX Ingress Controller para Kubernetes com NGINX Plus e NGINX App Protect, comece seu teste gratuito de 30 dias hoje mesmo ou entre em contato conosco para discutir seus casos de uso .
Para testar o NGINX Ingress Controller com o NGINX Open Source, você pode obter o código-fonte da versão ou baixar um contêiner pré-criado do DockerHub .
Para uma discussão sobre as diferenças entre os controladores Ingress, confira Wait, Which NGINX Ingress Controller for Kubernetes Am I Using? no nosso blog.
"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."