Observabilidade no NKPParte 2: NKP Insights

Resumo: o NKP Insights é o app do catálogo que analisa o cluster e aponta pontos de atenção de disponibilidade, configuração, boas práticas e segurança, cada um com causa e solução. No management ele subiu em um minuto, porque as dependências já existiam. No workload, subiu em cerca de dois minutos, com o CloudNativePG habilitado antes e o storage Ceph da Parte 1. Em 10 minutos, mostrou os alertas do Prometheus com contexto e ciclo de vida, dentro do Kommander, onde o administrador já trabalha. Em 11 horas, encontrou 204 itens, incluindo auditorias de segurança e o CIS Benchmark. Esta é a parte 2 de 3.

Onde paramos

Na Parte 1, ligamos os logs no cluster de workload e vimos que o Alertmanager, ligado desde o primeiro dia, vem com o destino padrão "null", à espera do destino real de cada ambiente, e que uma regra crítica, o KubeProxyDown, não se aplica a um cluster com Cilium.

A pergunta desta parte: um app da própria plataforma consegue transformar esses alertas em algo que alguém lê e resolve?

O que é o NKP Insights

É uma ferramenta de análise da Nutanix que roda dentro do NKP. Ela examina o cluster continuamente e gera insights: achados com severidade, tipo, causa provável e solução sugerida, exibidos no próprio Kommander.

A nota da página de detalhes merece atenção: com a configuração padrão, o Insights grava num bucket S3 e espera os apps Rook Ceph e Rook Ceph Cluster habilitados, com espaço suficiente. A alternativa é apontar para o Nutanix Objects ou outro S3.

Como ele está montado

O inventário da Parte 1 já mostrava um detalhe que vale conhecer: a parte central do Insights (nkp-insights-management) roda no management desde a instalação, mesmo com o app desligado. Habilitar o app acrescenta o motor de análise em cada cluster.

Habilitando no management: um minuto

Objetivo: ter o Insights analisando o cluster de management.

No workspace de management, a tela de Enable lista duas dependências, Prometheus Monitoring e CloudNativePG, e não pede para escolher cluster, porque só existe um. As duas dependências já estavam lá, assim como o Ceph com HEALTH_OK.

$ kubectl -n kommander get pods | grep insights
nkp-insights-backend-deployment-...       1/1  Running    3m59s
nkp-insights-backend-forwarder-...        1/1  Running    4m14s
nkp-insights-management-auth-server-...   1/1  Running    30h
nkp-insights-management-mgmt-cm-...       1/1  Running    30h
nkp-insights-object-store-init-...        0/1  Completed  4m14s
nkp-insights-postgresql-1                 1/1  Running    4m36s
nkp-insights-resolution-cm-...            1/1  Running    4m14s

Repare nas idades: a parte central tinha 30 horas; o resto, 4 minutos. O único evento de aviso foi uma verificação de saúde do forwarder no primeiro segundo, normal durante a subida.

Habilitando no workload: dependências primeiro

Objetivo: o mesmo, no cluster de workload, aplicando a boa prática da Parte 1: dependências antes do app.

Aqui o CloudNativePG não existia. Habilitei ele antes (fica na categoria General do catálogo) e só depois o Insights. No workspace de workload, a tela de Enable pede para escolher o cluster:

Em cerca de dois minutos, o operador do CloudNativePG, o banco do Insights e o motor de análise estavam no ar:

$ kubectl get clusters.postgresql.cnpg.io -A
NAME                      INSTANCES   READY   STATUS
nkp-insights-postgresql   1           1       Cluster in healthy state

O object-store-init usou o Ceph que criamos na Parte 1 para os logs. Sem ele, o Insights ficaria aguardando o bucket, como o Loki na Parte 1.

O que ele encontrou nos primeiros 10 minutos

No management, quatro achados. No workload, três.

Dois pontos chamam atenção. Primeiro, são os mesmos pontos que o Alertmanager mostrava na Parte 1, mas sem os alertas auxiliares Watchdog e InfoInhibitor, e dentro do Kommander, onde o administrador já trabalha. Segundo, a mesma causa ganhou severidades diferentes: o throttling é Warning no management e Notice no workload, porque o limite foi mais ultrapassado num do que no outro.

