GSP768

Descripción general

Google Kubernetes Engine tiene soluciones horizontales y verticales para ajustar automáticamente la escala de tus Pods y tu infraestructura. Cuando se trata de optimizar costos, estas herramientas se vuelven muy útiles para garantizar que tus cargas de trabajo se ejecuten de la manera más eficiente posible y que solo pagues por lo que usas.

En este lab, configurarás y observarás el Ajuste automático de escala horizontal de Pods y el Ajuste de escala automático vertical de Pods para el escalamiento a nivel del Pod, y el Escalador automático de clúster (solución de infraestructura horizontal) y el Aprovisionamiento automático de nodos (solución de infraestructura vertical) para el escalamiento a nivel de nodo. Primero, usarás estas herramientas de ajuste de escala automático para ahorrar tantos recursos como sea posible y reducir el tamaño de tu clúster durante un período de baja demanda. Luego, aumentarás las demandas de tu clúster y observarás cómo el ajuste de escala automático mantiene la disponibilidad.

Objetivos

En este lab, aprenderás a hacer lo siguiente:

• Reducir la cantidad de réplicas para un Deployment con el Horizontal Pod Autoscaler
• Reducir la solicitud de CPU de un Deployment con el Vertical Pod Autoscaler
• Reducir la cantidad de nodos que se usan en el clúster con el escalador automático de clúster
• Crear automáticamente un grupo de nodos optimizado para la carga de trabajo con el aprovisionamiento automático de nodos
• Probar el comportamiento del ajuste de escala automático frente a un aumento repentino de la demanda
• Aprovisionar en exceso tu clúster con Pods de pausa

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón Abrir la consola de Google Cloud
   • El tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia Cuenta de Google podría generar cargos adicionales.

7. Haga clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para ver un menú con una lista de productos y servicios de Google Cloud, haz clic en el menú de navegación que se encuentra en la parte superior izquierda.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. El resultado contiene una línea que declara el PROJECT_ID para esta sesión:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

Aprovisiona el entorno de pruebas

1. Establece la zona predeterminada como :

gcloud config set compute/zone {{{project_0.default_zone | zone}}}

2. Ejecuta el siguiente comando para crear un clúster de tres nodos en la zona :

gcloud container clusters create scaling-demo --num-nodes=3 --enable-vertical-pod-autoscaling

Con el objetivo de demostrar el ajuste automático de escala horizontal de Pods, este lab usa una imagen de Docker personalizada basada en la imagen php-apache. Esta define una página index.php que realiza algunos cálculos de uso intensivo de CPU. Supervisarás un Deployment de esta imagen.

3. Crea un manifiesto para el Deployment php-apache:

cat << EOF > php-apache.yaml apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 3 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache EOF

4. Aplica el manifiesto recién creado a tu clúster:

kubectl apply -f php-apache.yaml

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Aprovisionar el entorno de pruebas

Tarea 1. Escala Pods con el ajuste automático de escala horizontal de Pods

El ajuste automático de escala horizontal de Pods cambia la forma de tu carga de trabajo de Kubernetes aumentando o disminuyendo automáticamente la cantidad de Pods en función del consumo de memoria o CPU de la carga de trabajo, o en función de las métricas personalizadas que se establecen desde Kubernetes o las métricas externas de fuentes fuera del clúster.

1. En Cloud Shell, ejecuta este comando para inspeccionar los Deployments de tu clúster:

kubectl get deployment

Deberías ver el Deployment php-apache con 3/3 Pods en ejecución:

NAME READY UP-TO-DATE AVAILABLE AGE php-apache 3/3 3 3 91s Nota: Si no ves 3 Pods disponibles, espera un minuto hasta que se creen y vuelve a intentar ejecutar el comando anterior. Si ves 1/1 Pods disponibles, es probable que ya haya pasado el tiempo suficiente para que tu Deployment reduzca la escala verticalmente.

2. Aplica el ajuste de escala automático horizontal al Deployment php-apache:

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Escalar Pods con el ajuste automático de escala horizontal de Pods

