Kubernetes en producción: las 7 reglas que todo SRE debe seguir

He visto clusters de Kubernetes caerse por no seguir reglas básicas. Aquí están las 7 que SÍ importan.

---

Por qué importa

Kubernetes es poderoso pero también complejo. Un cluster mal configurado se cae en producción. Estas 7 reglas vienen de errores que cuestan tiempo, dinero y reputación.

---

Regla 1: SIEMPRE define resource requests y limits

El error más común en clusters de Kubernetes: pods sin limits que consumen toda la RAM del nodo y tumban otros pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mi-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: mi-app:1.0
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Cómo elegir los valores: 1. Empieza con valores razonables (los de arriba) 2. Mide uso real con kubectl top pod 3. Ajusta después de ver patrones reales

Sin requests: el scheduler no puede calcular bien dónde poner tu pod Sin limits: un pod puede consumir todo el nodo

---

Regla 2: Health checks SIEMPRE (liveness + readiness)

Sin health checks, Kubernetes no sabe si tu app está viva. Un pod con deadlock sigue “Running” indefinidamente.

spec:
  containers:
  - name: app
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

Liveness: “¿Está vivo este pod? Si no, restart” Readiness: “¿Puede recibir tráfico? Si no, sácalo del load balancer”

Tip: el endpoint /healthz debe ser rápido (< 100ms) y no chequear dependencias externas (DB, cache). Si DB está caída, no quieres que Kubernetes reinicie tu app cada 10s.

---

Regla 3: Secrets en External Secrets Operator, no en ConfigMaps

Anti-pattern común: poner passwords en ConfigMaps o en el código.

# ❌ MAL
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_PASSWORD: "supersecret123"

Cómo hacerlo bien con External Secrets Operator + AWS Secrets Manager / HashiCorp Vault:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-credentials-secret
  data:
  - secretKey: password
    remoteRef:
      key: prod/db/password

Kubernetes crea automáticamente un Secret. Tu app lo lee de forma normal.

Alternativa simple: Sealed Secrets (cifrados en Git, descifrados por controller en cluster).

---

Regla 4: Backups de etcd Y de los datos

Backup de etcd

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%F).db 
  --endpoints=https://127.0.0.1:2379 
  --cacert=/etc/kubernetes/pki/etcd/ca.crt 
  --cert=/etc/kubernetes/pki/etcd/server.crt 
  --key=/etc/kubernetes/pki/etcd/server.key

Backup de datos de apps

Usa Velero (https://velero.io):

velero backup create daily-$(date +%F) --include-namespaces production

Cron automático:

apiVersion: velero.io/v1
kind: Schedule
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"
  template:
    includedNamespaces:
    - production
    storageLocation: default
    ttl: 720h  # 30 días

---

Regla 5: Network Policies restrictivas por default

Default peligroso: cualquier pod puede hablar con cualquier otro pod.

Cómo arreglar:

# Default deny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Después, permite solo lo necesario:

# Permitir ingress al frontend desde el IngressController
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: ingress-nginx
    ports:
    - port: 80
      protocol: TCP

Si te da pereza esto, al menos pon un NetworkPolicy global que bloquee egress a internet (para que pods hackeados no exfiltren datos).

---

Regla 6: HPA + PDB para resiliencia

HorizontalPodAutoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

PodDisruptionBudget (PDB)

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: api

Esto dice: “Durante un deploy o mantenimiento, al menos 1 pod debe estar disponible”. Evita que un rolling update tumbe toda la app.

---

Regla 7: Monitoring + alerting real

Lo mínimo obligatorio:

1. Métricas de infraestructura (Prometheus + node_exporter) 2. Métricas de aplicación (Prometheus + exporters de app) 3. Logs centralizados (Loki o ELK) 4. Tracing distribuido (Jaeger o Tempo) 5. Alertas con runbook (AlertManager + PagerDuty)

Alertas que importan

# Alert: pod en CrashLoopBackOff
- alert: PodCrashLooping
  expr: rate(kube_pod_container_status_restarts_total[5m]) > 0
  for: 5m
  annotations:
    summary: "Pod {{ $labels.pod }} reiniciando frecuentemente"
    runbook: "https://wiki/runbooks/pod-crash"
# Alert: alta latencia
- alert: HighP99Latency
  expr: histogram_quantile(0.99, http_request_duration_seconds_bucket) > 1
  for: 5m
  annotations:
    summary: "P99 latency > 1s"
    runbook: "https://wiki/runbooks/latency"

Anti-pattern: alertar por todo. Si todo es urgente, nada es urgente. Solo alerta lo que requiere acción humana.

---

Resumen

Regla	Impacto	Costo
1. Resource limits	Alto	Bajo
2. Health checks	Alto	Bajo
3. External secrets	Alto	Medio
4. Backups	Crítico	Medio
5. Network policies	Alto	Medio
6. HPA + PDB	Alto	Bajo
7. Monitoring	Crítico	Alto

Aplica las 7 reglas desde día 1. Es 10x más difícil aplicarlas después cuando el cluster está en producción.

---

Lee también: Docker en producción si quieres empezar con containers antes de Kubernetes, o Ansible desde cero para automatizar tu cluster.

---

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux