Tomando melhores decisões com o Deep Service Insight do NGINX Ingress Controller

Lançamos a versão 3.0 do NGINX Ingress Controller em janeiro de 2023 com uma série de novos recursos significativos e funcionalidade aprimorada. Um novo recurso que acreditamos que você achará particularmente valioso é o Deep Service Insight, disponível com a edição NGINX Plus do NGINX Ingress Controller.

O Deep Service Insight aborda uma limitação que dificulta o funcionamento ideal quando um sistema de decisão de roteamento, como um balanceador de carga, fica na frente de um ou mais clusters do Kubernetes — ou seja, o sistema não tem acesso a informações sobre a integridade de serviços individuais em execução nos clusters por trás do controlador Ingress. Isso evita que o tráfego seja roteado apenas para clusters com serviços saudáveis, o que potencialmente expõe seus usuários a interrupções e erros como404 e500 .

O Deep Service Insight elimina esse problema expondo o status de integridade dos pods de serviço de backend (conforme coletado pelo NGINX Ingress Controller) em um endpoint dedicado, onde seus sistemas podem acessá-lo e usá-lo para melhores decisões de roteamento.

Nesta postagem, examinaremos em detalhes o problema resolvido pelo Deep Service Insight, explicaremos como ele funciona em alguns casos de uso comuns e mostraremos como configurá-lo.

Por que Deep Service Insight?

As sondas padrão de atividade, prontidão e inicialização do Kubernetes fornecem algumas informações sobre os serviços de backend em execução nos seus clusters, mas não o suficiente para o tipo de insight necessário para tomar melhores decisões de roteamento em toda a sua pilha. A falta de informações corretas se torna ainda mais problemática à medida que suas implantações do Kubernetes aumentam em complexidade e seus requisitos comerciais para tempo de atividade ininterrupto se tornam mais urgentes.

Uma abordagem comum para melhorar o tempo de atividade à medida que você dimensiona seu ambiente Kubernetes é implantar balanceadores de carga, gerenciadores de DNS e outros sistemas de decisão automatizados na frente de seus clusters. No entanto, devido ao modo como os controladores Ingress funcionam, um balanceador de carga na frente de um cluster Kubernetes normalmente não tem acesso às informações de status sobre os serviços por trás do controlador Ingress no cluster – ele pode verificar apenas se os pods do controlador Ingress estão íntegros e aceitando tráfego.

O NGINX Ingress Controller, por outro lado, tem informações sobre a integridade do serviço. Ele já monitora a integridade dos pods upstream em um cluster enviando verificações de integridade passivas periódicas para serviços HTTP , TCP , UDP e gRPC , monitorando a capacidade de resposta das solicitações e rastreando códigos de resposta bem-sucedidos e outras métricas. Ele usa essas informações para decidir como distribuir o tráfego entre os pods dos seus serviços para fornecer uma experiência de usuário consistente e previsível. Normalmente, o NGINX Ingress Controller realiza toda essa mágica silenciosamente em segundo plano, e você pode nunca pensar duas vezes sobre o que está acontecendo nos bastidores. O Deep Service Insight “expõe” essas informações valiosas para que você possa usá-las de forma mais eficaz em outras camadas da sua pilha.

Como funciona o Deep Service Insight?

O Deep Service Insight está disponível para serviços que você implanta usando os recursos personalizados NGINX VirtualServer e TransportServer (para HTTP e TCP/UDP, respectivamente). O Deep Service Insight usa a API NGINX Plus para compartilhar a visão do NGINX Ingress Controller dos pods individuais em um serviço de backend em um endpoint dedicado exclusivo do Deep Service Insight:

• Para VirtualServer – <endereço_IP> :<porta> /sonda/<nome do host>
• Para TransportServer – <endereço_IP> :<porta> /sonda/ts/<nome_do_serviço>

onde

• <endereço_IP> pertence ao NGINX Ingress Controller
• <porta> é o número da porta do Deep Service Insight (9114 por padrão)
• <nome do host> é o nome de domínio do serviço conforme definido no host de especificações campo do recurso VirtualServer
• <nome_do_serviço> é o nome do serviço conforme definido no especificação.upstreams.serviço campo no recurso TransportServer

A saída inclui dois tipos de informação:

1. Um código de status HTTP para o nome do host ou nome do serviço:

   • 200 OK – Pelo menos um pod está saudável
   • 418 Eu sou um bule de chá – Nenhuma cápsula é saudável
   • 404 Não encontrado – Não há pods que correspondam ao nome do host ou nome do serviço especificado

2. Três contadores para o nome do host ou nome do serviço especificado:

   • Número total de instâncias de serviço (pods)
   • Número de pods no estado Up (saudável)
   • Número de pods no estado Unhealthy

Aqui está um exemplo em que todos os três pods de um serviço estão saudáveis:

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8 Data: Dia , DD Seg AAAA hh : mm : ss TZ Conteúdo-Comprimento: 32 {"Total":3,"Up":3,"Insalubre":0}

Para mais detalhes, consulte a documentação do NGINX Ingress Controller.

Você pode personalizar ainda mais os critérios que o NGINX Ingress Controller usa para decidir se um pod está íntegro configurando verificações de integridade ativas. Você pode configurar o caminho e a porta para onde a verificação de integridade é enviada, o número de verificações com falha que devem ocorrer dentro de um período de tempo especificado para que um pod seja considerado não íntegro, o código de status esperado, tempos limite para conectar ou receber uma resposta e muito mais. Inclua o campo Upstream.Healthcheck no recurso VirtualServer ou TransportServer .

Exemplos de casos de uso para Deep Service Insight

Um caso de uso em que o Deep Service Insight é particularmente valioso é quando um balanceador de carga está roteando tráfego para um serviço que está sendo executado em dois clusters, digamos, para alta disponibilidade. Dentro de cada cluster, o NGINX Ingress Controller rastreia a integridade dos pods upstream, conforme descrito acima. Quando você habilita o Deep Service Insight, informações sobre o número de pods upstream íntegros e não íntegros também são expostas em um endpoint dedicado. Seu sistema de decisão de roteamento pode acessar o endpoint e usar as informações para desviar o tráfego de aplicativos de pods não íntegros em favor de pods íntegros.

O diagrama ilustra como o Deep Service Insight funciona neste cenário.

Você também pode aproveitar o Deep Service Insight ao executar manutenção em um cluster em um cenário de alta disponibilidade. Basta reduzir o número de pods para um serviço a zero no cluster onde você está fazendo a manutenção. A falta de pods saudáveis aparece automaticamente no endpoint do Deep Service Insight e seu sistema de decisão de roteamento usa essa informação para enviar tráfego para os pods saudáveis no outro cluster. Você efetivamente obtém failover automático sem precisar alterar a configuração no NGINX Ingress Controller ou no sistema, e seus clientes nunca sofrem interrupção de serviço.

Habilitando o Deep Service Insight

Para habilitar o Deep Service Insight, inclua o argumento de linha de comando -enable-service-insight no manifesto do Kubernetes ou defina o parâmetro serviceInsight.create como true se estiver usando o Helm.

Há dois argumentos opcionais que você pode incluir para ajustar o endpoint para seu ambiente:

• -serviço-insight-escuta-porta <porta> – Altere o número da porta do Deep Service Insight do padrão, 9114 (<porta> é um número inteiro no intervalo 1024–65535). O equivalente do Helm é o parâmetro serviceInsight.port .
• -serviço-insight-tls-string <segredo> – Um segredo do Kubernetes (certificado e chave TLS) para terminação TLS do ponto de extremidade do Deep Service Insight (<segredo> é uma sequência de caracteres com formato <namespace>/<nome_secreto>). O equivalente do Helm é o parâmetro serviceInsight.secret .

Exemplo: Habilitar Deep Service Insight para o aplicativo Cafe

Para ver o Deep Service Insight em ação, você pode habilitá-lo para o aplicativo Cafe, frequentemente usado como exemplo na documentação do NGINX Ingress Controller.

1. Instale a edição NGINX Plus do NGINX Ingress Controller com suporte para recursos personalizados do NGINX e habilitação do Deep Service Insight:

   • Se estiver usando Helm , defina o parâmetro serviceInsight.create como true .
   • Se estiver usando um manifesto do Kubernetes (implantação ou DaemonSet), inclua o argumento -enable-service-insight no arquivo de manifesto.

2. Verifique se o NGINX Ingress Controller está em execução:

   $ kubectl get pods -n nginx-ingress NOME PRONTO ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ...  STATUS REINICIA IDADE ...  Correndo 0 9d

3. Implante o aplicativo Cafe de acordo com as instruções no README .

4. Verifique se o recurso personalizado NGINX VirtualServer está implantado para o aplicativo Cafe (o endereço IP foi omitido para legibilidade):

   $ kubectl get vs NOME ESTADO HOST IP PORTAS IDADE cafe Válido cafe.example.com ... [80.443] 7h1m

5. Verifique se há três pods upstream para o serviço Cafe em execução em cafe.example.com :

   $ kubectl get pods NOME PRONTO STATUS REINÍCIOS IDADE coffee-87cf76b96-5b85h 1/1 Em execução 0 7h39m coffee-87cf76b96-lqjrp 1/1 Em execução 0 7h39m tea-55bc9d5586-9z26v 1/1 Em execução 0 111m

6. Acesse o ponto de extremidade do Deep Service Insight:

   $ enrolar -i <endereço_IP_NIC>:9114/probe/cafe.example.com

   O 200 OK o código de resposta indica que o serviço está pronto para aceitar tráfego (pelo menos um pod está íntegro). Neste caso, todos os três pods estão no estado Up.

   HTTP/1.1 200 OK Tipo de conteúdo: application/json; charset=utf-8 Data: Dia , DD Seg AAAA hh : mm : ss TZ Conteúdo-Comprimento: 32 {"Total":3,"Up":3,"Insalubre":0}

   O 418 Eu sou um bule de chá o código de status indica que o serviço não está disponível (todos os pods não estão íntegros).

   HTTP/1.1 418 Eu sou um bule de cháContent-Type: application/json; charset=utf-8 Data: Dia , DD Seg AAAA hh : mm : ss TZ Conteúdo-Comprimento: 32 {"Total":3,"Up":0,"Insalubre":3}

   O 404 Não Encontrado O código de status indica que não há nenhum serviço em execução no nome do host especificado.

   HTTP/1.1 404 Não EncontradoData: Dia , DD Seg AAAA hh : mm : ss TZ Conteúdo-Comprimento: 0

Recursos

Para o changelog completo do NGINX Ingress Controller versão 3.0.0, consulte as Notas de versão .

Para experimentar o NGINX Ingress Controller 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 .