Escribir manifiestos de Kubernetes a mano es propenso a errores de indentación YAML y a olvidar campos críticos como los probes de salud o los límites de recursos, algo que en producción se traduce en pods reiniciándose sin control o consumiendo toda la memoria de un nodo. Este generador construye Deployments, Services e Ingress completos con las prácticas recomendadas por el propio proyecto Kubernetes, listos para aplicar con kubectl apply.
Requests y limits: la diferencia entre programación y throttling
El campo requests le dice al scheduler cuánta CPU y memoria reservar como mínimo garantizado al programar el pod en un nodo; limits es el techo máximo que el pod puede consumir. Si no defines limits de memoria, un proceso con fuga de memoria puede consumir toda la RAM del nodo y provocar que el kernel mate procesos aleatorios (OOM killer) de otros pods vecinos. Si defines limits de CPU muy ajustados, Kubernetes aplica throttling (CFS quota) que ralentiza tu aplicación aunque el nodo tenga CPU libre; por eso muchas guías recomiendan definir requests de CPU realistas pero no limits de CPU en cargas sensibles a la latencia.
Liveness, readiness y startup probes
El livenessProbe le dice a Kubernetes cuándo reiniciar un contenedor que se ha quedado colgado internamente aunque el proceso siga vivo. El readinessProbe controla si el pod recibe tráfico del Service: un pod que está arrancando o recalentando caché debe fallar el readiness sin que eso dispare un reinicio. El startupProbe es crítico en aplicaciones con arranque lento (JVM con caches grandes): sin él, el liveness puede matar el contenedor antes de que termine de iniciar, generando un bucle de reinicios (CrashLoopBackOff) que nunca converge.
Service: ClusterIP, NodePort y LoadBalancer
Un Service de tipo ClusterIP expone el pod solo dentro del clúster, la opción por defecto para comunicación interna entre microservicios. NodePort abre un puerto fijo en cada nodo del clúster, útil para pruebas pero poco recomendable en producción por la gestión manual de puertos. LoadBalancer aprovisiona automáticamente un balanceador del proveedor cloud (ELB en AWS, forwarding rule en GCP) y es la opción habitual para exponer un servicio a internet en un clúster gestionado.
Ingress: enrutado HTTP y TLS centralizado
Un recurso Ingress permite enrutar tráfico HTTP/HTTPS de múltiples dominios y rutas hacia distintos Services usando un único punto de entrada (un controlador como NGINX Ingress o Traefik), evitando aprovisionar un LoadBalancer por cada microservicio. Con cert-manager y una anotación adecuada, el certificado TLS se emite y renueva automáticamente vía Let's Encrypt, eliminando la gestión manual de certificados que antes requería reiniciar servicios.
Etiquetas, selectores y el error de desconexión silenciosa
Un Deployment y su Service se conectan exclusivamente por coincidencia de labels y selectors, sin ninguna referencia por nombre. El error más frecuente es cambiar una etiqueta en el Deployment (por ejemplo al renombrar una app) y olvidar actualizar el selector del Service: el resultado es un Service que sigue existiendo pero no enruta tráfico a ningún pod, sin ningún mensaje de error visible salvo timeouts en el cliente.
Estrategias de despliegue: RollingUpdate vs Recreate
RollingUpdate, la estrategia por defecto, sustituye pods gradualmente manteniendo siempre un número mínimo disponible, ideal para servicios sin downtime tolerado. Recreate mata todos los pods antiguos antes de crear los nuevos, apropiado solo cuando la aplicación no soporta tener dos versiones corriendo simultáneamente (por ejemplo, por migraciones de esquema incompatibles). Ajusta maxSurge y maxUnavailable según la capacidad extra que tu clúster pueda absorber durante el despliegue.
De YAML manual a GitOps
Aplicar manifiestos sueltos con kubectl apply funciona para pruebas, pero en equipos que gestionan varios entornos (dev, staging, producción) la práctica recomendada es versionar estos manifiestos en Git y sincronizarlos automáticamente con herramientas como ArgoCD o Flux, de forma que el estado del clúster siempre refleje lo que hay en el repositorio. Combina este generador con el generador de playbooks de Ansible cuando necesites aprovisionar la infraestructura subyacente (nodos, redes) antes de desplegar sobre Kubernetes.
Casos de uso comunes
- Desplegar una API REST con autoescalado horizontal y probes de salud correctos.
- Exponer un microservicio interno solo dentro del clúster con un Service ClusterIP.
- Configurar un Ingress con TLS automático para varios subdominios.
- Migrar un despliegue manual con kubectl run a manifiestos versionados en Git.
- Definir límites de recursos antes de que un pod monopolice un nodo compartido.
Buenas prácticas
- Define siempre requests de CPU y memoria; evita limits de CPU en servicios sensibles a latencia.
- Añade readinessProbe y livenessProbe distintos; nunca uses el mismo endpoint para ambos sin justificación.
- Usa startupProbe en aplicaciones con arranque superior a 10-15 segundos.
- Versiona los manifiestos en Git en vez de aplicarlos manualmente en producción.
- Revisa que labels del Deployment y selector del Service coincidan tras cualquier renombrado.