AIOps Kubernetes

Implementando Self-Healing Infrastructure com Kubernetes e AIOps

Construir uma infraestrutura self-healing deixou de ser luxo reservado a big techs e passou a ser requisito básico para qualquer time que opera clusters Kubernetes em produção. Neste tutorial, mostramos como combinar os mecanismos nativos de autocorreção do Kubernetes com práticas de AIOps para detectar falhas em tempo real e aplicar correções automáticas — como restart de pods, scaling reativo e rollback de deploys — sem depender de intervenção humana. O objetivo é sair da teoria e chegar a uma arquitetura funcional, com manifests YAML, scripts e exemplos de controllers que você pode adaptar ao seu ambiente ainda hoje.

O que é Self-Healing Infrastructure e por que ela importa

Self-healing infrastructure é o conjunto de mecanismos, políticas e automações que permitem que um sistema identifique anomalias, diagnostique a causa provável e execute uma remediação sem que um engenheiro precise ser acionado às 3h da manhã. Em ambientes Kubernetes, isso vai muito além do restartPolicy: Always de um Pod: envolve observabilidade contínua, correlação de eventos, tomada de decisão automatizada e, cada vez mais, modelos de machine learning capazes de prever falhas antes que elas aconteçam.

A adoção de infraestrutura self-healing reduz o MTTR (Mean Time To Recovery), diminui a fadiga operacional de times de SRE e evita que incidentes pequenos se transformem em outages de grande impacto. Quando falamos em AIOps aplicado a Kubernetes, estamos falando de usar dados de telemetria — métricas, logs e traces — para alimentar algoritmos que tomam decisões operacionais em tempo real.

Fundamentos: o Kubernetes já nasce com mecanismos de autocorreção

Antes de adicionar qualquer camada de inteligência artificial, é fundamental dominar os recursos nativos do Kubernetes que já entregam parte do trabalho de self-healing.

Liveness, Readiness e Startup Probes

As probes são o primeiro nível de defesa. Elas informam ao kubelet quando um container está travado, ainda inicializando ou pronto para receber tráfego.

apiVersion: v1
kind: Pod
metadata:
  name: api-payments
spec:
  containers:
    - name: api-payments
      image: registry.interno/api-payments:1.4.2
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 10
        periodSeconds: 15
        failureThreshold: 3
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        failureThreshold: 30
        periodSeconds: 10

Quando a livenessProbe falha três vezes seguidas, o kubelet reinicia o container automaticamente — o primeiro exemplo prático de infraestrutura self-healing dentro do próprio cluster.

ReplicaSets, Deployments e o controlador de reconciliação

O modelo declarativo do Kubernetes é, por natureza, self-healing: o controller manager compara continuamente o estado desejado (definido no manifest) com o estado atual do cluster e corrige divergências. Se um nó cai e leva três réplicas de um Deployment junto, o ReplicaSet cria novos pods em outros nós automaticamente.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-payments
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: api-payments
  template:
    metadata:
      labels:
        app: api-payments
    spec:
      containers:
        - name: api-payments
          image: registry.interno/api-payments:1.4.2

Esses mecanismos resolvem falhas simples, mas não lidam com degradação silenciosa de performance, memory leaks progressivos ou padrões de erro que só ficam evidentes quando correlacionados com dados históricos — é aí que entra o AIOps.

AIOps: adicionando inteligência à correção automática

AIOps (Artificial Intelligence for IT Operations) aplica machine learning e correlação estatística sobre grandes volumes de telemetria para antecipar problemas e automatizar decisões operacionais. Em uma infraestrutura self-healing madura, o AIOps atua em três camadas:

  1. Detecção de anomalias em métricas (latência, uso de CPU, taxa de erro) usando baselines dinâmicos em vez de thresholds fixos.
  2. Correlação de eventos entre múltiplos serviços para identificar a causa-raiz real, não apenas o sintoma.
  3. Decisão e execução de remediação, acionando automações (restart, rollback, scale-out) com base em playbooks previamente validados.

