KubePilot: CoPilot, Pilot e AutoPilot para incidentes mais rápidos do Kubernetes

KubePilot é um cockpit de solução de problemas do Kubernetes de código aberto criado pelo Workstation equipe de engenharia. Ele combina diagnóstico assistido por IA (Co-piloto), navegação em cluster estilo SRE (Piloto) e remediação controlada por políticas (Piloto automático) para que as equipes de plataforma, SRE e DevOps passem de sinais barulhentos para uma solução segura, sem fazer malabarismos com as guias kubectl no meio do incidente. Local do produto: kubepilot.org. Fonte: github.com/bwalia/kubepilot.

1. Assista ao passo a passo

youtu.be/CsiJWpfncqA - Balinder Walia, Workstation.

2. O problema que o KubePilot resolve

Clusters modernos emitem mais sinais do que os humanos conseguem fazer triagem em uma única página: CrashLoops, ImagePullBackOff, OOMKills, pressão de nó, testes escamosos e desvio de YAML. A resposta típica se espalha por:

• kubectl histórico e scripts de shell,
• uma IU do navegador (Lens/Rancher/painel),
• registra em uma terceira ferramenta,
• um bate-papo LLM com YAML colado (e sem autenticação de cluster).

Essa fragmentação queima minutos quando os minutos são o SLA. O KubePilot recolhe o loop em um cockpit: localizar → perguntar → verificar → corrigir.

3. Modo A — CoPilot (solução de problemas assistida por IA)

CoPilot é a superfície RCA automatizada e de linguagem natural:

• Faça perguntas operacionais em inglês simples (“por que o checkout CrashLooping está em produção?”).
• Um clique Análise de IA em pods e eventos de problemas.
• Análise de causa raiz com cadeias de evidências, confiança, risco, comandos sugeridos, correções YAML e próximas etapas.
• Detecção de anomalias para padrões CrashLoop, OOM, ImagePull e pressão de nó.
• Copiar prompt para reutilizar o prompt de diagnóstico exato com seu modelo preferido.
• Projetado para Ollama/modelos locais para que o contexto do cluster possa permanecer na sua rede.

4. Modo B – Piloto (navegador de solução de problemas de SRE)

Pilot é o ambiente de trabalho somente leitura estilo Lens/Rancher para verificação antes da mutação:

• Navegue por implantações, StatefulSets, DaemonSets, Jobs, Services, Ingresses, ConfigMaps, Secrets, PVCs.
• Ambiente de trabalho de pod: visão geral, contêineres, eventos, logs, YAML higienizado, contagens de reinicialização, tempo de atividade.
• Medidores de recursos de cluster em tempo real (CPU, memória, disco) — compatíveis com Longhorn quando aplicável.
• Tela de topologia de serviço: Entrada → Serviço → Carga de trabalho → Pod com cores e portas de status.
• Classificação IP de LAN, WAN e túnel (por exemplo, WireGuard / flanela) - não apenas o endereço de sobreposição.
• Túneis de encaminhamento de porta da UI; upload de kubeconfig de vários clusters e alternância de contexto sem reinicialização.

5. Modo C – Piloto Automático (fixador AI com grades de segurança)

O AutoPilot fecha o ciclo com autocorreção auditável – nunca “YOLO apply” como padrão:

Controlar	Propósito
Modos: desligado/funcionamento a seco/ativo	Pré-visualizar antes de aplicar; mantenha a automação estacionada quando necessário
Pisos de confiança	Ignore RCAs de baixa confiança em vez de adivinhar
Listas de bloqueio de namespace e listas de permissões de ação	Proteja os namespaces kube-system/prod; limitar tipos de mutação
Recargas e limites horários	Evite tempestades de remediação
Interruptor de matar	Pausa de um clique para operadores
Livro razão de decisão	Executado, ignorado, escalonado, com falha — trilha de auditoria
Escalação de código CR	Aprovação humana para ações arriscadas

6. Mapa completo de recursos (de kubepilot.org)

