Kubernetes en producción: 10 errores que cuestan tickets críticos

Después de operar clusters Kubernetes en producción por varios años (E-commerce, SaaS B2B, banca), estos son los 10 errores que más tickets críticos generan. Ninguno es exótico — son cosas que todo el mundo "sabe" pero que el 70% de los clusters siguen teniendo.

Errores de configuración

1 · Resource limits ausentes o mal calibrados

El error más común. Sin limits, un pod con memory leak come toda la RAM del nodo y mata a sus vecinos vía OOM kill.

Antes (peligroso):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          image: astrum/api:1.2.3
          # ← sin resources. Default: usa lo que quiera.

Después (sano):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  template:
    spec:
      containers:
        - name: api
          image: astrum/api:1.2.3
          resources:
            requests:
              cpu: 100m
              memory: 256Mi
            limits:
              cpu: 1000m       # max 1 vCPU
              memory: 512Mi    # max 512 MB · OOMKill si supera
          # Bonus: si haces requests=limits, K8s asigna QoS Guaranteed

2 · HPA peleándose con Cluster Autoscaler

Horizontal Pod Autoscaler quiere escalar pods (más réplicas). Cluster Autoscaler quiere escalar nodos (más máquinas). Sin coordinación, terminan en loops: HPA pide más pods → no entran en los nodos → CA agrega nodos → pods schedulean → load baja → CA retira nodos → HPA agrega pods otra vez.

La solución es configurar bien los thresholds y agregar margin:

• HPA: --horizontal-pod-autoscaler-cpu-initialization-period=60s (espera 1 min antes de medir).
• CA: --scale-down-delay-after-add=10m (no retira nodos recién agregados por 10 min).
• Pods: PodDisruptionBudgets para que CA no pueda evict pods críticos.

3 · Liveness probes muy agresivos

Un livenessProbe con initialDelaySeconds: 5 y failureThreshold: 1 parece responsable. En realidad: si tu app tarda 8s en arrancar bajo carga, K8s te mata el pod a los 5s, vuelve a crearlo, vuelve a tardar 8s, vuelve a matarlo… loop infinito.

# Configuración defensiva (deja margen para arranques lentos)
livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3      # 3 fails seguidos antes de matar
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 2

Errores de operación

4 · "Vamos a aplicar a prod"

Sin kubectl diff previo. Sin canary. Sin rollback plan. El apply aplica TODO y si rompe rompe.

"Una vez modifiqué un ConfigMap con una key mal escrita y rolling-update destruyó 12 pods en 30 segundos. El rollback me llevó 4 minutos. Eso es 4 minutos sin servicio. En e-commerce eso son miles de dólares."

Pipeline GitOps mínimo:

1. Cambio en branch → PR → CI corre kubectl diff contra cluster.
2. Review obligatorio (al menos 1 aprobador).
3. Merge a main → ArgoCD/Flux sincroniza automáticamente.
4. Healthchecks post-deploy. Si fail por >2min → rollback automático.

5 · Logs no centralizados

Cuando algo falla a las 3am, no querés hacer kubectl logs --previous en 17 pods buscando el stack trace. Necesitás Loki / Elasticsearch / Datadog donde grepees todo de un toque.

Resumen ejecutivo

Si tu cluster sufre alguno de estos errores, no estás solo — son endémicos. Pero también son TODOS prevenibles con disciplina operativa y buenas templates de YAML.

• Tooling crítico: GitOps + observability + capacity planning + chaos engineering (1 día al mes).
• Pricing: un buen SRE cuesta lo que cuesta un downtime de 2 horas. Hacé las cuentas.
• Cultura: "si duele, hazlo más seguido" — Martin Fowler. Deploys diarios, no semanales.

En Astrum operamos clusters de clientes en AWS EKS, GCP GKE y on-prem. Si querés un health-check gratuito de tu cluster, escribinos.