A diferença central entre um cluster “apenas resiliente” e um cluster com infraestrutura self-healing baseada em AIOps é a capacidade de agir sobre padrões complexos — não só sobre falhas binárias de health check.

Arquitetura de referência

Uma arquitetura funcional de self-healing infrastructure para Kubernetes normalmente combina estas camadas:

  • Coleta: Prometheus, para métricas de cluster e aplicação.
  • Análise: um detector de anomalias (estatístico ou baseado em ML) consumindo as séries temporais do Prometheus.
  • Alertamento: Alertmanager, roteando alertas para um serviço de decisão.
  • Execução: um Kubernetes Operator customizado, KEDA para scaling e Argo Rollouts para rollback progressivo.
  • Auditoria: logs estruturados de cada ação automática, para rastreabilidade e revisão posterior.

A seguir, implementamos cada peça.

Passo 1: configurando a camada de detecção de falhas

Instalando Prometheus e Alertmanager

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set alertmanager.config.global.resolve_timeout=5m

Definindo regras de alerta orientadas a self-healing

Em vez de alertas genéricos, criamos regras que já carregam o contexto necessário para a automação decidir o tipo de remediação.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: self-healing-rules
  namespace: monitoring
spec:
  groups:
    - name: self-healing.rules
      rules:
        - alert: PodCrashLoopBackOff
          expr: kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"} == 1
          for: 2m
          labels:
            severity: critical
            remediation: restart-pod
          annotations:
            summary: "Pod {{ $labels.pod }} em CrashLoopBackOff"

        - alert: HighErrorRateAfterDeploy
          expr: |
            sum(rate(http_requests_total{status=~"5.."}[5m])) by (deployment)
            /
            sum(rate(http_requests_total[5m])) by (deployment)
            > 0.05
          for: 3m
          labels:
            severity: critical
            remediation: rollback-deploy
          annotations:
            summary: "Taxa de erro acima de 5% em {{ $labels.deployment }}"

Note o uso do label remediation: ele funciona como uma instrução direta para o motor de automação, eliminando ambiguidade na hora de decidir qual ação executar.

Roteando alertas para o motor de automação via webhook

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
stringData:
  alertmanager.yaml: |
    route:
      receiver: self-healing-webhook
      routes:
        - match:
            severity: critical
          receiver: self-healing-webhook
    receivers:
      - name: self-healing-webhook
        webhook_configs:
          - url: http://self-healing-operator.automation.svc:9090/webhook
            send_resolved: true

Passo 2: automatizando a remediação

Kubernetes Operator para self-healing

O núcleo da automação é um operator que recebe os alertas do Alertmanager e decide a ação com base no label remediation. Abaixo, um exemplo simplificado usando o framework Kopf (Python), ideal para prototipagem rápida antes de migrar para Go com controller-runtime em produção.

import kopf
import kubernetes
from flask import Flask, request

app = Flask(__name__)
kubernetes.config.load_incluster_config()
apps_v1 = kubernetes.client.AppsV1Api()
core_v1 = kubernetes.client.CoreV1Api()

@app.route("/webhook", methods=["POST"])
def handle_alert():
    payload = request.json
    for alert in payload.get("alerts", []):
        labels = alert.get("labels", {})
        remediation = labels.get("remediation")
        namespace = labels.get("namespace", "default")

        if remediation == "restart-pod":
            pod_name = labels.get("pod")
            core_v1.delete_namespaced_pod(pod_name, namespace)
            log_action(f"Pod {pod_name} reiniciado automaticamente")

        elif remediation == "rollback-deploy":
            deployment = labels.get("deployment")
            rollback_deployment(deployment, namespace)
            log_action(f"Rollback executado em {deployment}")

    return {"status": "processed"}, 200

def rollback_deployment(name, namespace):
    body = {"spec": {"rollbackTo": {"revision": 0}}}
    apps_v1.patch_namespaced_deployment(name, namespace, body)

