Acciones típicas en Kubernetes

Hay un puñado de operaciones que aparecen una y otra vez al operar un cluster: ejecutar tareas programadas, controlar dónde se ubican los pods y otorgar permisos a un ServiceAccount. Esta guía recoge patrones que usamos en el día a día con su sintaxis lista para copiar.

Ejecutar CronJobs

Un CronJob ejecuta un Job en un horario al estilo cron. Sirve para backups, limpieza, reportes, sincronizaciones, etc.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-diario
spec:
  schedule: "0 2 * * *"            # 02:00 todos los días
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: tuempresa/backup:1.2
              args: ["/scripts/backup.sh"]

Patrón sidecar

Si la aplicación principal del pod ya viene con las dependencias que necesitas para tu tarea (CLI de la base de datos, credenciales, conexión a la VPN…), puedes reutilizar esa misma imagen como sidecar dentro del CronJob:

containers:
  - name: app
    image: tuempresa/app:1.2
  - name: cron-runner
    image: tuempresa/app:1.2        # misma imagen, distinto comando
    command: ["/bin/sh", "-c", "/app/run-mantenimiento.sh"]

Así evitas mantener dos imágenes con configuración redundante.

Topology Keys y ubicación de pods

Los nodos llevan labels (kubernetes.io/hostname, topology.kubernetes.io/zone, node-role.kubernetes.io/worker, etc.). Esas claves son las topology keys que usa el scheduler para decidir dónde colocar pods.

Tres usos típicos:

• Distribuir entre zonas con topologySpreadConstraints:

  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: api

• Evitar que dos réplicas caigan en el mismo nodo con anti-affinity:

  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels: { app: api }
          topologyKey: kubernetes.io/hostname

• Forzar que un pod corra junto a otro con affinity, usando la misma topologyKey (mismo nodo, misma zona, etc.).

Regla mental: el topologyKey define la unidad de agrupación (nodo, zona, rack). El label selector define a quién aplica la regla.

RoleBinding por línea de comandos

Para enlazar un Role existente a un ServiceAccount sin escribir YAML:

kubectl -n <ns> create rolebinding <nombre-binding> \
  --role=<nombre-role> \
  --serviceaccount=<ns>:<nombre-sa>

Ejemplo real: dar a process-sa los permisos del Role processor dentro del namespace data:

kubectl -n data create rolebinding process \
  --role=processor \
  --serviceaccount=data:process-sa

Variantes útiles:

# Enlazar un ClusterRole a un usuario en un namespace
kubectl -n app create rolebinding admin-binding \
  --clusterrole=admin \
  --user=[email protected]

# Enlazar un ClusterRole a un grupo en todo el cluster
kubectl create clusterrolebinding view-all \
  --clusterrole=view \
  --group=auditors

Recuerda agregar --dry-run=client -o yaml para guardar el manifiesto en lugar de aplicarlo directamente; así puedes versionarlo en git.

Cheatsheet final

Quiero…	Comando
Tareas periódicas	kubectl create cronjob nombre --image=img --schedule="..."
Ver labels de nodos	kubectl get nodes --show-labels
Top de recursos por nodo	kubectl top nodes
Top de recursos por pod	kubectl top pods -A
Ordenar por CPU	kubectl top pods -A --sort-by=cpu
Validar permisos	kubectl auth can-i <verb> <res> --as=...

Dominar estas acciones cubre quizá el 80% del trabajo cotidiano sobre un cluster.