• Runbooks pré-construídos: sete fluxos de trabalho de diagnóstico opinativos; runbooks YAML personalizados com fsnotify hot-reload (IDs de usuário substituem os integrados).
• História RCA durável: SQLite integrado opcional (WAL, sem CGO) com retenção para relatórios e anomalias durante reinicializações.
• Alertas e cronograma: avisos, eventos, anomalias, RCA como um cronograma de operações pesquisável; cartões de incidentes opcionais do Slack.
• Chip de saúde de IA: saber que o Ollama está pronto antes que um incidente dependa disso.
• Padrões de segurança em primeiro lugar: autenticação opcional, navegação somente leitura, portas de mutação, políticas CORS.
• Protocolo do agente MCP: servidor MCP integrado para orquestração de agentes multicluster e acesso programático.
• Companheiro iOS nativo: Aplicativo SwiftUI – cartões de saúde, pods, registros, RCA, Face ID, widgets, Siri/App Intents.

7. Opções de instalação

Pré-requisitos para compilações de origem: Go 1.22+, Node.js 18+, um cluster acessível + kubeconfig; Ollama recomendado para IA local.

7.1 Construir a partir da fonte

git clone https://github.com/bwalia/kubepilot.git
cd kubepilot
make dashboard-install
make dashboard
make build
KUBEPILOT_KUBECONFIG="$HOME/.kube/config" ./dist/kubepilot serve --dashboard-port=8383
# Dashboard/API: http://localhost:8383
# MCP server: :9090

7.2 Helm (instalação de cluster)

helm repo add kubepilot https://bwalia.github.io/kubepilot
helm repo update
helm upgrade --install kubepilot kubepilot/kubepilot \
  -n kubepilot --create-namespace
kubectl port-forward svc/kubepilot -n kubepilot 8080:8080
# Open http://localhost:8080

Também suportado: NodePort, Ingress (+ TLS do gerenciador de certificados), LoadBalancer e substituições de valores - consulte o gráfico README no GitHub.

7.3 Janela de encaixe

docker run --rm -p 8383:8383 -p 9090:9090 \
  -v "$HOME/.kube:/root/.kube:ro" \
  ghcr.io/kubepilot/kubepilot:latest \
  serve --dashboard-port=8383

7.4 companheiro iOS

cd ios
brew install xcodegen
./generate.sh
open KubePilot.xcodeproj
# Point the app at http://<server-ip>:8383

8. Modelo operacional recomendado

1. Dia 0: execute o Pilot como somente leitura em um cluster que não seja de produção; fio Ollama; confirme o chip de saúde da IA.
2. Dia 1: use o CoPilot AI Analyze em pods defeituosos conhecidos; compare o RCA com seus runbooks; ajuste o prompt de cópia em sua equipe LLM.
3. Dia 2: ativar o piloto automático em ensaio apenas; revisar o livro de decisões por uma semana.
4. Dia 3+: promova namespaces selecionados para ativos com listas de permissões restritas, níveis de confiança e alertas do Slack; mantenha o sistema kube bloqueado.
5. Sempre: kill switch ensaiado; Caminho do código CR para mutações de risco; Ferramentas MCP por trás da autenticação (veja nosso resumo de segurança do agente).

9. Lista de verificação de produção

• ☐ Autenticação habilitada para qualquer painel acessível pela rede.
• ☐ O AutoPilot inicia em teste; ativo somente após revisão do razão.
• ☐ A lista de bloqueio de namespace inclui namespaces de sistema/compartilhados.
• ☐ Limites horários e tempos de espera definidos abaixo dos limites de tempestade.
• ☐ Ollama (ou caminho LLM aprovado) monitorado por meio de integridade de IA.
• ☐ Integração com Slack ou pager para anomalias de alta gravidade.
• ☐ GitOps ainda possui o estado desejado – o AutoPilot é um fixador tático, não um substituto para o Argo CD/Flux.
• ☐ Lançamentos de estrelas e faixas: github.com/bwalia/kubepilot.

10. Por que o Workstation oferece este código aberto

A Workstation cria plataformas de automação para equipes de operações reais. KubePilot é nossa aposta que AIOps só funciona quando o diagnóstico e a remediação compartilham uma trilha de evidências – e quando a automação é controlada como um SRE humano bloquearia uma mudança. Nós o publicamos em código aberto para que as equipes da plataforma possam executá-lo em suas próprias redes, estender runbooks e conectar agentes MCP sem dependência de fornecedor.

Começar em kubepilot.org, clonar o repositórioe assista ao passo a passo em YouTube. Resumo do complemento: postagem no blog.