Implementando ChatOps com Slack e Kubernetes usando BotKube

Por que ChatOps transforma a operação de clusters

ChatOps é a prática de centralizar a comunicação, automação e observabilidade de infraestrutura dentro de um canal de chat. Ao trazer comandos de linha de comando e alertas de monitoramento para o Slack, equipes DevOps reduzem o tempo de resposta a incidentes, eliminam a necessidade de alternar entre consoles e mantêm um registro auditável de todas as ações. Quando o alvo são clusters Kubernetes, a complexidade de objetos (pods, deployments, services) e a frequência de eventos (crash loops, escalonamento automático) tornam o ChatOps ainda mais valioso.

Benefícios tangíveis

Entre os ganhos mais notáveis estão:

Visibilidade em tempo real de eventos críticos (crash, OOM, falhas de readiness).
Execução de comandos kubectl diretamente do canal, sem abrir múltiplas janelas de terminal.
Documentação automática das decisões, pois cada comando e resposta fica registrado no histórico do Slack.
Redução de erros humanos, já que as interações são guiadas por políticas de permissão (RBAC) definidas no BotKube.

Arquitetura de integração Slack + Kubernetes via BotKube

BotKube atua como um agente intermediário entre o Slack e a API do Kubernetes. Ele roda como um pod dentro do cluster, escuta eventos do apiserver e responde a mensagens enviadas ao bot no Slack. A arquitetura típica inclui:

Slack App: configurado com escopos de bot (chat:write, channels:read, commands) e um token de acesso.
BotKube Deployment: manifesto YAML contendo a imagem oficial, variáveis de ambiente (SLACK_TOKEN, KUBE_CONFIG) e ConfigMap com regras de notificação.
ConfigMap de políticas: define quais recursos gerarão alertas (por exemplo, CrashLoopBackOff em pods) e quais comandos são permitidos (kubectl get, describe, delete).
Ingress ou Service (opcional): expõe o webhook do BotKube caso seja necessário receber callbacks externos.

Essa separação garante que o BotKube tenha acesso somente ao namespace necessário, respeitando o princípio de menor privilégio.

Pré-requisitos e preparação do ambiente

Antes de iniciar a implantação, verifique os seguintes itens:

Cluster Kubernetes (v1.22+ recomendado) com acesso administrativo para criar ServiceAccount, Role e RoleBinding.
Slack Workspace onde será criado o aplicativo BotKube. É preciso ter permissões de administrador para registrar apps.
kubectl configurado localmente, apontando para o cluster alvo.
Helm 3 (opcional, mas simplifica a instalação).

Além disso, garanta que o namespace onde o BotKube será implantado possua recursos de CPU/memória suficientes – tipicamente 100m CPU e 128Mi RAM são adequados para ambientes de teste.

Instalação e configuração do BotKube

Existem duas abordagens principais: via Helm chart ou manualmente com manifests YAML. A seguir, o fluxo usando Helm, que automatiza a criação de ServiceAccount, Role, RoleBinding e ConfigMap.

Passo a passo com Helm

helm repo add botkube https://helm.botkube.io
helm repo update
helm install botkube botkube/botkube 
  --namespace botkube 
  --create-namespace 
  --set communications.slack.enabled=true 
  --set communications.slack.channel=#ops 
  --set communications.slack.token=YOUR_SLACK_BOT_TOKEN 
  --set settings.clusterName=prod-cluster 
  --set settings.kubeConfigPath=/root/.kube/config

Se preferir a instalação manual, aplique os manifests disponíveis no repositório oficial, ajustando os campos spec.containers.env para inserir o token do Slack e o caminho do kubeconfig.

Validação da implantação

Após o deploy, verifique os pods:

kubectl -n botkube get pods -l app=botkube

Os logs devem exibir a mensagem “BotKube is listening on Slack channel #ops”. Envie uma mensagem de teste no Slack, como @botkube ping, e aguarde a resposta “pong”.

Definindo políticas de notificação e comandos

O coração do BotKube está no ConfigMap botkube-config. Nele, você descreve filtros de eventos e mapeia comandos permitidos. Exemplo de configuração para alertar apenas sobre pods em estado CrashLoopBackOff:

