Escalabilidad de Aplicaciones en Kubernetes: Mecanismos y Estrategias. Bloque 2. Tema 2.2 del CKA.

En este artículo, vamos a explorar los mecanismos que ofrece Kubernetes para ajustar la cantidad de recursos, tanto a nivel de pods como de nodos.

Escalado Horizontal de Pods (Horizontal Pod Autoscaler - HPA)

Uno de los mecanismos clave en Kubernetes para el escalado de aplicaciones es el Horizontal Pod Autoscaler (HPA). Este componente ajusta automáticamente el número de pods en una aplicación en función del uso de recursos, como CPU o memoria, según las métricas que recoge el clúster. Si la demanda de una aplicación aumenta, el HPA añadirá más réplicas (pods) para asegurar que la aplicación pueda seguir manejando la carga. Por el contrario, si la carga disminuye, el HPA reducirá la cantidad de pods para evitar el uso innecesario de recursos.

Requisitos y consideraciones para el HPA:

Para que el Horizontal Pod Autoscaler (HPA) funcione correctamente y de manera óptima, es necesario tener en cuenta los siguientes aspectos:

Métricas:
- Metrics Server: El Metrics Server es un componente crítico en Kubernetes que recopila datos de uso de recursos como CPU y memoria de los diferentes nodos y pods en el clúster. Estos datos son utilizados por Kubernetes para tomar decisiones automatizadas, como escalar o reducir el número de réplicas de una aplicación. Sin el Metrics Server, Kubernetes no tendría información en tiempo real sobre el uso de recursos y no podría activar el escalado automático a través del Horizontal Pod Autoscaler (HPA).
  Para implementar el HPA, el Metrics Server debe estar instalado y funcionando en el clúster. Proporciona una API que Kubernetes usa para acceder a los datos de las métricas en tiempo real, y esos datos son fundamentales para que Kubernetes decida cuándo agregar o eliminar pods.
- Métricas personalizadas: Aunque Kubernetes puede utilizar las métricas estándar de CPU y memoria proporcionadas por el Metrics Server, también es posible usar métricas personalizadas si necesitas algo más específico para tu aplicación. Por ejemplo, puedes querer escalar tus pods no solo en función del uso de CPU, sino también basándote en otras métricas, como la cantidad de peticiones HTTP que está recibiendo tu aplicación o el tiempo de respuesta.
  Esto se puede lograr utilizando la API de métricas personalizadas , que permite definir métricas específicas para cada aplicación. Es útil en escenarios donde el uso de recursos no es el único indicador de la carga, y necesita un control más granular sobre el escalado automático.
  Ejemplo de métricas personalizadas: Si tienes una aplicación web, puedes usar métricas como el número de usuarios concurrentes o el tamaño de la cola de mensajes para decidir cuándo escalar. Para habilitar las métricas personalizadas, podría utilizar herramientas como Prometheus , que se integra bien con Kubernetes y proporciona una gran flexibilidad para definir y monitorear métricas específicas.
Probes:
- Readiness: Un Readiness Probe es una verificación periódica que Kubernetes realiza para asegurarse de que un pod esté listo para recibir tráfico. Si una aplicación está arrancando o no hay lista para manejar peticiones, el Readiness Probe le indica a Kubernetes que no envíe tráfico a ese pod. Una vez que el pod está preparado, la sonda informa a Kubernetes que puede empezar a enviarle solicitudes.
  Ejemplo: Imagina que tienes una aplicación que tarda 10 segundos en iniciarse y cargarse completamente. Durante este tiempo, no hay lista para recibir tráfico. El Readiness Probe se asegura de que Kubernetes no dirija solicitudes a la aplicación hasta que esté totalmente lista, evitando posibles errores de servicio.