Um achado por dentro

O que diferencia o Insights de uma lista de alertas é a página de detalhe. A do throttling do Fluentd:

O link Headlamp do achado abre direto o StatefulSet do Fluentd. Do aviso ao objeto, em um clique.

O ciclo de vida: Open, Muted e Resolved

O achado da cota de nkpclusters é proposital: o NKP limita um cluster por workspace. É o caso típico para Mute.

Silenciado, ele sai da lista de abertos, mas continua registrado e pode voltar com Unmute. Um achado marcado como Resolved só reaparece se a condição voltar. É o tipo de controle que o Alertmanager sozinho não oferece: lá, ou o alerta está disparando, ou alguém criou uma regra de silêncio com prazo.

Depois de 11 horas: 204 achados

No dia seguinte, o workload tinha 204 achados abertos: 9 Critical, 50 Warning e 145 Notice.

O último item merece destaque. Durante o lab da Parte 3, o Collector do OpenTelemetry entrou em crashloop por um ajuste que faltava na configuração que eu escrevi. O Insights registrou o achado cerca de dois minutos depois, antes que eu investigasse.

Quanto ele consome

Medido com kubectl top, logo depois da subida:

O backend é o maior consumidor de memória. Para o dimensionamento, some as dependências: o CloudNativePG e, se ainda não existir, o Ceph da Parte 1.

Insights × Alertmanager × Headlamp

Eles se complementam: o Insights organiza a revisão diária para quem abre o Kommander, e o Alertmanager, com um destino real configurado, é quem avisa fora dele. No lab, não encontrei uma opção de notificação externa no Insights.

Privacidade, acesso e licença

• Onde ficam os dados: no próprio cluster, no PostgreSQL e no bucket do Ceph. Não fiz uma análise de tráfego de saída; para ambientes regulados, vale confirmar com a Nutanix.
• Quem vê: a tela Insights fica dentro de cada workspace do Kommander e filtra por cluster e projeto, então acompanha o modelo de workspaces e as permissões do NKP.
• Licença: o lab roda NKP Ultimate. Confirme com a Nutanix em qual edição o Insights está disponível antes de incluir numa proposta.

O que aprendi

1. A parte central do Insights já vem instalada, mesmo com o app desligado. Habilitar acrescenta o motor de análise em cada cluster.
2. No workload, as dependências vêm primeiro: Ceph, CloudNativePG e só então o Insights.
3. Em minutos, o Insights mostra os alertas dentro do Kommander, com causa, solução e um link para o objeto.
4. Mute e Resolved dão ciclo de vida aos achados, complementando a lista de alertas.
5. Volume não é urgência: filtre por severidade e tipo, e comece pelos 9 Critical antes dos 145 Notice.
6. Insights e Alertmanager trabalham juntos. O Insights organiza a revisão dentro do Kommander; o Alertmanager, com destino real, avisa fora dele.

Checklist do NKP Insights

• Storage S3 disponível (Rook Ceph Cluster, Nutanix Objects ou outro S3)
• CloudNativePG habilitado no workspace
• Insights habilitado em cada workspace, escolhendo os clusters
• Pods do Insights conferidos (backend, forwarder, resolution-cm, postgresql)
• Achados Critical e Warning revisados no primeiro dia
• Achados propositais marcados como Muted, com justificativa
• Revisão periódica dos achados de Security e Best Practices
• Edição do NKP confirmada com a Nutanix

O que ainda não testei

• Notificação do NKP Insights fora do Kommander. No lab, acompanhei os achados pela tela Insights e não verifiquei um envio externo.
• O tráfego de saída do Insights. Não fiz uma análise de rede; para ambientes regulados, é o próximo passo.
• Outras edições do NKP. O lab roda NKP Ultimate; não testei o Insights em outra edição.

Referências

Nutanix

• Nutanix Kubernetes Platform Guide 2.19, seção NKP Insights (portal Nutanix)

Projetos e comunidade

• Polaris (Fairwinds)
• CIS Kubernetes Benchmark
• CloudNativePG