Arranca el segundo dominio. Cómo Kubernetes corre y mantiene tus aplicaciones: Deployments, DaemonSets, StatefulSets, cómo se configuran con ConfigMaps y Secrets, y cómo escalan solos con HPA.
# Crear un deployment
k create deploy web --image=nginx --replicas=3
# Escalar
k scale deploy web --replicas=5
# Ver el deployment, sus RS y pods
k get deploy,rs,pods# Cambiar la imagen (dispara un rollout)
k set image deploy/web nginx=nginx:1.27
# Ver el estado del rollout
k rollout status deploy/web
# Ver el historial de revisiones
k rollout history deploy/web# Volver a la revisión anterior
k rollout undo deploy/web
# Volver a una revisión específica
k rollout undo deploy/web --to-revision=2rollout es de examen puro: te piden actualizar una imagen y verificar, o "volvé a la versión anterior porque la nueva falla". Los comandos set image, rollout status/history/undo tienen que salir rápido.Hay tres capas y cada una tiene su rol:
Cada vez que cambiás la imagen, el Deployment crea un ReplicaSet nuevo y va moviendo pods del viejo al nuevo (rolling update). El RS viejo queda con 0 réplicas — por eso el rollback es rápido: solo reactiva el RS anterior.
Por defecto el Deployment usa RollingUpdate (reemplaza pods de a poco, sin downtime). La otra estrategia es Recreate (mata todos, después crea todos — con downtime, pero útil si no pueden coexistir versiones).
# No hay 'create daemonset' imperativo.
# Truco: generar un deployment y editar el kind
k create deploy logger --image=fluentd $do > ds.yaml
# editar: kind: Deployment → DaemonSet
# quitar: replicas y strategy
# Verlos (ya tenés varios en tu cluster)
k get daemonsets -A
# calico-node y kube-proxy son DaemonSets# Ver los StatefulSets
k get statefulsets
# Los pods tienen nombre predecible:
# db-0, db-1, db-2 (no hash aleatorio)calico-node y kube-proxy corren uno por nodo. Por eso en el upgrade usabas drain --ignore-daemonsets: no se pueden mover, hay uno fijo por nodo.| Controller | Para qué |
|---|---|
| Deployment | Apps sin estado. Réplicas intercambiables |
| DaemonSet | Un pod en CADA nodo (logs, red, monitoreo) |
| StatefulSet | Apps con estado: identidad y almacenamiento estables |
Ideal para bases de datos, colas, cualquier cosa donde "quién es quién" importa.
¿Los pods son intercambiables? → Deployment. ¿Necesitás uno por nodo? → DaemonSet. ¿Cada pod es único y tiene datos propios? → StatefulSet.
# ConfigMap desde literales
k create configmap app-cfg \
--from-literal=COLOR=blue \
--from-literal=MODE=prod
# ConfigMap desde un archivo
k create configmap app-cfg --from-file=config.txt
# Secret (se guarda en base64, no cifrado por defecto)
k create secret generic db-pass \
--from-literal=password=s3cr3tspec:
containers:
- name: app
image: nginx
envFrom:
- configMapRef:
name: app-cfg
- secretRef:
name: db-passenv:
- name: COLOR
valueFrom:
configMapKeyRef:
name: app-cfg
key: COLORvolumes:
- name: cfg
configMap:
name: app-cfg
# y en el container:
volumeMounts:
- name: cfg
mountPath: /etc/configLa misma imagen (nginx) debe correr en dev, staging y prod sin recompilar. La configuración cambia por entorno; la imagen no. ConfigMaps y Secrets inyectan esa config en runtime.
| ConfigMap | Secret |
|---|---|
| Config no sensible | Datos sensibles |
| Texto plano | base64 (NO cifrado) |
| URLs, flags, modos | Passwords, tokens, certs |
# Escalar 'web' entre 2 y 10 réplicas,
# objetivo: 50% de CPU
k autoscale deploy web \
--min=2 --max=10 --cpu-percent=50
# Ver los HPA y su estado actual
k get hpa
k describe hpa web<unknown> en los targets. En clusters de práctica hay que instalarlo aparte.# El HPA calcula el % sobre el 'request', así que
# el deployment DEBE tener resources.requests.cpu
resources:
requests:
cpu: 100mVigila una métrica (típicamente CPU) de los pods de un Deployment. Si la carga supera el objetivo, agrega réplicas; si baja, las quita. Todo dentro del rango min/max que definís.
Si el objetivo es 50% de CPU y los pods están al 100%, el HPA duplica las réplicas para repartir la carga a la mitad. Es proporcional: apunta a que el promedio quede en el target.
# Deployments
k create deploy NAME --image=IMG --replicas=N
k scale deploy NAME --replicas=N
k set image deploy/NAME cont=img:tag
k rollout status/history/undo deploy/NAME
# ConfigMaps / Secrets
k create configmap NAME --from-literal=K=V
k create secret generic NAME --from-literal=K=V
# consumir: envFrom (todo) o env+valueFrom (una)
# HPA
k autoscale deploy NAME --min=2 --max=10 --cpu-percent=50
# DaemonSet: no hay imperativo →
# generar deploy con $do y cambiar kind