- Startup Probes (Sondeo de arranque): Los Startup Probes son similares, pero su propósito es asegurarse de que una aplicación haya arrancado completamente antes de que Kubernetes comience a hacer otras verificaciones de salud, como los Liveness y Readiness Probes . Son especialmente útiles para aplicaciones que tardan mucho en arrancar y podrían fallar si Kubernetes comienza a hacer pruebas de salud demasiado pronto.
  Ejemplo: Si una base de datos necesita un tiempo largo para inicializarse (cargar datos, crear conexiones, etc.), un Startup Probe puede configurar un tiempo de espera más largo, asegurando que Kubernetes no reinicie el contenedor prematuramente, pensando que ha fallado, cuando en realidad solo está tomando más tiempo para arrancar.

Configuración:
- Escalado mínimo y máximo: Es posible establecer límites en el número de pods para evitar escalados excesivos o insuficientes.
- Tiempo de enfriamiento: Se puede configurar un tiempo de enfriamiento para evitar fluctuaciones frecuentes en el número de pods.
Integración:
- Otros componentes: El HPA puede integrarse con otros componentes de Kubernetes, como los Ingress, para garantizar una distribución uniforme del tráfico entre los pods.

Ejemplo práctico:

Imagina una aplicación web que experimenta picos de tráfico, por ejemplo, durante la emisión de un partido de fútbol relevante. Con el HPA configurado, la aplicación puede escalar automáticamente para manejar la carga adicional durante estos eventos, y luego reducir el número de pods cuando la demanda disminuye, optimizando así el uso de los recursos.

Instalación y Configuración de Metrics Server y Prometheus con Helm para Escalar Aplicaciones usando HPA:
En Kubernetes, el Horizontal Pod Autoscaler (HPA) es fundamental para ajustar automáticamente el número de réplicas de pods en función de las métricas de uso de recursos, como CPU o memoria. Para que el HPA funcione correctamente, necesitamos una solución de monitoreo. Por un lado, el Metrics Server proporciona las métricas estándar para el escalado basado en el uso de CPU y memoria. Por otro lado, Prometheus nos permite recopilar métricas personalizadas que pueden ampliar las capacidades del HPA, escalando las aplicaciones en función de métricas más específicas.
Más información sobre Prometheus. Click aquí.
Más información sobre HELM. Click Aquí.
A continuación, veremos cómo instalar y configurar ambos sistemas con Helm, y cómo usarlos junto con el HPA para escalar nuestras aplicaciones.

Paso 1: Instalación del Metrics Server

El Metrics Server es esencial para que el HPA pueda acceder a métricas básicas de CPU y memoria. Si aún no lo tienes instalado en tu clúster, puedes hacerlo con Helm.

Añadir el repositorio del Metrics Server:

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm repo update

Instalar el Metrics Server:

helm install metrics-server metrics-server/metrics-server

El Metrics Server comenzará a recopilar métricas de los nodos y pods, lo que permitirá que el HPA funcione basándose en el uso de recursos.

Paso 2: Instalación de Prometheus

Para situaciones en las que necesitamos un monitoreo más avanzado o utilizar métricas personalizadas, Prometheus es una opción ideal. Proporciona un sistema de monitoreo más completo y flexible, que se integra perfectamente con Kubernetes.

Añadir el repositorio de Prometheus:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

Instalar Prometheus:

helm install prometheus prometheus-community/prometheus

Una vez instalado, Prometheus comenzará a recopilar métricas detalladas de los nodos, pods y servicios en tu clúster.

Verificación y Acceso a Prometheus

Para verificar que todos los recursos de Prometheus se hayan creado correctamente, usa el siguiente comando:

kubectl get all -l app=prometheus

Si deseas acceder a la interfaz web de Prometheus para explorar las métricas, puedes hacer un port-forward al servicio con:

kubectl port-forward deploy/prometheus-server 9090:9090

Luego, abre tu navegador en http://localhost:9090 para acceder a la interfaz.

Paso 3: Definición de un Deployment para Escalar

Ahora que tenemos las métricas, necesitamos configurar un deployment que sea escalado automáticamente. A continuación, creamos un archivo de manifiesto llamado cka-demo-hpa.yaml, que define un deployment con 2 réplicas y límites de CPU.

yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cka-hpa-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      run: cka-hpa-deployment
  template:
    metadata:
      labels:
        run: cka-hpa-deployment
    spec:
      containers:
      - name: cka-hpa-deployment
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
          limits:
            cpu: 400m

Este manifiesto define un deployment que utilizará dos réplicas y asigna un límite de uso de CPU de 400 milicores para cada pod. Es importante establecer estos límites para que el HPA sepa cuándo debe escalar la aplicación.

Paso 4: Aplicación del Manifiesto

Aplica el manifiesto con el siguiente comando para crear el deployment y su servicio:

kubectl apply -f cka-demo-hpa.yaml

Puedes verificar que el deployment y el servicio se hayan creado correctamente con:

kubectl get all

Paso 5: Configuración del HPA

Para escalar automáticamente el número de réplicas del deployment según el uso de CPU, configuramos el HPA con el siguiente comando:

kubectl autoscale deployment cka-hpa-deployment --cpu-percent=25 --min=2 --max=6

Este comando crea un HPA que ajustará el número de réplicas entre 2 y 6 según el umbral de utilización de CPU, que en este caso es del 25%. Es decir, cuando el uso de CPU supere el 25%, el HPA agregará más pods hasta alcanzar el máximo definido (6).

Paso 6: Probar el Escalado Automático

Una vez configurado el HPA, puedes probar cómo el número de réplicas se ajusta en función de la carga. Para ello, genera carga sobre el servicio con el siguiente comando:

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

Este pod simulará una carga continua sobre el servicio, lo que incrementará el uso de CPU y activará el escalado automático. En otra terminal, puedes monitorear el HPA con:

kubectl get hpa cka-hpa-deployment -w

A medida que la carga aumenta, el HPA incrementará el número de réplicas hasta alcanzar el máximo configurado (6). Cuando la carga disminuya, el HPA reducirá gradualmente el número de réplicas.

Escalado de Clúster (Cluster Autoscaler)

El Cluster Autoscaler es un componente crítico en Kubernetes que ajusta dinámicamente la cantidad de nodos en el clúster, en función de la demanda de recursos. Este ajuste ocurre de manera automática, agregando o eliminando nodos según las necesidades de las cargas de trabajo. La función principal del Cluster Autoscaler es asegurar que el clúster tenga la capacidad adecuada para ejecutar todas las cargas de trabajo, optimizando al mismo tiempo el uso de los recursos disponibles.

¿Cómo funciona el Cluster Autoscaler?

El Cluster Autoscaler evalúa continuamente el uso de recursos en el clúster, centrándose en dos aspectos principales:

Agregar nodos:
- Cuando los pods no pueden ser programados en ningún nodo existente debido a la falta de recursos (por ejemplo, si no hay suficiente CPU o memoria disponible en los nodos existentes), el Cluster Autoscaler añade automáticamente nuevos nodos al clúster para proporcionar capacidad adicional. Esto asegura que los pods puedan ser programados y ejecutados sin restricciones de recursos.
Eliminar nodos:
- Por el contrario, cuando el Cluster Autoscaler detecta que hay nodos en el clúster que no están utilizando de manera eficiente sus recursos (por ejemplo, si no están ejecutando ningún pod), puede eliminar estos nodos de manera segura para reducir el uso innecesario de recursos y los costos asociados. Antes de eliminar un nodo, el Cluster Autoscaler se asegura de que los pods en ejecución en ese nodo se programen en otros nodos disponibles, evitando cualquier interrupción del servicio.

Este comportamiento hace que el Cluster Autoscaler sea ideal para clústeres con cargas de trabajo variables. Por ejemplo, en entornos de desarrollo o producción donde las demandas de recursos fluctúan a lo largo del día, el Cluster Autoscaler garantiza que siempre haya suficientes nodos para manejar la carga en momentos pico y que no se mantengan nodos inactivos cuando la carga disminuye.