El comando autoscale configurará un Horizontal Pod Autoscaler que mantendrá entre 1 y 10 réplicas de los Pods controlados por el Deployment php-apache. La marca cpu-percent especifica un uso promedio objetivo de CPU del 50% de la CPU solicitada en todos los Pods. El HPA ajustará la cantidad de réplicas (a través del Deployment) para mantener un uso de CPU promedio del 50% en todos los Pods.

3. Verifica el estado actual de tu Horizontal Pod Autoscaler:

kubectl get hpa

En la columna Targets, deberías ver 1%/50%.

Esto significa que, por el momento, las CPUs de los Pods de tu implementación se encuentran al 1% de su capacidad promedio objetivo. Esto era de esperarse, ya que la aplicación php-apache no recibe tráfico en este momento.

Nota: Si ves <unknown>/50%, espera un minuto y vuelve a ejecutar el comando kubectl get hpa. Tu HPA aún no creó una evaluación.

Además, toma nota de la columna Replicas. Para comenzar, el valor será 3. El escalador automático cambiará este número a medida que cambie la cantidad de Pods necesarios.

En este caso, el escalador automático reducirá verticalmente la escala del Deployment a la cantidad mínima de Pods que se indica cuando ejecutas el comando autoscale. El ajuste automático de escala horizontal de Pods tarda entre 5 y 10 minutos, y necesitará cerrar o iniciar Pods nuevos en función del modo en que realice el escalamiento.

Continúa con el siguiente paso del lab. Inspeccionarás los resultados del escalador automático más adelante.

Nota: Cuando usas cpu-percent como la métrica objetivo para tu escalador automático en este lab, HPA permite que se definan métricas personalizadas de manera que puedas escalar los Pods según otras métricas útiles capturadas en los registros.

Tarea 2: Ajusta el tamaño de los Pods con el Ajuste de escala automático vertical de Pods

El Ajuste de escala automático vertical de Pods te libera de tener que pensar qué valores especificar para las solicitudes de CPU y de memoria de un contenedor. El escalador automático te puede recomendar valores de solicitudes y límites de CPU y memoria o puede actualizar automáticamente los valores.

Nota: El Ajuste de escala automático vertical de Pods no debe usarse junto con el Ajuste automático de escala horizontal de Pods en la CPU o la memoria. Ambos escaladores automáticos intentarán responder a los cambios en la demanda en las mismas métricas y conflictos. Sin embargo, el VPA en la CPU o la memoria puede usarse en métricas personalizadas con el HPA para evitar la superposición.

El Ajuste de escala automático vertical de Pods ya se habilitó en el clúster scaling-demo.

1. Para verificarlo, ejecuta el siguiente comando:

gcloud container clusters describe scaling-demo | grep ^verticalPodAutoscaling -A 1

El resultado debería ser enabled: true.

Nota: El Ajuste de escala automático vertical de Pods puede habilitarse en un clúster existente con gcloud container clusters update scaling-demo --enable-vertical-pod-autoscaling

Para demostrar el VPA, implementarás la aplicación hello-server.

2. Aplica el Deployment hello-server a tu clúster:

kubectl create deployment hello-server --image=gcr.io/google-samples/hello-app:1.0

3. Asegúrate de que el Deployment se haya creado correctamente:

kubectl get deployment hello-server

4. Asigna al Deployment una solicitud de recursos de CPU de 450m:

kubectl set resources deployment hello-server --requests=cpu=450m

5. A continuación, ejecuta este comando para inspeccionar los detalles específicos del contenedor de los Pods de hello-server:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

• En el resultado, busca Requests. Ten en cuenta que este Pod solicita actualmente la CPU de 450m que asignaste.

6. Ahora crea un manifiesto para tu Vertical Pod Autoscaler:

cat << EOF > hello-vpa.yaml apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: hello-server-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: hello-server updatePolicy: updateMode: "Off" EOF

Lo anterior genera un manifiesto para un Vertical Pod Autoscaler orientado al Deployment hello-server con una política de actualización Off. Un VPA puede tener una de las tres políticas de actualización que pueden resultar útiles según tu aplicación:

• Off: Esta política significa que el VPA generará recomendaciones basadas en datos históricos que puedes aplicar manualmente.
• Initial: Las recomendaciones del VPA se usarán para crear Pods nuevos una vez y, luego, no cambiarán el tamaño del Pod.
• Auto: Los Pods se borran y se vuelven a crear con regularidad para coincidir con el tamaño de las recomendaciones.

7. Aplica el manifiesto para hello-vpa:

kubectl apply -f hello-vpa.yaml

8. Espera un minuto y, luego, visualiza el VerticalPodAutoscaler:

kubectl describe vpa hello-server-vpa

Busca “Container Recommendations” al final del resultado. Si no aparece, espera un poco más y vuelve a ejecutar el comando anterior. Cuando aparezca, verás varios tipos de recomendaciones diferentes, cada uno con valores para CPU y memoria:

• Lower Bound: Este es el número límite inferior que el VPA toma como referencia para activar un cambio de tamaño. Si el uso de tu Pod se encuentra por debajo de este límite, el VPA borrará el Pod y reducirá su escala verticalmente.
• Target: Este es el valor que el VPA usará cuando cambie el tamaño del Pod.
• Uncapped Target: Si no se asigna una capacidad mínima o máxima al VPA, esta será el uso objetivo del VPA.
• Upper Bound: Este es el número límite superior que el VPA toma como referencia para activar un cambio de tamaño. Si el uso de tu Pod se encuentra por encima de este límite, el VPA borrará el Pod y lo escalará verticalmente.

Notarás que el VPA recomienda que la solicitud de CPU de este contenedor esté configurada en 25m en lugar de 100m como antes y también te proporciona una sugerencia de cuánta memoria debería solicitarse. En este punto, estas recomendaciones se pueden aplicar de forma manual al Deployment hello-server.

Nota: El Ajuste de escala automático vertical de Pods basa sus recomendaciones en datos históricos del contenedor. En la práctica, se recomienda esperar al menos 24 horas para recopilar datos de recomendaciones antes de aplicar cambios.

9. Para observar el VPA y sus efectos en este lab, cambiarás la política de actualización de hello-vpa a Auto y observarás el escalamiento.

10. Actualiza el manifiesto para establecer la política en Auto y aplica la configuración:

sed -i 's/Off/Auto/g' hello-vpa.yaml kubectl apply -f hello-vpa.yaml

Para cambiar el tamaño de un Pod, el Vertical Pod Autoscaler deberá borrar ese Pod y volver a crearlo con el tamaño nuevo. De forma predeterminada, para evitar el tiempo de inactividad, el VPA no borrará el último Pod activo ni cambiará su tamaño. Debido a esto, necesitarás al menos 2 réplicas para ver los cambios en el VPA.

11. Escala el Deployment hello-server a 2 réplicas:

kubectl scale deployment hello-server --replicas=2

12. Ahora observa tus Pods:

kubectl get pods -w

13. Espera hasta que veas tus Pods hello-server-xxx en el estado terminating o en pending (o dirígete a Kubernetes Engine > Cargas de trabajo):

Esto indica que tu VPA está borrando tus Pods y cambiando su tamaño. Cuando observes esto, presiona Ctrl + C para salir del comando.

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Ajustar el tamaño de los Pods con el Ajuste de escala automático vertical de Pods

Tarea 3. Resultados del HPA

En este punto, es probable que el Horizontal Pod Autoscaler haya reducido verticalmente la escala de tu Deployment php-apache.

1. Ejecuta este comando para verificar tu HPA:

kubectl get hpa

• Consulta la columna Replicas. Verás que tu Deployment php-apache redujo la escala verticalmente a 1 Pod.

Nota: Si aún ves 3 réplicas para tu implementación php-apache, debes esperar algunos minutos más hasta que el escalador automático realice la acción.

• El HPA aprovecha el hecho de que la aplicación está inactiva en este momento y quita todos los recursos que no se usan. Además, si aumentara la demanda en la aplicación php-apache, volvería a escalar verticalmente para responder ante la carga.

Nota: Si la disponibilidad de tu aplicación es una de las preocupaciones principales, una práctica recomendada es dejar un búfer un poco más alto como la cantidad mínima de Pods para que tu Horizontal Pod Autoscaler tenga en cuenta el tiempo que le lleva escalar.

Esto es muy útil cuando se considera la optimización de costos. Un escalador automático bien ajustado implica mantener la alta disponibilidad de la aplicación mientras que pagas únicamente por los recursos necesarios para mantener esa disponibilidad, independientemente de la demanda.

Tarea 4. Resultados del VPA

Ahora el VPA debería haber cambiado el tamaño de tus Pods en el Deployment hello-server.

1. Inspecciona tus Pods:

kubectl describe pod hello-server | sed -n "/Containers:$/,/Conditions:/p"

2. Busca el campo Requests:.

• El Vertical Pod Autoscaler volvió a crear los Pods con los usos objetivo. Ahora debería solicitar una menor cantidad de CPU y una determinada cantidad de memoria:

Solicitudes: CPU: 25m memoria: 262144k Nota: Si aún ves una solicitud de CPU de 450m para cualquiera de los Pods, ejecuta el siguiente comando para configurar tu recurso de CPU con el objetivo: kubectl set resources deployment hello-server --requests=cpu=25m Hay ocasiones en las que el VPA en modo automático demora mucho tiempo o establece valores de límite inferiores o superiores por no tener el tiempo necesario para recopilar datos precisos. Para no perder tiempo en el lab, una solución fácil es usar la recomendación como si estuviera en modo “Off”.

En este caso, el VPA se convierte en una excelente herramienta para optimizar el uso de recursos y, en efecto, ahorrar costos. La solicitud original de 400m de CPU era mayor que la que necesitaba este contenedor. Si ajustas la solicitud al valor recomendado de 25m, podrás usar menos CPU del grupo de nodos, lo que podría implicar que se necesiten menos nodos en el clúster.

Con la política de actualización en Auto, tu VPA seguirá borrando los Pods del Deployment hello-server y cambiando su tamaño durante toda su vida útil. Puedes escalar verticalmente los Pods con solicitudes más grandes para manejar mucho tráfico y, luego, reducir la escala de forma vertical durante un tiempo de inactividad. Esto puede ser muy útil para los aumentos constantes en la demanda de tu aplicación, pero corres el riesgo de perder la disponibilidad durante grandes aumentos repentinos.

Según tu aplicación, suele ser más seguro usar el VPA con la política de actualización en Off y aplicar las recomendaciones según sea necesario para optimizar el uso de los recursos y maximizar la disponibilidad de tu clúster.

En las próximas secciones, analizarás cómo optimizar aún más el uso de los recursos con el escalador automático de clúster y el aprovisionamiento automático de nodos.

Tarea 5: Escalador automático de clúster

El escalador automático de clúster está diseñado para agregar o quitar nodos en función de la demanda. Cuando la demanda es alta, el escalador automático de clúster agregará nodos al grupo de nodos para satisfacer esa demanda. Cuando la demanda es baja, el escalador automático de clúster reduce verticalmente la escala de tu clúster mediante la eliminación de nodos. Esto te permite mantener una alta disponibilidad de tu clúster, al mismo tiempo que minimiza los costos excesivos asociados a máquinas adicionales.

1. Habilita el ajuste de escala automático para tu clúster:

gcloud beta container clusters update scaling-demo --enable-autoscaling --min-nodes 1 --max-nodes 5

Este proceso tardará unos minutos en completarse.

Cuando escalas un clúster, la decisión de cuándo quitar un nodo representa el equilibrio entre la optimización para el uso o la disponibilidad de los recursos. Quitar los nodos poco usados mejora el uso del clúster, pero es posible que las cargas de trabajo nuevas tengan que esperar que los recursos se aprovisionen nuevamente antes de poder ejecutarse.

Puedes especificar qué perfil de ajuste de escala automático usar cuando tomes esas decisiones. Los perfiles disponibles en este momento son los siguientes:

• Balanced: Es el perfil predeterminado.
• Optimize-utilization: Prioriza la optimización para el uso en lugar de mantener los recursos libres en el clúster. Cuando se selecciona, el escalador automático de clúster reduce verticalmente la escala del clúster de manera más contundente. Puede quitar más nodos y hacerlo más rápido. Este perfil se optimizó para usarse con cargas de trabajo por lotes que no son sensibles a la latencia de inicio.

2. Cambia al perfil de ajuste de escala automático optimize-utilization para que se puedan observar los efectos completos del escalamiento:

gcloud beta container clusters update scaling-demo \ --autoscaling-profile optimize-utilization

3. Cuando se habilite el ajuste de escala automático, observa tu clúster en la consola de Cloud. Haz clic en las tres barras ubicadas en la parte superior izquierda para abrir el Menú de navegación.

4. En Menú de navegación, selecciona Kubernetes Engine > Clústeres.

5. En la página Clústeres, selecciona el clúster scaling-demo.

6. En la página del clúster scaling-demo, selecciona la pestaña Nodos (Nodes).

7. Mira la descripción general del uso de recursos de tus tres nodos.

Nota: Es posible que tus números no sean los mismos que se muestran. Kubernetes no aprovisiona ni asigna recursos de la misma manera en cada ocasión.

Si combinas los valores de CPU solicitada y CPU asignable para los 3 nodos, los totales serían 1555m y 2820m, respectivamente. Esto significa que hay un total de 1265m de CPU disponibles en todo el clúster. Esto es más grande de lo que puede proporcionar un nodo.

Para optimizar el uso, la carga de trabajo actual a la demanda actual se podría consolidar en dos nodos en lugar de tres. Sin embargo, tu clúster aún no redujo su escala verticalmente de forma automática. Esto se debe a los Pods del sistema, distribuidos a través de todo el clúster.

Tu clúster ejecuta varios Deployments en el espacio de nombres de kube-system que permiten que funcionen los diferentes servicios de GKE, como el registro, la supervisión, el ajuste de escala automático, etc.

8. Esto se puede verificar con la ejecución del siguiente comando en Cloud Shell:

kubectl get deployment -n kube-system

De forma predeterminada, la mayoría de los Pods del sistema de estos Deployments evitan que el escalador automático del clúster los deje completamente sin conexión para reprogramarlos. En general, esto se debe a que muchos de estos Pods recopilan datos usados en otros Deployments y Services. Por ejemplo, si metrics-agent dejara de funcionar temporalmente, provocaría una interrupción en los datos recopilados para el VPA y el HPA, o si pasara lo mismo con el Pod fluentd, se podría crear una interrupción en sus registros en la nube.

A los fines de este lab, aplicarás Presupuestos de interrupción de Pods a tus Pods de kube-system, lo que permitirá que el escalador automático del clúster los reprograme de forma segura en otro nodo. Esto te dará suficiente espacio para reducir verticalmente la escala de tu clúster.

Los Presupuestos de interrupción de Pods (PDB) definen la forma en que Kubernetes debe manejar las interrupciones, como las actualizaciones, las eliminaciones de Pods, la falta de recursos, etc. En los PDB, puedes especificar la cantidad max-unavailable o min-available de Pods que debería tener un Deployment.

9. Ejecuta estos comandos para crear los Presupuestos de interrupción de Pods en cada uno de tus Pods de kube-system:

kubectl create poddisruptionbudget kube-dns-pdb --namespace=kube-system --selector k8s-app=kube-dns --max-unavailable 1 kubectl create poddisruptionbudget prometheus-pdb --namespace=kube-system --selector k8s-app=prometheus-to-sd --max-unavailable 1 kubectl create poddisruptionbudget kube-proxy-pdb --namespace=kube-system --selector component=kube-proxy --max-unavailable 1 kubectl create poddisruptionbudget metrics-agent-pdb --namespace=kube-system --selector k8s-app=gke-metrics-agent --max-unavailable 1 kubectl create poddisruptionbudget metrics-server-pdb --namespace=kube-system --selector k8s-app=metrics-server --max-unavailable 1 kubectl create poddisruptionbudget fluentd-pdb --namespace=kube-system --selector k8s-app=fluentd-gke --max-unavailable 1 kubectl create poddisruptionbudget backend-pdb --namespace=kube-system --selector k8s-app=glbc --max-unavailable 1 kubectl create poddisruptionbudget kube-dns-autoscaler-pdb --namespace=kube-system --selector k8s-app=kube-dns-autoscaler --max-unavailable 1 kubectl create poddisruptionbudget stackdriver-pdb --namespace=kube-system --selector app=stackdriver-metadata-agent --max-unavailable 1 kubectl create poddisruptionbudget event-pdb --namespace=kube-system --selector k8s-app=event-exporter --max-unavailable 1

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Escalador automático de clúster

