Ajusta la actualización a la cuota

Introducción

Aster Supply sirve su catálogo habitual mientras una actualización de invierno está bloqueada. Su espacio de nombres tiene suficiente CPU solicitada para el funcionamiento normal, pero no para el Pod adicional solicitado durante una actualización progresiva. Elegirás un presupuesto de despliegue que se ajuste a la asignación fija, mantendrás en funcionamiento la tienda de referencia y entregarás el catálogo actualizado.

Debes conocer ya las rutas básicas del terminal, el formato YAML sencillo, los Pods, Deployments, Services y las etiquetas. Este laboratorio explica las unidades de las solicitudes de CPU, ResourceQuota y el cálculo del presupuesto de actualización. El clúster real de un solo nodo, la aplicación, las comprobaciones de salud y los datos del catálogo están preparados; no se requiere instalar el clúster, construir imágenes ni programar la aplicación. El tiempo estimado incluye la lectura y los errores habituales; es una estimación del autor.

Ajusta la actualización al presupuesto fijo

En este paso, terminarás la actualización del catálogo de invierno de Aster Supply sin aumentar su asignación de CPU ni detener la tienda de referencia.

La pestaña Shop muestra un catálogo que funciona. Abre Stoneware tray, anota su precio y usa Back to collection para volver. La colección actual Everyday essentials tiene tres productos; la colección solicitada The winter edit añade Amber cup y cambia los precios. Abre la pestaña Reference: Fern Stationery es un servicio independiente y protegido que debe conservar su catálogo existente. Mantén sin cambios su Deployment, su Service y su Pod original. Después cambia a la pestaña Workspace.

El clúster preparado es Kubernetes real de un solo nodo. Un espacio de nombres agrupa los recursos de este curso. Una ResourceQuota limita el total de recursos admitidos en ese espacio de nombres. Aquí solo contabiliza solicitudes de CPU: CPU reservada para la planificación, no una asignación de dinero ni un límite del uso de CPU medido. 1000m significa un núcleo de CPU; 40m significa 0.04 de un núcleo. La memoria está preparada y no es el cuello de botella de cuota de esta tarea.

Primero lee la cuota. --context=labex-v135 selecciona el clúster preparado, -n shop-quota selecciona el espacio de nombres de este curso y describe muestra los detalles de un objeto:

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Espera ver requests.cpu con Used 140m y Hard 140m. Es CPU reservada, no el uso actual. La tienda original sigue disponible, pero su intento de actualización necesita otro Pod. Una réplica disponible ha superado su comprobación de preparación y el período mínimo preparado de tres segundos en estado listo; crear un Pod no basta para que esté disponible. Lee el Deployment y sus ReplicaSets. Un ReplicaSet mantiene Pods para una plantilla de Deployment; rs es su nombre de recurso abreviado:

kubectl --context=labex-v135 -n shop-quota get deployments,rs,pods

Hay tres réplicas disponibles de la tienda y una réplica de referencia. El nuevo ReplicaSet de la tienda no puede crear su Pod. Describe ambos ReplicaSets de la tienda; -l app=shop selecciona su etiqueta:

kubectl --context=labex-v135 -n shop-quota describe rs -l app=shop

Busca FailedCreate o ReplicaFailure con exceeded quota: shop-budget, requested: requests.cpu=40m, used: requests.cpu=140m y limited: requests.cpu=140m. Es un rechazo de admisión: ese nuevo Pod no se creó. Difiere de un Pod Pending existente que un planificador no puede ubicar. No cambies la cuota ni elimines la carga de trabajo de referencia.

El nuevo catálogo aprobado y el manifiesto candidato ya están proporcionados. Entra explícitamente en el espacio de trabajo. pwd muestra tu directorio actual; ls enumera sus entradas:

cd /home/labex/project/shop-update

pwd

ls

Debes ver approved, starter y tools. cat muestra el catálogo aprobado:

cat approved/catalogue.json

Lee la versión candidata completa con sed -n '1,180p': -n suprime la salida habitual y p muestra las líneas de la 1 a la 180. El intervalo entre comillas es un solo argumento:

sed -n '1,180p' starter/shop.yaml