def log_action(message):
    print(f"[self-healing] {message}")

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=9090)

Esse serviço deve rodar em um namespace isolado (automation), com uma ServiceAccount de permissões mínimas, seguindo o princípio de menor privilégio via RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: self-healing-operator
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "delete"]
  - apiGroups: ["apps"]
    resources: ["deployments", "deployments/rollback"]
    verbs: ["get", "list", "patch", "update"]

Scaling reativo com KEDA

Nem toda falha exige restart ou rollback — muitas vezes o problema é subdimensionamento diante de picos de carga. O KEDA (Kubernetes Event-Driven Autoscaling) permite escalar workloads com base em métricas externas, como fila de mensagens ou latência.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-payments-scaler
  namespace: default
spec:
  scaleTargetRef:
    name: api-payments
  minReplicaCount: 3
  maxReplicaCount: 20
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://monitoring-prometheus.monitoring:9090
        metricName: http_request_duration_seconds
        query: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[2m])) by (le))
        threshold: "0.8"

Rollback automático de deploys com Argo Rollouts

Para deploys progressivos com análise automática de métricas, o Argo Rollouts substitui o Deployment tradicional por uma estratégia canary com validação contínua — se as métricas piorarem, o rollback acontece sem intervenção humana.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-payments
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: { duration: 60 }
        - analysis:
            templates:
              - templateName: success-rate-check
        - setWeight: 50
        - pause: { duration: 60 }
        - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate-check
spec:
  metrics:
    - name: success-rate
      interval: 30s
      successCondition: result[0] >= 0.95
      failureLimit: 2
      provider:
        prometheus:
          address: http://monitoring-prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{status!~"5..",deployment="api-payments"}[2m]))
            /
            sum(rate(http_requests_total{deployment="api-payments"}[2m]))

Se a taxa de sucesso cair abaixo de 95% durante o canary, o Argo Rollouts interrompe o avanço e reverte automaticamente para a versão estável anterior — um exemplo direto de infraestrutura self-healing aplicada ao pipeline de entrega contínua.

Passo 3: incorporando detecção de anomalias com machine learning

Thresholds fixos, como “CPU acima de 80%”, geram falsos positivos em cargas sazonais. Um detector de anomalias baseado em desvio estatístico melhora a precisão da automação. Segue um exemplo simplificado usando Z-score sobre séries do Prometheus, empacotado como CronJob:

import requests
import numpy as np
from datetime import datetime, timedelta

PROM_URL = "http://monitoring-prometheus.monitoring:9090"

def fetch_series(query, minutes=30):
    end = datetime.utcnow()
    start = end - timedelta(minutes=minutes)
    params = {
        "query": query,
        "start": start.timestamp(),
        "end": end.timestamp(),
        "step": "30s",
    }
    resp = requests.get(f"{PROM_URL}/api/v1/query_range", params=params).json()
    values = resp["data"]["result"][0]["values"]
    return np.array([float(v[1]) for v in values])

def detect_anomaly(series, z_threshold=3.0):
    mean = np.mean(series)
    std = np.std(series)
    latest = series[-1]
    z_score = (latest - mean) / std if std > 0 else 0
    return abs(z_score) > z_threshold, z_score

if __name__ == "__main__":
    series = fetch_series('sum(rate(http_requests_total{status=~"5.."}[1m]))')
    is_anomaly, score = detect_anomaly(series)
    if is_anomaly:
        print(f"[AIOps] Anomalia detectada. Z-score={score:.2f}")
        requests.post(
            "http://self-healing-operator.automation.svc:9090/webhook",
            json={
                "alerts": [{
                    "labels": {
                        "remediation": "rollback-deploy",
                        "deployment": "api-payments",
                        "namespace": "default",
                    }
                }]
            },
        )
apiVersion: batch/v1
kind: CronJob
metadata:
  name: anomaly-detector
  namespace: automation
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: anomaly-detector
              image: registry.interno/anomaly-detector:1.0.0
          restartPolicy: OnFailure

