Boost Academy
FormaciónEvaluacionesPerfil
Volver
  • En directo

Kubernetes — Intermedio

8h de clase en directo·HACK A BOSS·Español

Skills que aprenderás

  • kubernetes

Convocatorias

Necesitas un plan activo

Para acceder a los cursos en directo necesitas un plan activo. Estamos trabajando para que los planes estén disponibles pronto — ¡mantente atento!

No hay convocatorias abiertas ahora mismo, pero no te pierdas la oportunidad: guarda este curso y te avisamos en cuanto se abra una convocatoria.

Descripción

Objetivos

Temario

Requisitos técnicos

Conocimientos previos

Detalles de la 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.

  1. Comparar los controladores Deployment, StatefulSet y DaemonSet para seleccionar el más adecuado ante distintos tipos de carga de trabajo, distinguiendo sus diferencias conceptuales y sus casos de uso canónicos.
  2. Justificar la configuración de 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.
  3. Diseñar un conjunto de manifiestos YAML multi-recurso —Deployment, Service, ConfigMap y PersistentVolumeClaim— para desplegar una aplicación stateless con almacenamiento persistente en un clúster Kubernetes local.
  4. Diseñar una estrategia de despliegue RollingUpdate con los parámetros maxSurge y maxUnavailable configurados explícitamente, incluyendo un procedimiento de rollback documentado ante fallo de versión.
  5. Integrar sondas de salud (liveness, readiness y startup probe) en el manifiesto de un pod, justificando los valores de temporización y umbral de fallo según el comportamiento de arranque de la aplicación.
  6. Adaptar la exposición de una aplicación migrando su tipo de Service de NodePort a Ingress con enrutamiento por path, argumentando la decisión en términos de seguridad y escalabilidad.
  7. Diseñar la segregación de recursos de una aplicación multi-entorno usando namespaces distintos con ResourceQuota y LimitRange definidos por namespace.
  8. Depurar un pod en estado 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.

  • Equipo con mínimo 8 GB de RAM y 4 núcleos de CPU disponibles para el clúster local de práctica.
  • Sistema operativo: Linux, macOS o Windows 10/11 con WSL2 habilitado.
  • kubectl v1.28 o superior instalado y configurado con acceso al clúster local.
  • Clúster Kubernetes local operativo: minikube v1.32+, kind v0.22+ o equivalente, con al menos un nodo worker disponible.
  • Controlador Ingress habilitado en el clúster local (p. ej. minikube addons enable ingress o despliegue de ingress-nginx en kind).
  • Editor de código con soporte YAML y validación de esquemas Kubernetes (VS Code con extensión Kubernetes recomendado).
  • Acceso a internet para descarga de imágenes de contenedor desde Docker Hub o registro equivalente.
  • Comprensión de los objetos fundamentales de Kubernetes: Pod, Deployment, Service, ConfigMap y Namespace.
  • Capacidad para crear y aplicar manifiestos YAML básicos con kubectl apply y verificar el estado de los recursos con kubectl get y kubectl describe.
  • Familiaridad con los conceptos de contenedor e imagen Docker: construcción básica, registro y ejecución.
  • Conocimiento operativo de la línea de comandos Linux: navegación de sistema de ficheros, variables de entorno y redirección de salida.
  • Acceso y configuración de un clúster local (minikube, kind o equivalente) como entorno de práctica.