Este documento explica, de forma sencilla y estructurada, cómo se organiza una aplicación dentro del clúster.
No es solo un ejemplo técnico.
Es el patrón que seguimos para que todo sea ordenado, reproducible y GitOps‑friendly.
Un manifiesto es un archivo YAML que describe un recurso de Kubernetes.
No ejecuta nada directamente.
Describe el estado que queremos que exista en el clúster.
Ejemplo mental:
Cada uno de esos deseos se convierte en un archivo YAML.
Kubernetes compara lo que existe con lo que describes… y actúa para que coincida.
Eso se llama modelo declarativo.
Podríamos hacerlo.
Pero no sería:
Por eso usamos una estructura por carpetas, donde cada tipo de recurso tiene su responsabilidad.
.
├── namespace.yaml
├── deployments/
├── services/
├── pvc/
├── ingress/
├── configmaps/
├── rbac/
└── kustomization.yaml
Cada carpeta representa una pieza del sistema.
No mezclamos responsabilidades.
El Namespace separa recursos dentro del clúster.
Sirve para:
Sin namespace, todo estaría mezclado.
Si una aplicación necesita guardar datos (base de datos, archivos, etc.),
no se conecta a un disco físico directamente.
Solicita almacenamiento mediante un:
👉 PersistentVolumeClaim (PVC)
El PVC declara:
La aplicación no sabe si está usando Ceph, iSCSI, NFS o una cabina.
Eso es desacoplamiento.
En Kubernetes, desplegar una aplicación significa elegir qué recurso va a crear y mantener los Pods.
Un Pod es una instancia única.
Problema:
👉 En producción casi nunca es la opción correcta.
Un Deployment gestiona pods sin identidad fija.
Permite:
Es el estándar para:
Porque con almacenamiento distribuido o arquitecturas desacopladas:
👉 Si no tienes un motivo claro para otra cosa, usa Deployment.
Un StatefulSet es como un Deployment, pero:
db-0, db-1…)Se usa en:
Es una herramienta potente, pero más compleja.
Un DaemonSet asegura que haya un pod en cada nodo.
Se usa en:
Es el recurso adecuado cuando algo debe estar pegado al nodo.
Los Pods tienen IP dinámica.
El Service crea un punto estable dentro del clúster.
Tipos habituales:
El Service conecta el mundo interno con la aplicación.
Si la aplicación necesita un dominio:
app.ejemplo.com
El Ingress define:
El Ingress no ejecuta nada por sí solo.
Lo hace el Ingress Controller.
Las aplicaciones necesitan parámetros.
Esto evita meter configuración dentro de la imagen Docker.
Es separación limpia entre código y configuración.
Si una aplicación necesita hablar con el API de Kubernetes:
Principio básico:
👉 Mínimos privilegios.
No todo vive dentro de Kubernetes.
A veces una app necesita hablar con:
Se puede crear un Service puente.
Apunta a un DNS externo.
Sencillo pero limitado.
Defines:
Resultado:
Desde dentro del clúster se usa un nombre interno estable,
pero realmente apunta fuera.
Esto integra recursos externos como si fueran internos.
kustomization.yaml agrupa recursos.
Cuando ejecutas:
kubectl apply -k .
Se aplican todos los manifiestos declarados.
Pero Kustomize no solo agrupa.
También permite variantes reutilizables.
Cuando quieres:
No copias archivos.
Se usa:
base/
overlays/
base/ → definición genéricaoverlays/ → variacionesEvitan colisiones.
Ejemplo:
wg-apolo → wg-apolo-3
Hay dos grandes tipos:
Sobrescribe bloques YAML.
Ideal para:
Más quirúrgico.
Perfecto para:
Si algo no es parcheable limpiamente:
Se añade como resources: en el overlay.
El base queda limpio.
El overlay documenta la diferencia.
[Usuario]
│
▼
[Ingress]
│
▼
[Service]
│
▼
[Deployment / StatefulSet / DaemonSet]
│
▼
[Pod]
│
├── usa PVC
├── usa ConfigMap
└── usa Secret
Cada pieza tiene una responsabilidad.
Nada está mezclado.
Si entiendes este documento, entiendes la base del clúster.
Ideas clave:
No desplegamos contenedores.
Declaramos sistemas completos, ordenados y versionables.