Casos de uso del Cluster Autoscaler

Escalado en función de la demanda: En aplicaciones que experimentan picos de tráfico impredecibles (como plataformas de comercio electrónico durante eventos de venta), el Cluster Autoscaler puede añadir nodos automáticamente para satisfacer las necesidades de recursos adicionales.
Optimización de costos en la nube: En entornos de nube, los recursos (nodos) tienen un costo asociado. El Cluster Autoscaler ayuda a reducir los costos operativos al eliminar nodos innecesarios cuando no hay demanda. Esto es particularmente útil en plataformas de pago por uso como Amazon Web Services (AWS), Google Cloud o Azure, donde eliminar nodos inactivos puede ahorrar costos significativos.
Cargas de trabajo elásticas: Para aplicaciones con patrones de uso impredecibles o que pueden tener tareas que requieren mucha capacidad computacional por períodos cortos (como procesamiento de datos o análisis), el Cluster Autoscaler asegura que los recursos adicionales solo se utilicen cuando sea necesario.

Cómo se configura el Cluster Autoscaler

El Cluster Autoscaler se puede implementar fácilmente en un clúster de Kubernetes que se ejecute en una nube pública (como AWS, GCP o Azure) o en un entorno local que soporte escalado dinámico de nodos. A continuación, te explico cómo configurarlo en un clúster en la nube:

Instalación con Helm: Si estás usando un proveedor de nube como Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) o Azure Kubernetes Service (AKS), puedes instalar el Cluster Autoscaler directamente con Helm.
Ejemplo para AWS (EKS):
```
helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update
helm install cluster-autoscaler autoscaler/cluster-autoscaler --namespace kube-system --set autoDiscovery.clusterName=<nombre-del-cluster> --set awsRegion=<región-aws>
```
Este comando instalará el Cluster Autoscaler en tu clúster de AWS y permitirá que descubra automáticamente los nodos que puede añadir o eliminar, basándose en el uso de recursos.

Configuración manual: En entornos donde no puedes utilizar Helm o quieres una configuración personalizada, puedes configurar el Cluster Autoscaler descargando su código fuente y aplicando los manifiestos YAML correspondientes. Un ejemplo básico para configurarlo sería crear un Deployment de Cluster Autoscaler:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cluster-autoscaler
  namespace: kube-system
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: cluster-autoscaler
    spec:
      containers:
      - name: cluster-autoscaler
        image: k8s.gcr.io/autoscaler/cluster-autoscaler:v1.20.0
        command:
        - ./cluster-autoscaler
        - --cloud-provider=aws
        - --nodes=1:10:my-node-group
        - --skip-nodes-with-local-storage=false
        - --expander=least-waste
        env:
        - name: AWS_REGION
          value: <tu-región-aws>

En este ejemplo, el Cluster Autoscaler está configurado para gestionar un grupo de nodos en AWS con un mínimo de 1 nodo y un máximo de 10. La opción --expander=least-waste indica que el Cluster Autoscaler intentará utilizar los nodos de la manera más eficiente posible.

Ejemplo: Implementación del Cluster Autoscaler

El Cluster Autoscaler también está disponible en GitHub como parte del proyecto Kubernetes Autoscaler. Puedes acceder a su código fuente, modificarlo o instalar versiones preconfiguradas desde el repositorio oficial:

Cluster Autoscaler en GitHub

Beneficios del Cluster Autoscaler

Escalabilidad automática: El Cluster Autoscaler garantiza que el clúster siempre tenga suficientes recursos para ejecutar las aplicaciones, añadiendo nodos cuando sea necesario.
Optimización de recursos: Al eliminar nodos inactivos, el Cluster Autoscaler reduce el desperdicio de recursos, lo que puede traducirse en menores costos operativos, especialmente en entornos de nube.
Alta disponibilidad: Mantiene la capacidad operativa de las aplicaciones en todo momento, asegurando que los pods puedan ejecutarse sin interrupciones, incluso en momentos de alta demanda.