notifications:
  - name: pod-crash
    type: Slack
    enabled: true
    filters:
      - resource: pod
        namespace: "*"
        condition: "status.containerStatuses[?(@.state.waiting.reason=='CrashLoopBackOff')]"
    message: " Pod *{{ .metadata.name }}* está em CrashLoopBackOff no namespace *{{ .metadata.namespace }}*"

Para habilitar comandos, adicione a seção commands:

commands:
  - name: get-pods
    description: "Lista pods no namespace atual"
    command: "kubectl get pods -n {{ .metadata.namespace }}"
    allowedRoles:
      - devops
  - name: delete-pod
    description: "Remove um pod problemático"
    command: "kubectl delete pod {{ .args[0] }} -n {{ .metadata.namespace }}"
    allowedRoles:
      - admin

Os papéis (roles) referenciados são mapeados ao usuário Slack via a configuração users, permitindo granularidade de permissões.

Fluxos de trabalho típicos: deploy, rollback e troubleshooting

Com o BotKube ativo, equipes podem executar pipelines completos sem sair do Slack. A seguir, três cenários comuns.

Deploy de nova versão

Um desenvolvedor publica uma imagem no registry e, no canal, digita:

@botkube apply -f deployment.yaml

O BotKube valida o manifesto, executa kubectl apply e retorna o resumo das alterações. Caso haja erro de validação, o bot envia a mensagem de erro detalhada, permitindo correção imediata.

Rollback automático após falha

Se o BotKube detectar um CrashLoopBackOff, ele pode disparar um comando de rollback pré-configurado:

@botkube rollback deployment my-app --to-revision=2

O bot confirma a ação e publica o status do rollout, reduzindo o MTTR (Mean Time To Recovery).

Diagnóstico de pod problemático

Para investigar, basta solicitar logs ou descrição:

@botkube logs my-pod -c my-container
@botkube describe pod my-pod

O BotKube responde com trechos de logs (até 500 linhas) e o output do kubectl describe, tudo dentro da mesma thread.

Segurança, RBAC e auditoria

Segurança é crítica ao expor controle de cluster via chat. As recomendações incluem:

ServiceAccount limitado: crie um ServiceAccount dedicado ao BotKube com permissões estritas (ex.: get, list, watch em pods; create, delete apenas em namespaces específicos).
RBAC baseado em grupos Slack: associe usuários a papéis internos (admin, devops, viewer) usando a seção users do ConfigMap.
Auditoria de comandos: habilite a flag audit.enabled=true para que cada comando executado seja registrado em um ConfigMap ou enviado a um endpoint externo (ex.: Elasticsearch).
Rotação de tokens: o token do Slack deve ser armazenado como Secret Kubernetes e renovado periodicamente.

Além disso, considere usar NetworkPolicies para limitar o tráfego de saída do pod BotKube apenas ao endpoint da API do Slack.

Escalando e monitorando a solução

Em ambientes de produção com múltiplos clusters, pode ser necessário rodar instâncias do BotKube em cada cluster ou usar um deployment multi-tenant. Estratégias de escalabilidade:

Horizontal Pod Autoscaler (HPA): ajuste automático de réplicas baseado em CPU ou na fila de mensagens Slack.
ConfigMap centralizado: mantenha políticas comuns em um repositório GitOps (ArgoCD, Flux) e sincronize-as em todos os clusters.
Observabilidade: exponha métricas do BotKube via Prometheus (endpoint /metrics) e crie dashboards que mostrem taxa de alertas, comandos executados e latência de resposta.

Com essas práticas, a solução permanece resiliente, auditável e pronta para atender a demandas de alta disponibilidade.

Próximos passos e boas práticas avançadas

Para extrair ainda mais valor, explore integrações adicionais:

GitOps triggers: configure o BotKube para abrir pull requests automáticos quando detectar drift de configuração.
ChatOps com pipelines CI/CD: combine o BotKube com GitHub Actions ou GitLab CI, permitindo que o Slack dispare pipelines via comando @botkube trigger pipeline.
Machine Learning para priorização de alertas: encaminhe eventos para um modelo que classifique a criticidade antes de notificar o canal.

Ao adotar essas extensões, a equipe evolui de um modelo reativo para um fluxo de trabalho proativo, onde a observabilidade, automação e colaboração convergem em um único ponto de contato: o Slack.

Rogerio Lima

Sou um profissional na área de Tecnologia da informação, especializado em monitoramento de ambientes, Sysadmin e na cultura DevOps. Possuo certificações de Segurança, AWS e Zabbix.