En cada uno de estos comandos, selecciona un Pod de implementación de kube-system distinto según una etiqueta definida en su creación, la cual especifica que puede haber 1 Pod no disponible para cada una de estas implementaciones. Esto permitirá que el escalador automático reprograme los Pods del sistema.

Con los PDB establecidos, tu clúster debería reducir su escala verticalmente de tres nodos a dos en un minuto o dos.

10. Vuelve a ejecutar este comando en Cloud Shell hasta que veas solo dos nodos en total:

kubectl get nodes

En la consola de Cloud, actualiza la pestaña Nodos de tu scaling-demo para inspeccionar cómo se empaquetaron los recursos:

Configuraste la automatización que redujo verticalmente la escala de tu clúster de tres a dos nodos.

Si tienes en cuenta los costos, debido a que redujiste verticalmente la escala de tu grupo de nodos, se te facturará por menos máquinas durante períodos de baja demanda en tu clúster. Este escalamiento podría ser aún más marcado si fluctuara entre períodos de alta demanda y baja demanda durante el día.

Es importante tener en cuenta que, si bien el escalador automático del clúster quitó un nodo innecesario, el Ajuste de escala automático vertical de Pods y el Ajuste automático de escala horizontal de Pods ayudaron a reducir la demanda de CPU lo suficiente como para que el nodo ya no fuera necesario. Combinar estas herramientas es una excelente manera de optimizar los costos generales y el uso de recursos.

Por lo tanto, el escalador automático del clúster ayuda a agregar y quitar nodos en respuesta a los Pods que necesitan programarse. Sin embargo, GKE tiene otra función específicamente para escalar de forma vertical; se denomina aprovisionamiento automático de nodos.

Tarea 6. Aprovisionamiento automático de nodos

El aprovisionamiento automático de nodos (NAP) agrega nuevos grupos de nodos que tienen el tamaño para satisfacer la demanda. Sin el aprovisionamiento automático de nodos, el escalador automático del clúster solo creará nodos nuevos en los grupos de nodos que hayas especificado, lo que significa que los nodos nuevos serán el mismo tipo de máquina que los otros nodos en ese grupo. Esto es ideal para optimizar el uso de recursos en cargas de trabajo por lotes y otras aplicaciones que no necesitan escalamiento extremo, ya que crear un grupo de nodos que esté optimizado de forma específica para tu caso de uso podría llevar más tiempo que solo agregar más nodos a un grupo de nodos existente.

• Habilita el aprovisionamiento automático de nodos:

gcloud container clusters update scaling-demo \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 2 \ --max-cpu 45 \ --max-memory 160

En el comando, especificas un número mínimo y máximo para los recursos de CPU y memoria. Esto se aplica a todo el clúster.

El NAP puede demorar un poco y es muy probable que no cree un grupo de nodos nuevo para el clúster scaling-demo en su estado actual.

En las siguientes secciones, aumentarás la demanda en tu clúster y observarás las acciones de sus escaladores automáticos y el NAP.

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Aprovisionamiento automático de nodos

Tarea 7. Realiza pruebas con una demanda mayor

Hasta ahora, analizaste cómo el HPA, el VPA y el escalador automático del clúster pueden ayudarte a ahorrar recursos y costos mientras tu aplicación tiene una demanda baja. Ahora verás cómo estas herramientas administran la disponibilidad ante una mayor demanda.

1. Abre una pestaña nueva en Cloud Shell. Para ello, haz clic en el ícono +:

2. En la pestaña nueva, ejecuta este comando para enviar un bucle infinito de consultas al servicio php-apache:

kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

3. Regresa a la pestaña original de Cloud Shell.

4. En un plazo aproximado de un minuto, deberías ver una mayor carga de CPU en tu HPA mediante la ejecución del siguiente comando:

kubectl get hpa