Escalado Vertical de Pods (Vertical Pod Autoscaler - VPA)

El Vertical Pod Autoscaler (VPA) es un componente esencial en Kubernetes para ajustar dinámicamente los recursos de CPU y memoria solicitados por los pods. A diferencia del Horizontal Pod Autoscaler (HPA), que ajusta la cantidad de pods en función del uso de recursos, el VPA se enfoca en ajustar los recursos asignados a cada pod individualmente. Esto permite que los pods existentes se adapten a la carga sin necesidad de agregar o eliminar réplicas, lo que puede ser crucial para ciertos tipos de aplicaciones.

¿Cómo funciona el Vertical Pod Autoscaler?

El VPA monitorea continuamente los recursos consumidos por los pods y ajusta las solicitudes de CPU y memoria basándose en datos históricos de uso. La idea es asegurar que cada pod tenga los recursos suficientes para manejar la carga de trabajo actual, pero sin sobreasignar recursos que no se están utilizando de manera efectiva.

El VPA hace tres cosas principales:

Recomendar recursos:
- El VPA analiza el uso histórico de los recursos y recomienda ajustes en los límites y solicitudes de CPU y memoria de los pods. Estas recomendaciones se pueden utilizar para actualizar los manifiestos de Kubernetes manualmente o dejar que el VPA las aplique automáticamente.
Actualizar recursos en tiempo real:
- Cuando el VPA está configurado para hacerlo, puede ajustar automáticamente las solicitudes de recursos de los pods en tiempo real. Si un pod necesita más CPU o memoria debido a un aumento de carga, el VPA actualizará las solicitudes del pod sin necesidad de reiniciarlo, siempre que sea posible.
Optimización del uso de recursos:
- El VPA ayuda a evitar el desperdicio de recursos ajustando los límites de CPU y memoria de los pods. Esto es ideal en aplicaciones donde la carga puede fluctuar considerablemente con el tiempo. En lugar de asignar recursos excesivos de forma estática, el VPA asegura que cada pod utilice la cantidad óptima de recursos según la demanda actual.

Casos de uso del Vertical Pod Autoscaler

El VPA es especialmente útil para aplicaciones que tienen fluctuaciones en la demanda de recursos o aplicaciones que requieren recursos variables según el tipo de tarea que estén ejecutando. Algunos ejemplos de cuándo el VPA es la mejor opción incluyen:

Aplicaciones con carga variable: Para aplicaciones como sistemas de procesamiento de datos o análisis, donde la demanda de recursos puede variar drásticamente de un momento a otro, el VPA garantiza que los pods obtengan los recursos necesarios durante picos de carga sin desperdiciar recursos cuando la demanda es baja.
Entornos de producción con cambios impredecibles: En aplicaciones de producción donde no se pueden prever los patrones de uso (por ejemplo, aplicaciones de inteligencia artificial o aprendizaje automático que procesan datos en tiempo real), el VPA ajusta los recursos dinámicamente para optimizar el rendimiento.
Optimización de costos: En entornos en la nube, los recursos de CPU y memoria suelen tener un costo asociado. Al ajustar los límites de los pods en función de su uso real, el VPA ayuda a evitar la sobreasignación de recursos, lo que puede generar importantes ahorros en los costos de infraestructura.

Diferencias entre VPA y HPA

Aunque ambos, el HPA y el VPA, tienen el objetivo de ajustar los recursos para mejorar el rendimiento y la eficiencia, lo hacen de maneras muy diferentes:

HPA (Horizontal Pod Autoscaler): Ajusta el número de réplicas de un pod en función de métricas como el uso de CPU o la cantidad de peticiones HTTP. A medida que aumenta la demanda, se crean más pods para repartir la carga.
VPA (Vertical Pod Autoscaler): Ajusta los recursos asignados (CPU y memoria) a los pods existentes. En lugar de aumentar la cantidad de pods, el VPA aumenta o disminuye los recursos asignados a cada pod para que se ajusten mejor a las necesidades actuales.

