Introducción
Has llegado al desafío final de este curso para principiantes. En los laboratorios anteriores trabajaste con Pods, Deployments, Services, escalado, resolución de problemas y reversión. Ahora combinarás todos esos conceptos en una pequeña tarea de publicación, sin seguir una guía comando por comando.
El entorno contiene una versión inicial saludable llamada web-app. Tu tarea consiste en publicar la siguiente versión fijada de la imagen de NGINX, conservando tres réplicas disponibles y el Service estable. El estado final del clúster y el manifiesto guardado deben coincidir para que la versión pueda reproducirse después del desafío.
Publicar la siguiente versión de NGINX
Inicio del entorno: Este laboratorio inicia un clúster de Kubernetes completo. La configuración del plano de control, el nodo y los componentes de red suele tardar 2–3 minutos. Espera pacientemente a que el entorno termine de cargarse antes de comenzar.
Situación actual
El equipo de la plataforma ha preparado una versión inicial en /home/labex/project/final-release/web-app.yaml. Actualmente ejecuta nginx:1.26-alpine con tres réplicas detrás del Service web-app.
Alcance
- Trabaja con el Deployment
web-app, el Service, el manifiesto y el clienterelease-checkexistentes. - No cambies los nombres de los recursos, los selectores ni el presupuesto aprobado para la actualización progresiva.
- Utiliza la imagen de destino fijada; las etiquetas flotantes como
latestno forman parte de la versión aceptada.
Tu objetivo
Publica nginx:1.27-alpine mediante el Deployment existente y deja el clúster activo, la ruta de acceso del Service y el manifiesto guardado en un estado saludable y reproducible.
Criterios de aceptación
- El Deployment
web-appdebe tener exactamente tres réplicas deseadas. - El contenedor
nginxdebe utilizar exactamente la imagen fijadanginx:1.27-alpine. - El presupuesto de actualización progresiva debe conservarse como
maxUnavailable: 0ymaxSurge: 1. - La anotación de causa del cambio debe describir la versión de NGINX 1.27.
- El Service
web-appdebe seguir seleccionando los Pods del Deployment y tener tres backends listos. - Las tres réplicas actualizadas deben estar listas y disponibles, y una solicitud HTTP dentro del clúster a
http://web-appdebe tener éxito. /home/labex/project/final-release/web-app.yamldebe contener la imagen final y la configuración de la actualización, de modo que volver a aplicarlo conserve el estado aceptado.
Utiliza los comandos de inspección y de actualización progresiva de Kubernetes para determinar cuándo se ha completado la versión. Si la actualización todavía está en curso, espera a que termine en lugar de basarte únicamente en el primer resultado de kubectl get.
Pistas
Entre las observaciones útiles se encuentran las columnas READY, UP-TO-DATE y AVAILABLE del Deployment; las imágenes de los Pods; el historial de actualizaciones; y las direcciones de EndpointSlice del Service.
Resumen
Has completado el curso publicando de forma independiente una imagen fijada de NGINX mediante un Deployment de Kubernetes. Conservaste un presupuesto explícito de disponibilidad, esperaste a que todas las réplicas actualizadas estuvieran listas, mantuviste el Service conectado a tres backends preparados, verificaste una solicitud dentro del clúster y guardaste el estado aceptado en YAML.
Estas comprobaciones constituyen un flujo de trabajo reutilizable para principiantes: declarar el estado deseado, aplicarlo, observar el progreso del controlador, verificar la carga de trabajo y su ruta de acceso, y mantener el manifiesto sincronizado con el clúster.
