Lección 7: Actualizaciones progresivas y reversión
Ya tenemos un Deployment que mantiene varias copias (Pods) de la app. Pero ¿qué pasa cuando queremos lanzar una nueva versión — por ejemplo, cambiar la image de nginx:1.27 a nginx:1.28? La forma ingenua es tumbar todo y reconstruirlo, pero entonces el servicio cae por unos segundos y todos los usuar
Es como cambiar las llantas de un carro en movimiento sin detenerlo — cambias una rueda a la vez, así el carro sigue andando. Y si la rueda nueva viene doblada, simplemente vuelves a poner la vieja.
- Actualización progresiva
- Una forma de actualizar un Deployment sin tiempo de inactividad: Kubernetes reemplaza los Pods viejos por nuevos de forma gradual, unos cuantos a la vez, de modo que siempre queden suficientes copias vivas para atender solicitudes.
- Reversión
- Devolver el Deployment a la revisión anterior que funcionaba, cuando la nueva versión resulta fallida. El comando kubectl rollout undo hace esto en un solo paso.
- Estado del rollout
- Seguimiento en vivo del progreso de una actualización: cuántos Pods ya se actualizaron del total, hasta que un mensaje confirma que el rollout terminó con éxito.
- maxUnavailable
- Cuántos Pods pueden estar no disponibles a la vez durante una actualización progresiva. Un valor bajo mantiene más copias vivas en todo momento, pero hace la actualización más lenta.
- maxSurge
- Cuántos Pods adicionales más allá del objetivo se pueden crear temporalmente durante una actualización, para que las copias nuevas estén listas antes de eliminar las viejas.
- Revisión
- Una versión guardada del Deployment. Cada actualización crea una revisión nueva, y Kubernetes recuerda las anteriores para que puedas volver a ellas.