Importante: Debido a que el HPA y el VPA tienen diferentes enfoques, no se pueden usar juntos en el mismo pod. Si usas el HPA, debes gestionar el escalado horizontal y las solicitudes de recursos manualmente. Si usas el VPA, es el encargado de ajustar los recursos de los pods, pero no manejará el número de réplicas.

Tipos de Modos en VPA

El VPA tiene tres modos que puedes elegir dependiendo de tus necesidades:

"Off":
- El VPA en modo Off genera recomendaciones de CPU y memoria, pero no las aplica automáticamente. Este modo es útil cuando solo deseas observar las recomendaciones antes de realizar cambios manuales en los recursos solicitados por los pods.
"Auto":
- En este modo, el VPA no solo recomienda ajustes de recursos, sino que también los aplica automáticamente. Esto significa que el VPA ajustará los límites de recursos del pod sin intervención manual. Sin embargo, algunos cambios pueden requerir que el pod sea reiniciado.
"Recreate":
- El modo Recreate reinicia los pods para aplicar las recomendaciones de recursos. Este modo es útil si los pods necesitan ser recreados para aplicar correctamente los nuevos límites de CPU o memoria. En situaciones donde no se puede aplicar un cambio en caliente, este modo garantiza que el pod se reinicie con los nuevos recursos asignados.

Implementación del Vertical Pod Autoscaler

La implementación del VPA es bastante sencilla y puede hacerse mediante un conjunto de manifiestos YAML o utilizando Helm para instalarlo. Aquí te muestro un ejemplo básico de cómo implementar el VPA.

Instalación de VPA usando Helm

Añadir el repositorio del VPA:

helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm repo update

Instalar el Vertical Pod Autoscaler:


helm install vpa autoscaler/vertical-pod-autoscaler

Una vez instalado, el VPA comenzará a monitorear los pods en el clúster y ajustará sus recursos basándose en el uso histórico.

Configuración de un ejemplo básico de VPA:

Puedes configurar el VPA para que monitoree un deployment específico. A continuación, se muestra un ejemplo de cómo aplicar el VPA a un deployment:

yaml:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       my-deployment
  updatePolicy:
    updateMode: "Auto"

En este ejemplo, el VPA se aplicará al deployment my-deployment y ajustará automáticamente los recursos de CPU y memoria de los pods asociados.

Ejemplo: Implementación del Vertical Pod Autoscaler

Puedes encontrar más detalles sobre cómo implementar y configurar el VPA en su repositorio oficial de GitHub:

Vertical Pod Autoscaler en GitHub

Beneficios clave del Vertical Pod Autoscaler

Optimización de recursos: El VPA asegura que los pods utilicen solo los recursos necesarios, lo que optimiza el uso de CPU y memoria en el clúster, evitando la sobreasignación y reduciendo costos en entornos de nube.
Escalabilidad sin aumento de réplicas: A diferencia del HPA, el VPA permite que los pods individuales escalen en recursos sin necesidad de aumentar el número de réplicas.
Ajuste dinámico de recursos: Con el VPA, los recursos de los pods se ajustan dinámicamente en función del uso real, lo que mejora la eficiencia de las aplicaciones que tienen demandas de recursos fluctuantes.

Escalado Manual en Kubernetes.

Aunque Kubernetes ofrece mecanismos automáticos para escalar aplicaciones, como el Horizontal Pod Autoscaler (HPA) y el Cluster Autoscaler, a veces es necesario realizar un escalado manual utilizando el comando kubectl scale. Este método es útil cuando se necesita ajustar rápidamente el número de réplicas de un deployment o un statefulset, ya sea para reaccionar ante una situación puntual o para probar el comportamiento de la aplicación bajo diferentes niveles de carga.

El escalado manual es particularmente valioso en escenarios como:

Reacciones inmediatas a cambios inesperados: Si observas un pico repentino en la demanda de recursos y aún no tienes configurado el HPA o no está funcionando como se esperaba, puedes aumentar el número de réplicas manualmente para manejar la carga adicional.
Pruebas de escalabilidad: Antes de configurar un autoscaler, a menudo es útil escalar manualmente las aplicaciones para entender cómo responden a diferentes cantidades de réplicas. Esto te permite evaluar si tu aplicación está diseñada para escalar correctamente.
Entornos de desarrollo o prueba: En entornos no críticos, donde los recursos no son tan limitados o la escalabilidad automática no está configurada, puedes optar por gestionar el escalado manualmente según las necesidades inmediatas del equipo de desarrollo o pruebas.

Ejemplo de Escalado Manual de un Deployment

Supongamos que tienes un deployment llamado mysql y actualmente tiene 2 réplicas. Si deseas escalar el número de réplicas a 3, puedes hacerlo rápidamente con el siguiente comando:

kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

Este comando escala el deployment de manera inmediata, lo que significa que Kubernetes creará o eliminará réplicas adicionales según lo indicado. Sin embargo, es importante tener en cuenta que este comando no actualiza el archivo YAML original del deployment, lo que significa que el número de réplicas especificado en el manifiesto no reflejará este cambio. Si más adelante vuelves a aplicar ese archivo YAML sin actualizarlo, Kubernetes revertirá el número de réplicas al que se especifica en el manifiesto original.

Para mantener el cambio de réplicas de manera persistente, debes actualizar manualmente el manifiesto YAML después de realizar el escalado manual.

Escalado Manual de un StatefulSet

El proceso para escalar un statefulset es muy similar al de un deployment, pero es importante entender que los statefulsets se comportan de manera diferente. A diferencia de los deployments, donde las réplicas son intercambiables, en un statefulset cada pod tiene una identidad única (por ejemplo, web-0, web-1, etc.) y puede estar asociado a almacenamiento persistente específico.

Para escalar un statefulset llamado web a 3 réplicas, el comando sería:

kubectl scale --replicas=3 statefulset/web

Aquí, Kubernetes creará o eliminará réplicas adicionales, pero mantendrá las propiedades únicas de cada pod. Es importante recordar que el escalado de statefulsets tiende a ser más complejo, especialmente si los pods están utilizando volúmenes persistentes, ya que cada pod adicional o eliminado podría tener datos únicos asociados.

Consideraciones al Escalar Manualmente

Impacto inmediato: El comando kubectl scale es útil porque su efecto es inmediato; no requiere reiniciar los pods ni modificar el archivo YAML original. Es una solución temporal y reactiva para manejar cargas de trabajo fluctuantes o emergentes.
No persistente en el YAML: Como se mencionó antes, al escalar manualmente no se actualiza el archivo YAML fuente del deployment o statefulset. Si en algún momento aplicas de nuevo el manifiesto sin modificar el número de réplicas en el YAML, Kubernetes revertirá el escalado manual. Para evitar este problema, asegúrate de actualizar el YAML original después de escalar.
Escalado de statefulsets: Es importante destacar que el escalado de statefulsets puede tener un impacto mayor que el de un deployment debido a la naturaleza única de los pods. Los pods de statefulsets tienen nombres y volúmenes persistentes únicos, por lo que cualquier cambio en el número de réplicas podría requerir una reconfiguración o ajuste en el almacenamiento.

Cómo Actualizar el Manifiesto YAML Después del Escalado Manual

Si realizaste un escalado manual, deberías actualizar tu manifiesto YAML para reflejar el número actual de réplicas. Esto se puede hacer modificando la sección replicas del archivo YAML correspondiente al deployment o statefulset:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
spec:
  replicas: 3   # Actualiza el número de réplicas aquí
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306

Una vez que actualices el manifiesto, aplícalo de nuevo con:


kubectl apply -f <archivo-YAML>

Esto garantizará que tu archivo YAML refleje el cambio y que el escalado se mantenga después de futuras aplicaciones de manifiestos.

Buscar este blog

Transfórmate en un Power User!