La tienda necesita tres réplicas, cada una con una solicitud de 40m. La referencia protegida solicita 20m. Solo puede cambiar spec.strategy.rollingUpdate; deben permanecer intactos la nueva plantilla de aplicación proporcionada, las réplicas, los recursos, los selectores y las comprobaciones de salud.

Una actualización progresiva equilibra dos valores. maxSurge permite Pods adicionales por encima del número deseado de réplicas. maxUnavailable permite que algunas réplicas deseadas no estén disponibles. Aquí se requiere al menos dos réplicas disponibles de la tienda durante la actualización observada. Con tres réplicas deseadas, una puede no estar disponible temporalmente, pero no cabe ningún Pod adicional. Elige maxSurge: 0 y maxUnavailable: 1. Ambos valores no pueden ser cero. Recreate, eliminar el Deployment, reducir las solicitudes, reducir el número deseado de réplicas o aumentar la cuota quedan fuera de esta tarea.

Crea un directorio de versión editable y copia la versión candidata proporcionada. mkdir crea un directorio; cp copia el archivo. Los originales proporcionados son de solo lectura. chmod u+w añade permiso de escritura para tu usuario en la copia:

mkdir release

cp starter/shop.yaml release/shop.yaml

chmod u+w release/shop.yaml

Si release ya existe de un intento anterior, consérvalo y continúa con la copia que estás editando. Ante un error al escribir una ruta, usa los comandos pwd, ls y cd absoluto anteriores antes de repetir el comando fallido; una ruta que falta no requiere restablecer la VM.

sed -i edita un archivo directamente. Cada expresión s/old/new/ sustituye el texto mostrado. Las comillas simples mantienen juntos los espacios y la puntuación. Cambia solo los dos valores de despliegue en tu copia:

sed -i 's/maxSurge: 1/maxSurge: 0/' release/shop.yaml

sed -i 's/maxUnavailable: 0/maxUnavailable: 1/' release/shop.yaml

Lee el principio del manifiesto guardado antes de aplicarlo:

sed -n '1,35p' release/shop.yaml

Espera ver replicas: 3, type: "RollingUpdate", maxSurge: 0 y maxUnavailable: 1. apply -f reconcilia este archivo con el Deployment existente; conserva la identidad del Deployment. rollout status espera a las nuevas réplicas, con un --timeout finito:

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Espera ver deployment "shop" successfully rolled out. El controlador puede eliminar una réplica antigua, admitir una nueva, esperar a que esté disponible y continuar. Los Pods en terminación pueden seguir contabilizándose brevemente en la cuota, por lo que un evento FailedCreate adicional temporal puede resolverse de forma natural; no es un motivo para cambiar la cuota. El presupuesto de despliegue no es un límite absoluto de todos los procesos en terminación ni una garantía de funcionamiento ininterrumpido.

Si una edición incorrecta impide la finalización, inspecciona el archivo guardado y corrige los dos valores de estrategia. Para recuperarte de un intento fallido o un fallo de la ventana de observación, vuelve a aplicar el estado de referencia original aprobado y espera antes de reintentar tu versión corregida:

kubectl --context=labex-v135 apply -f approved/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

La opción --wait-baseline de la herramienta de estado proporcionada espera a una observación reciente y saludable del catálogo antiguo antes de un nuevo intento. Solo lee hechos registrados:

./tools/update-status --wait-baseline

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Estos comandos de recuperación solo se necesitan para un intento fallido. Mantén sin cambios el estado de referencia proporcionado. El observador de solo lectura conserva los intentos y distingue un nuevo intento completo desde el estado de referencia hasta la actualización; la recuperación no borra las evidencias anteriores.

Por último, vuelve a leer la carga de trabajo y la cuota reales:

kubectl --context=labex-v135 -n shop-quota get deployments

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Ambos Deployments deben estar disponibles: tienda 3/3 y referencia 1/1. Una vez que los Pods antiguos terminan, el uso contabilizado de cuota vuelve a 140m con el mismo valor máximo. El siguiente paso comprueba el catálogo que las personas reciben realmente.

Entrega el catálogo actualizado

En este paso, inspeccionarás la nueva experiencia del cliente y conservarás una descarga real del catálogo junto al manifiesto de versión guardado.

Empieza en Workspace, en /home/labex/project/shop-update. El comando proporcionado tools/update-status resume muestras reales de API y HTTP registradas por un observador de solo lectura. El ./ inicial ejecuta un programa relativo al directorio actual:

./tools/update-status

Informa del mínimo requerido, el número de muestras, el mínimo de réplicas disponibles muestreadas y el último estado de actualización. Espera un mínimo de al menos dos y tres réplicas actualizadas y disponibles al finalizar. El observador toma muestras aproximadamente cada medio segundo más el tiempo de la API, comprueba la cuota y la referencia originales y registra fallos. Deja en ejecución este observador proporcionado. No demuestra lo ocurrido entre muestras, no garantiza un funcionamiento ininterrumpido en producción ni repara el clúster. Una comprobación inmediatamente posterior a la finalización del despliegue puede necesitar una breve espera hasta tener dos muestras de la actualización completada. Si un intento incumplió el mínimo requerido o tuvo una interrupción larga de observación, usa la recuperación al estado de referencia enseñada en el paso anterior antes de un intento corregido.

Cambia a Shop y recarga la página. Espera ver The winter edit, cuatro productos, Stoneware tray $20.00, Linen cloth $14.00, Bud vase $24.00 y Amber cup $16.00. Abre Amber cup y confirma su precio y el estado Available in store; después vuelve con Back to collection. Es un catálogo, sin compra en línea.

La colección completada tiene cuatro tarjetas de productos reales. Compara el encabezado de la colección y los precios con este ejemplo en ejecución:

Usa Download catalogue. Abre el catalogue.csv descargado por el navegador; sus cuatro filas deben coincidir con la colección, los nombres, los precios en céntimos y la disponibilidad mostrados en el sitio. La descarga del navegador y el espacio de trabajo del terminal son ubicaciones diferentes. A continuación guarda la misma descarga real del Service en el espacio de trabajo para la entrega.

Vuelve a Workspace. curl obtiene una URL. --fail informa de errores HTTP, --silent --show-error oculta el indicador de progreso y conserva los errores, y --output escribe los bytes de la respuesta en el archivo indicado. 127.0.0.1:8081 es la entrada local preparada que reenvía al Service original de la tienda:

curl --fail --silent --show-error http://127.0.0.1:8081/catalogue.csv --output catalogue.csv

cat catalogue.csv

Resultado esperado:

id,name,price_cents,available,collection
stone-tray,Stoneware tray,2000,true,The winter edit
linen-cloth,Linen cloth,1400,true,The winter edit
bud-vase,Bud vase,2400,true,The winter edit
amber-cup,Amber cup,1600,true,The winter edit

Un error de conexión significa que no se pudo acceder a la entrada local; un error HTTP es una respuesta de un servidor. Vuelve a los comandos enseñados de carga de trabajo y despliegue para inspeccionar el estado actual; no sustituyas el resultado por un archivo estático ni cambies el servicio de reenvío preparado. Si una descarga está incompleta o se sobrescribe por accidente, repite el mismo comando curl después de que esté disponible el catálogo correcto.

Abre Reference de nuevo y recarga. Fern Stationery debe seguir mostrando Desk essentials, Field notebook $9.00 y Clay pencil cup $14.00. Abre un producto y vuelve para confirmar que sus enlaces reales siguen funcionando.

Tu entrega es release/shop.yaml junto con el catalogue.csv real, respaldados por la nueva versión completa, la cuota sin cambios, el servicio de referencia original y un intento válido de actualización observado. Conserva los originales proporcionados, la aplicación, los Services y el observador de solo lectura.

Resumen

Relacionaste un rechazo real de cuota de un ReplicaSet con las necesidades temporales de recursos de una actualización progresiva, calculaste un presupuesto adecuado de réplicas adicionales y no disponibles, y completaste el nuevo catálogo sin ampliar la asignación. También conservaste el servicio de referencia protegido y entregaste un CSV real junto con un manifiesto de versión reutilizable.

Las solicitudes de CPU describen la contabilización de recursos, no el uso medido ni una promesa de rendimiento. Las observaciones nativas finitas respaldan la comprobación de disponibilidad de este curso; no demuestran un funcionamiento ininterrumpido en producción. En otro espacio de nombres, vuelve a calcular tanto la asignación libre como el mínimo de réplicas disponibles antes de elegir la estrategia.