Esse padrão pode evoluir para modelos mais sofisticados, como Isolation Forest ou LSTM para séries temporais, mas o princípio permanece: alimentar o motor de remediação com decisões baseadas em contexto histórico, não apenas em limites estáticos.

Ferramentas complementares para observabilidade e AIOps em Kubernetes

Além da stack apresentada, o ecossistema de observabilidade para self-healing infrastructure vem amadurecendo rapidamente, e vale conhecer outras peças que podem substituir ou complementar as escolhidas neste tutorial.

O Keptn é um projeto voltado especificamente para automação orientada a eventos em Kubernetes, com foco em SLOs (Service Level Objectives). Ele permite definir critérios de qualidade declarativos e disparar remediações — incluindo rollback — quando um SLO é violado, funcionando como uma camada de orquestração acima do Argo Rollouts ou do Flagger.

O OpenTelemetry se tornou o padrão de fato para instrumentação de métricas, logs e traces, e alimenta tanto o Prometheus quanto ferramentas de AIOps mais sofisticadas com dados correlacionados entre serviços. Instrumentar aplicações com OpenTelemetry facilita a correlação de causa-raiz, já que traces distribuídos mostram exatamente em qual serviço da cadeia uma falha se originou, evitando que a automação tome decisões equivocadas baseadas apenas em sintomas de serviços downstream.

Para clusters maiores, soluções de AIOps com suporte a correlação multi-cluster tornam-se relevantes, especialmente quando a infraestrutura self-healing precisa lidar com dependências entre múltiplos namespaces, regiões ou provedores de nuvem. Nesses cenários, a decisão de remediação deixa de ser local a um Deployment e passa a considerar o impacto em cascata sobre outros serviços.

Chaos Engineering como validação da automação

Um cluster só pode ser chamado de self-healing depois de testado sob falhas reais e controladas. Ferramentas de Chaos Engineering, como o Chaos Mesh, permitem injetar falhas propositalmente — matar pods, simular latência de rede, saturar CPU — para validar se as regras de detecção e remediação configuradas realmente funcionam como esperado.

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: kill-payments-pod
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - default
    labelSelectors:
      app: api-payments
  scheduler:
    cron: "@every 10m"

Rodar experimentos de caos periodicamente em ambiente de staging é a forma mais confiável de garantir que a infraestrutura self-healing continue funcionando conforme o sistema evolui, evitando o cenário em que a automação existe no papel, mas falha silenciosamente quando um incidente real acontece.

Boas práticas e cuidados com automação de correções

Automatizar correções em produção exige disciplina para não trocar um incidente por outro maior:

Defina limites de segurança (circuit breakers) na automação, como número máximo de restarts por hora antes de escalar para um humano. Registre toda ação automática em um log de auditoria imutável, incluindo métricas antes e depois da remediação. Separe claramente ambientes de teste e produção ao validar novas regras de self-healing — um bug no operator pode causar mais dano do que a falha original. Combine self-healing automatizado com runbooks documentados para cenários que exigem intervenção humana, evitando que a equipe perca visibilidade sobre o que o sistema está decidindo sozinho. Revise periodicamente os thresholds e modelos de anomalia, já que padrões de tráfego mudam ao longo do tempo.

Implementar uma infraestrutura self-healing com Kubernetes e AIOps não é um projeto de “configurar e esquecer” — é um processo contínuo de refinamento entre observabilidade, automação e governança. Começando pelos mecanismos nativos do Kubernetes (probes, ReplicaSets), avançando para automações reativas com Prometheus, KEDA e Argo Rollouts, e incorporando detecção de anomalias baseada em machine learning, é possível construir um cluster capaz de se autocorrigir na maioria dos incidentes comuns, liberando o time de operações para focar em problemas realmente complexos. O resultado é uma infraestrutura self-healing mais resiliente, com menor MTTR e maior confiança operacional em ambientes de produção críticos.

Tag

Posts Relacionados