Espera y vuelve a ejecutar el comando hasta que veas tu objetivo por encima del 100%.

5. Ahora supervisa cómo tu clúster administra la mayor carga. Para ello, ejecuta periódicamente el siguiente comando:

kubectl get deployment php-apache

También puedes supervisar tu clúster si actualizas la pestaña Nodos en la pestaña de la consola de Cloud.

Después de unos minutos, verás que ocurren algunos eventos.

• Primero, el HPA escalará verticalmente de forma automática su Deployment php-apache para controlar el aumento de la carga.
• Luego, el escalador automático del clúster deberá aprovisionar nodos nuevos para controlar la mayor demanda.
• Por último, el aprovisionamiento automático de nodos creará un grupo de nodos optimizado para las solicitudes de CPU y memoria de las cargas de trabajo de tu clúster. En este caso, debería ser un grupo de nodos con CPU elevada y memoria reducida porque la prueba de carga traspasa los límites de la CPU.

Espera hasta que tu Deployment php-apache escale verticalmente hasta 7 réplicas y la pestaña de nodos se vea similar a la siguiente:

6. Regresa a la pestaña de Cloud Shell en la que ejecutaste la prueba de carga y presiona Ctrl + C para cancelarla. Ahora tu clúster volverá a reducir la escala verticalmente a medida que disminuya la demanda.

Tu clúster escaló verticalmente de forma eficiente para satisfacer una demanda mayor. Sin embargo, ten en cuenta la cantidad de tiempo que le tomó para manejar este aumento repentino de demanda. Para muchas aplicaciones, perder la disponibilidad mientras se aprovisionan recursos nuevos puede ser un problema.

Tarea 8. Optimiza las cargas más grandes

Cuando se escala verticalmente debido a cargas más grandes, el ajuste automático de escala horizontal de Pods agrega nuevos Pods mientras que el ajuste automático de escala vertical de Pods cambiará su tamaño en función de la configuración hayas establecido. Si hay espacio en un nodo existente, podría omitir la extracción de la imagen y comenzar a ejecutar inmediatamente la aplicación en un Pod nuevo. Si trabajas con un nodo que no implementó tu aplicación anteriormente, es posible que demore un poco más si necesita descargar las imágenes del contenedor antes de ejecutarla.

Por lo tanto, si no tienes suficiente espacio en tus nodos existentes y usas el escalador automático del clúster, podría tardar aún más. Ahora deberá aprovisionar un nodo nuevo, configurarlo y, luego, descargar la imagen e iniciar los Pods. Si el aprovisionador automático de nodos crea un grupo de nodos nuevo como lo hizo en tu clúster, tendrás aún más tiempo para aprovisionar el nuevo grupo de nodos primero y, luego, seguir los mismos pasos para el nodo nuevo.

Nota: En la práctica, es importante asegurarse de que tu aplicación use las imágenes de contenedor más pequeñas que pueda. Las imágenes más pequeñas mejoran el tiempo de inicio en frío de un Pod, ya que cuanto más pequeña sea la imagen, más rápido podrá descargarla el nodo cuando el escalador automático del clúster aprovisione un nodo nuevo para tu clúster. Además, las imágenes más grandes pueden provocar tiempos de inicio de Pods más largos, lo que produce un rendimiento deficiente al aprovisionar nodos nuevos durante el aumento repentino de tráfico.

A la hora de manejar estas diferentes latencias para el ajuste de escala automático, es probable que quieras aprovisionar en exceso un poco, de modo que haya menos presión en sus aplicaciones cuando se realice el ajuste de escala automático vertical. Esto es muy importante para la optimización de costos, ya que no es conveniente pagar por más recursos de los que necesitas, pero tampoco es recomendable que el rendimiento de tus aplicaciones se vea comprometido.

Para decidir cuánto debes aprovisionar en exceso, puedes usar esta fórmula:

Como ejemplo, piensa en el uso de CPU para tu clúster. No es conveniente que alcance el 100%, por lo que puedes elegir un búfer del 15% para mantener una distancia segura. En ese caso, la variable de tráfico de la fórmula sería el porcentaje de aumento de tráfico estimado en los próximos 2 a 3 minutos. En la prueba de carga que ejecutaste antes, del 0% al 150% era un ejemplo de aumento extremo; por lo tanto, en su lugar, imagina un aumento del tráfico promedio del 30%.

