Skills que aprenderás
Convocatorias
No hay convocatorias abiertas ahora mismo, pero no te pierdas la oportunidad: guarda este curso y te avisamos en cuanto se abra una convocatoria.
Recursos
No hay recursos disponibles todavía para esta convocatoria
Dirigido a profesionales que ya dominan los fundamentos de Kubernetes y desean consolidar capacidades operativas para gestionar cargas de trabajo reales en clústeres locales o de laboratorio. A lo largo de las ocho horas del curso, el participante pasará de crear manifiestos aislados a orquestar conjuntos de recursos YAML multi-componente, elegir el controlador adecuado según el tipo de aplicación, configurar estrategias de despliegue con procedimientos de rollback, integrar sondas de salud con parámetros justificados, exponer servicios a través de Ingress, diagnosticar pods en estado de error y diseñar la segregación de entornos mediante namespaces con cuotas de recursos. Al finalizar, el participante será capaz de desplegar y operar aplicaciones de complejidad media en Kubernetes, tomando decisiones de diseño argumentadas y resolviendo incidencias habituales de forma autónoma.
requests y limits de CPU y memoria en los contenedores, explicando su impacto en el scheduling del clúster y en la estabilidad del nodo ante picos de carga.maxSurge y maxUnavailable configurados explícitamente, incluyendo un procedimiento de rollback documentado ante fallo de versión.NodePort a Ingress con enrutamiento por path, argumentando la decisión en términos de seguridad y escalabilidad.ResourceQuota y LimitRange definidos por namespace.CrashLoopBackOff o OOMKilled en un entorno de práctica predispuesto, identificando la causa raíz mediante las herramientas de inspección y el análisis de eventos del clúster.Bloque 1 — Controladores y modelo de carga de trabajo (aprox. 1,5 h)
Se analizan en profundidad los tres controladores principales de Kubernetes: Deployment, StatefulSet y DaemonSet. El bloque explora las diferencias conceptuales entre cargas sin estado, con estado y distribuidas por nodo, y proporciona criterios objetivos para seleccionar el controlador correcto ante escenarios de aplicación concretos. Se relaciona esta elección con la configuración de requests y limits de CPU y memoria, estudiando cómo el scheduler utiliza estos valores para ubicar los pods y cómo los límites protegen la estabilidad del nodo frente a picos inesperados de consumo.
Bloque 2 — Manifiestos multi-recurso y almacenamiento persistente (aprox. 2 h) El participante construye desde cero un conjunto de manifiestos YAML que integra Deployment, Service, ConfigMap y PersistentVolumeClaim para desplegar una aplicación stateless con necesidades de almacenamiento. Se presta especial atención a la coherencia entre recursos —etiquetas, selectores y referencias de volumen— y a las decisiones de diseño que determinan la portabilidad y mantenibilidad del conjunto de manifiestos en distintos entornos.
Bloque 3 — Estrategias de despliegue, sondas de salud y rollback (aprox. 2 h)
Se trabaja la estrategia RollingUpdate configurando explícitamente maxSurge y maxUnavailable para controlar el ritmo de sustitución de pods durante una actualización. A continuación se incorporan las tres sondas de salud —liveness, readiness y startup probe— al manifiesto, justificando los parámetros de temporización según el comportamiento real de arranque de la aplicación. El bloque cierra con el diseño de un procedimiento de rollback documentado que permite revertir a la versión anterior ante un fallo detectado en producción.
Bloque 4 — Exposición de servicios con Ingress (aprox. 1 h)
Se compara la exposición mediante NodePort con el uso de un controlador Ingress con enrutamiento por path. El bloque aborda los beneficios en términos de seguridad —terminación TLS centralizada, reducción de puertos expuestos— y de escalabilidad —gestión de múltiples servicios bajo un único punto de entrada— guiando al participante en la reescritura del manifiesto de exposición y en la verificación del enrutamiento configurado.
Bloque 5 — Namespaces, cuotas y segregación de entornos (aprox. 1 h)
Se diseña una arquitectura de namespaces para separar los entornos de desarrollo y staging de una misma aplicación. El bloque cubre la definición de ResourceQuota para limitar el consumo agregado de recursos por namespace y de LimitRange para establecer valores por defecto y máximos por contenedor, analizando cómo estas políticas protegen la estabilidad global del clúster ante configuraciones incorrectas de los equipos de desarrollo.
Bloque 6 — Diagnóstico y resolución de incidencias (aprox. 0,5 h)
En un entorno de práctica con fallos predispuestos, el participante aplica un flujo de diagnóstico sistemático para identificar la causa raíz de pods en estado CrashLoopBackOff u OOMKilled. Se trabaja el uso combinado de kubectl logs, kubectl describe y el análisis de la sección de eventos del clúster, desarrollando un criterio de triaje que permita distinguir errores de configuración, de imagen, de recursos insuficientes o de dependencias externas.
kubectl v1.28 o superior instalado y configurado con acceso al clúster local.minikube addons enable ingress o despliegue de ingress-nginx en kind).kubectl apply y verificar el estado de los recursos con kubectl get y kubectl describe.