Con estos números, puedes calcular un búfer de seguridad de aproximadamente el 65%. Esto significa que es probable que debas aprovisionar en exceso tus recursos en aproximadamente un 65% para poder manejar los aumentos verticales de escala y, al mismo tiempo, minimizar los problemas.

Una estrategia eficiente para aprovisionar en exceso un clúster con el ajuste de escala automático del clúster es usar Pods de pausa.

Los Pods de pausa son implementaciones de prioridad baja que se pueden quitar y reemplazar por implementaciones de prioridad alta. Esto significa que puedes crear Pods de prioridad baja que en realidad no hagan nada, excepto reservar espacio de búfer. Cuando el Pod de prioridad más alta necesite espacio, los Pods de pausa se quitarán y se reprogramarán en otro nodo, o en un nodo nuevo, y el Pod de prioridad más alta tendrá el espacio que necesita para programarse rápidamente.

1. Crea un manifiesto para un Pod de pausa:

cat << EOF > pause-pod.yaml --- apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: overprovisioning value: -1 globalDefault: false description: "Priority class used by overprovisioning." --- apiVersion: apps/v1 kind: Deployment metadata: name: overprovisioning namespace: kube-system spec: replicas: 1 selector: matchLabels: run: overprovisioning template: metadata: labels: run: overprovisioning spec: priorityClassName: overprovisioning containers: - name: reserve-resources image: k8s.gcr.io/pause resources: requests: cpu: 1 memory: 4Gi EOF

2. Aplícalo a tu clúster:

kubectl apply -f pause-pod.yaml

3. Ahora espera un minuto y, luego, actualiza la pestaña Nodos de tu clúster scaling-demo.

Observa cómo se crea un nodo nuevo (lo más probable es que sea en un grupo de nodos nuevo) para adaptarse a tu Pod de pausa recién creado. Ahora, si volvieras a ejecutar la prueba de carga, cuando necesites un nodo adicional para tu Deployment php-apache, podría programarse en el nodo con tu Pod de pausa mientras el Pod de pausa se coloca en un nodo nuevo. Esto es excelente, ya que tus Pods de pausa ficticios le permiten a tu clúster aprovisionar un nodo nuevo por adelantado para que tu aplicación real pueda escalar verticalmente mucho más rápido. Si esperaras una cantidad de tráfico más grande, puedes agregar más Pods de pausa, pero es una práctica recomendada no agregar más de un Pod de pausa por nodo.

Haz clic en Revisar mi progreso para verificar la realización de la tarea indicada arriba. Optimizar las cargas más grandes

¡Felicitaciones!

¡Felicitaciones! En este lab, configuraste un clúster para aumentar o reducir la escala verticalmente de forma automática y eficiente según su demanda. El ajuste automático de escala horizontal de Pods y el ajuste de escala automático vertical de Pods proporcionaron soluciones para escalar automáticamente los Deployments del clúster, mientras que el escalador automático del clúster y el aprovisionamiento automático de nodos proporcionaron soluciones para escalar automáticamente la infraestructura de tu clúster.

Como siempre, saber cuáles de estas herramientas usar dependerá de tu carga de trabajo. Usar estos escaladores automáticos con cuidado puede conllevar una mayor disponibilidad cuando lo requieras, mientras que solo pagas por lo que necesitas en momentos de baja demanda. Si piensas en términos de costos, esto significa que optimizas el uso de los recursos y ahorras dinero.

Próximos pasos y más información

Consulta estos recursos para obtener más información sobre los temas abordados en este lab:

• Prácticas recomendadas para ejecutar aplicaciones de Kubernetes con optimización de costos en GKE: Optimiza el ajuste de escala automático de GKE
• Documentación sobre el escalador automático de clúster
• Documentación sobre el Horizontal Pod Autoscaler
• Documentación del Vertical Pod Autoscaler

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 1 de febrero de 2024

Prueba más reciente del lab: 20 de septiembre de 2023

Copyright 2025 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.