Administrar un clúster

• 1: Administrar un clúster con kubeadm
• 1.1: Añadir nodos de trabajo Linux
• 1.2: Actualizando clústeres de kubeadm
• 1.3: Actualizando nodos Linux
• 2: Administrar recursos de memoria, CPU y API
• 3: Instalar un proveedor de políticas de red
• 4: Drenar un nodo de forma segura

1 - Administrar un clúster con kubeadm

1.1 - Añadir nodos de trabajo Linux

Esta página explica cómo añadir nodos de trabajo Linux a un clúster de kubeadm.

Antes de empezar

• Para cada nodo de trabajo a añadir al clúster, debes tener instalados los componentes necesarios según Instalando kubeadm, como kubeadm, el kubelet y un runtime de contenedores.
• Dispones de un clúster de kubeadm en ejecución, creado con kubeadm init y siguiendo los pasos del documento Creando un clúster con kubeadm.
• Dispones de acceso de superusuario al nodo.

Añadiendo nodos de trabajo Linux

Para añadir nuevos nodos de trabajo Linux a tu clúster, haz lo siguiente en cada máquina:

1. Conéctate a la máquina usando SSH u otro método.
2. Ejecuta el comando que mostró kubeadm init en su salida. Por ejemplo:

sudo kubeadm join --token <token> <host-del-plano-de-control>:<puerto-del-plano-de-control> --discovery-token-ca-cert-hash sha256:<hash>

Información adicional sobre kubeadm join

Si no tienes el token, puedes obtenerlo ejecutando el siguiente comando en el nodo controlador:

# Ejecuta esto en un nodo controlador
sudo kubeadm token list

La salida es similar a esta:

TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system:
                                                   signing          token generated by     bootstrappers:
                                                                    'kubeadm init'.        kubeadm:
                                                                                           default-node-token

Por defecto, los tokens para añadir nodos expiran a las 24 horas. Si vas a añadir un nodo al clúster después de que el token actual haya expirado, puedes crear un token nuevo ejecutando el siguiente comando en el nodo controlador:

# Ejecuta esto en un nodo controlador
sudo kubeadm token create

La salida es similar a esta:

5didvk.d09sbcov8ph2amjw

Para imprimir un comando kubeadm join generando a la vez un nuevo token, puedes usar:

sudo kubeadm token create --print-join-command

Si no tienes el valor de --discovery-token-ca-cert-hash, puedes obtenerlo ejecutando los siguientes comandos en el nodo controlador:

# Ejecuta esto en un nodo controlador
sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey  | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'

La salida es similar a:

8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78

La salida del comando kubeadm join debería parecerse a esto:

[preflight] Running pre-flight checks

... (log output of join workflow) ...

Node join complete:
* Certificate signing request sent to control-plane and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on control-plane to see this machine join.

Unos segundos más tarde, deberías ver este nodo en la salida de kubectl get nodes (por ejemplo, ejecutando kubectl en un nodo controlador).

¿Qué sigue?

• Consulta cómo añadir nodos de trabajo Windows.

1.2 - Actualizando clústeres de kubeadm

Esta página explica cómo actualizar un clúster de Kubernetes creado con kubeadm desde la versión 1.35.x a la versión 1.36.x y desde la versión 1.36.x a la 1.36.y (donde y > x). No se admite omitir versiones MENORES al actualizar. Para más detalles, visita la política de desviación de versiones.

Para ver información sobre cómo actualizar clústeres creados con versiones más antiguas de kubeadm, consulta en su lugar las siguientes páginas:

• Actualizar un clúster de kubeadm de 1.34 a 1.35
• Actualizar un clúster de kubeadm de 1.33 a 1.34
• Actualizar un clúster de kubeadm de 1.32 a 1.33
• Actualizar un clúster de kubeadm de 1.31 a 1.32

El proyecto de Kubernetes recomienda actualizar cuanto antes a la última versión de parche, así como asegurarte de que ejecutas una versión menor de Kubernetes con soporte. Seguir esta recomendación te ayuda a mantener la seguridad.

En líneas generales, el proceso de actualización sigue los siguientes pasos:

1. Actualizar el nodo controlador principal.
2. Actualizar los demás nodos controladores (en el caso de que hubiera más de uno).
3. Actualizar los nodos de trabajo.

Antes de empezar

• Lee detenidamente las notas de la versión.
• El clúster debe usar pods estáticos para el plano de control y etcd, o un etcd externo.
• Asegúrate de hacer una copia de seguridad de cualquier componente importante, como el estado a nivel de aplicación almacenado en una base de datos. kubeadm upgrade no toca tus cargas de trabajo, solo los componentes internos de Kubernetes, pero las copias de seguridad son siempre una buena práctica.
• La swap debe estar deshabilitada.

Información adicional

• Las instrucciones siguientes indican en qué momento drenar cada nodo durante el proceso de actualización. Si vas a realizar una actualización de versión menor de cualquier kubelet, debes drenar primero el nodo (o los nodos) que estás actualizando. En el caso de los nodos controladores, podrían estar ejecutando pods de CoreDNS u otras cargas de trabajo críticas. Para más información, consulta cómo drenar un nodo de forma segura.
• El proyecto de Kubernetes recomienda que las versiones de kubelet y kubeadm coincidan. También puedes usar una versión de kubelet más antigua que la de kubeadm, siempre que esté dentro del rango de versiones soportadas. Para más detalles, visita la desviación de kubeadm respecto al kubelet.
• Todos los contenedores se reinician tras la actualización, porque el valor del hash de la spec del contenedor cambia.
• Para verificar que el servicio del kubelet se ha reiniciado correctamente después de actualizar el kubelet, puedes ejecutar systemctl status kubelet o ver los logs del servicio con journalctl -xeu kubelet.
• kubeadm upgrade admite --config con un tipo de la API UpgradeConfiguration que puede usarse para configurar el proceso de actualización.
• kubeadm upgrade no admite la reconfiguración de un clúster existente. Sigue en su lugar los pasos de reconfigurando un clúster de kubeadm.

Consideraciones al actualizar el etcd

Como el pod estático del kube-apiserver se ejecuta en todo momento (incluso si has drenado el nodo), cuando realizas una actualización de kubeadm que incluye una actualización del etcd, las peticiones al servidor se quedarán bloqueadas mientras se reinicia el nuevo pod estático del etcd. Como solución alternativa, es posible detener activamente el proceso kube-apiserver unos segundos antes de lanzar el comando kubeadm upgrade apply. Esto permite completar las peticiones en curso y cerrar las conexiones existentes, y minimiza las consecuencias de la indisponibilidad del etcd. Para ello, ejecuta los siguientes comandos en los nodos controladores:

killall -s SIGTERM kube-apiserver # provoca un apagado controlado de kube-apiserver
sleep 20 # espera un poco para permitir que se completen las peticiones en curso
kubeadm upgrade ... # ejecuta un comando de actualización de kubeadm

Cambiando el repositorio de paquetes

Si usas los repositorios de paquetes gestionados por la comunidad (pkgs.k8s.io), necesitas habilitar el repositorio de paquetes de la versión menor de Kubernetes deseada. Esto se explica en el documento: cambiando el repositorio de paquetes de Kubernetes.

Determinar a qué versión actualizar

Encuentra la última versión de parche de Kubernetes 1.36 usando el gestor de paquetes del sistema operativo:

• Ubuntu, Debian o HypriotOS
• CentOS, RHEL o Fedora

# Busca la última versión 1.36 en la lista.
# Debería parecerse a 1.36.x-*, donde x es el último parche.
sudo apt update
sudo apt-cache madison kubeadm

# Busca la última versión 1.36 en la lista.
# Debería parecerse a 1.36.x-*, donde x es el último parche.
sudo yum list --showduplicates kubeadm --disableexcludes=kubernetes

# Busca la última versión 1.36 en la lista.
# Debería parecerse a 1.36.x-*, donde x es el último parche.
sudo yum list --showduplicates kubeadm --setopt=disable_excludes=kubernetes

Si no ves la versión a la que esperas actualizar, verifica si se están usando los repositorios de paquetes de Kubernetes.

Actualizando los nodos controladores

Los nodos controladores deben actualizarse de uno en uno. Elige el nodo controlador que quieras actualizar primero. Debe tener el archivo /etc/kubernetes/admin.conf.

Ejecuta "kubeadm upgrade"

Para el primer nodo controlador

1. Actualiza kubeadm:

   • Ubuntu, Debian o HypriotOS
   • CentOS, RHEL o Fedora

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo apt-mark unhold kubeadm && \
   sudo apt-get update && sudo apt-get install -y kubeadm='1.36.x-*' && \
   sudo apt-mark hold kubeadm
   

   Para sistemas con DNF:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubeadm-'1.36.x-*' --disableexcludes=kubernetes
   

   Para sistemas con DNF5:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubeadm-'1.36.x-*' --setopt=disable_excludes=kubernetes
   

2. Verifica que la descarga funciona y tiene la versión esperada:

   kubeadm version
   

3. Verifica el plan de actualización:

   sudo kubeadm upgrade plan
   

   Este comando comprueba que tu clúster puede actualizarse y obtiene las versiones a las que puedes actualizar. También muestra una tabla con el estado de las versiones de configuración de los componentes.

   Nota:

   kubeadm upgrade también renueva automáticamente los certificados que gestiona en este nodo. Para desactivar la renovación de certificados puede usarse el flag --certificate-renewal=false. Para más información, consulta la guía de gestión de certificados.

4. Elige una versión a la que actualizar y ejecuta el comando apropiado. Por ejemplo:

   # sustituye x por la versión de parche que elegiste para esta actualización
   sudo kubeadm upgrade apply v1.36.x
   

   Una vez que el comando termine, deberías ver:

   [upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.36.x". Enjoy!
   
   [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
   

   Nota:

   Para las versiones anteriores a v1.28, kubeadm usaba por defecto un modo que actualizaba los complementos (incluidos CoreDNS y kube-proxy) inmediatamente durante kubeadm upgrade apply, sin importar si hubiera otras instancias del plano de control sin actualizar. Esto puede causar problemas de compatibilidad. Desde v1.28, kubeadm usa por defecto un modo que comprueba si todas las instancias del plano de control se han actualizado antes de empezar a actualizar los complementos. Debes realizar la actualización de todas las instancias del plano de control de forma secuencial o, al menos, asegurarte de que la actualización de la última instancia del plano de control no comienza hasta que todas las demás instancias se hayan actualizado por completo; la actualización de los complementos se realizará después de actualizar la última instancia del plano de control.

5. Actualiza manualmente el plugin de tu proveedor de CNI.

   Tu proveedor de Container Network Interface (CNI) puede tener sus propias instrucciones de actualización. Consulta la página de complementos para encontrar tu proveedor de CNI y ver si se requieren pasos de actualización adicionales.

   Este paso no es necesario en los demás nodos controladores si el proveedor de CNI se ejecuta como un DaemonSet.

Para los demás nodos controladores

Igual que en el primer nodo controlador, pero usa:

sudo kubeadm upgrade node

en lugar de:

sudo kubeadm upgrade apply

Además, ya no es necesario ejecutar kubeadm upgrade plan ni actualizar el plugin del proveedor de CNI.

Drena el nodo

Prepara el nodo para el mantenimiento marcándolo como no programable y desalojando las cargas de trabajo:

# sustituye <nodo-a-drenar> por el nombre del nodo que estás drenando
kubectl drain <nodo-a-drenar> --ignore-daemonsets

Actualiza kubelet y kubectl

1. Actualiza el kubelet y kubectl:

   • Ubuntu, Debian o HypriotOS
   • CentOS, RHEL o Fedora

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo apt-mark unhold kubelet kubectl && \
   sudo apt-get update && sudo apt-get install -y kubelet='1.36.x-*' kubectl='1.36.x-*' && \
   sudo apt-mark hold kubelet kubectl
   

   Para sistemas con DNF:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubelet-'1.36.x-*' kubectl-'1.36.x-*' --disableexcludes=kubernetes
   

   Para sistemas con DNF5:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubelet-'1.36.x-*' kubectl-'1.36.x-*' --setopt=disable_excludes=kubernetes
   

2. Reinicia el kubelet:

   sudo systemctl daemon-reload
   sudo systemctl restart kubelet
   

Reincorpora el nodo

Vuelve a poner el nodo disponible marcándolo como programable:

# sustituye <nodo-a-reincorporar> por el nombre de tu nodo
kubectl uncordon <nodo-a-reincorporar>

Actualizar los nodos de trabajo

Los nodos de trabajo deben actualizarse de uno en uno o en pequeños grupos, sin comprometer la capacidad mínima necesaria para ejecutar tus cargas de trabajo.

Las siguientes páginas muestran cómo actualizar nodos de trabajo Linux y Windows:

• Actualizar nodos Linux
• Actualizar nodos Windows

Verificar el estado del clúster

Después de actualizar el kubelet en todos los nodos, verifica que todos los nodos vuelven a estar disponibles ejecutando el siguiente comando desde donde kubectl tenga acceso al clúster:

kubectl get nodes

La columna STATUS debería mostrar Ready para todos tus nodos, y el número de versión debería estar actualizado.

Recuperarse de un estado de fallo

Si kubeadm upgrade falla y no revierte los cambios, por ejemplo debido a un apagado inesperado durante la ejecución, puedes ejecutar kubeadm upgrade de nuevo. Este comando es idempotente y asegura que el estado real sea el que declaras.

Para recuperarte de un estado erróneo, también puedes ejecutar sudo kubeadm upgrade apply --force sin cambiar la versión que ejecuta tu clúster.

Durante la actualización, kubeadm escribe los siguientes directorios de copia de seguridad bajo /etc/kubernetes/tmp:

• kubeadm-backup-etcd-<fecha>-<hora>
• kubeadm-backup-manifests-<fecha>-<hora>

kubeadm-backup-etcd contiene una copia de seguridad de los datos del miembro local del etcd de este nodo controlador. En caso de que falle una actualización del etcd y la reversión automática no funcione, el contenido de esta carpeta puede restaurarse manualmente en /var/lib/etcd. Si se usa un etcd externo, esta carpeta de copia de seguridad estará vacía.

kubeadm-backup-manifests contiene una copia de seguridad de los archivos de manifiesto de los pods estáticos de este nodo controlador. En caso de que falle una actualización y la reversión automática no funcione, el contenido de esta carpeta puede restaurarse manualmente en /etc/kubernetes/manifests. Si por alguna razón no hay diferencias entre el archivo de manifiesto de un componente antes y después de la actualización, no se escribirá un archivo de copia de seguridad para él.

Cómo funciona

kubeadm upgrade apply hace lo siguiente:

• Comprueba que tu clúster está en un estado actualizable:
  • El servidor de la API es accesible
  • Todos los nodos están en estado Ready
  • El plano de control está operativo
• Aplica las políticas de desviación de versiones.
• Se asegura de que las imágenes del plano de control están disponibles o pueden descargarse desde la máquina.
• Genera reemplazos y/o usa las sobrescrituras proporcionadas por el usuario si las configuraciones de los componentes requieren actualizaciones de versión.
• Actualiza los componentes del plano de control, o los revierte si alguno de ellos no consigue arrancar.
• Aplica los nuevos manifiestos de CoreDNS y kube-proxy y se asegura de que se crean todas las reglas RBAC necesarias.
• Crea nuevos archivos de certificado y clave del servidor de la API, y hace una copia de seguridad de los archivos antiguos si van a expirar en 180 días.

kubeadm upgrade node hace lo siguiente en los demás nodos controladores:

• Obtiene la ClusterConfiguration de kubeadm del clúster.
• Opcionalmente, hace una copia de seguridad del certificado de kube-apiserver.
• Actualiza los manifiestos de los pods estáticos de los componentes del plano de control.
• Actualiza la configuración del kubelet de este nodo.

kubeadm upgrade node hace lo siguiente en los nodos de trabajo:

• Obtiene la ClusterConfiguration de kubeadm del clúster.
• Actualiza la configuración del kubelet de este nodo.

1.3 - Actualizando nodos Linux

Esta página explica cómo actualizar nodos de trabajo Linux creados con kubeadm.

Antes de empezar

Necesitas tener acceso a la terminal en todos los nodos, y la herramienta de línea de comandos kubectl debe estar configurada para comunicarse con tu clúster. Se recomienda seguir este tutorial en un clúster con al menos dos nodos que no actúen como nodos controladores.

Para verificar la versión, ingresa kubectl version.

• Familiarízate con el proceso para actualizar el clúster de kubeadm. Conviene actualizar los nodos controladores antes de actualizar los nodos de trabajo Linux.

Cambiando el repositorio de paquetes

Si usas los repositorios de paquetes gestionados por la comunidad (pkgs.k8s.io), necesitas habilitar el repositorio de paquetes de la versión menor de Kubernetes deseada. Esto se explica en el documento cambiando el repositorio de paquetes de Kubernetes.

Actualizando los nodos de trabajo

Actualiza kubeadm

Actualiza kubeadm:

• Ubuntu, Debian o HypriotOS
• CentOS, RHEL o Fedora

# sustituye x en 1.36.x-* por la última versión de parche
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.36.x-*' && \
sudo apt-mark hold kubeadm

# sustituye x en 1.36.x-* por la última versión de parche
sudo yum install -y kubeadm-'1.36.x-*' --disableexcludes=kubernetes

# sustituye x en 1.36.x-* por la última versión de parche
sudo yum install -y kubeadm-'1.36.x-*' --setopt=disable_excludes=kubernetes

Ejecuta "kubeadm upgrade"

Para los nodos de trabajo, este comando actualiza la configuración local del kubelet:

sudo kubeadm upgrade node

Drena el nodo

Prepara el nodo para el mantenimiento marcándolo como no programable y desalojando las cargas de trabajo:

# ejecuta este comando en un nodo controlador
# sustituye <nodo-a-drenar> por el nombre del nodo que estás drenando
kubectl drain <nodo-a-drenar> --ignore-daemonsets

Actualiza kubelet y kubectl

1. Actualiza el kubelet y kubectl:

   • Ubuntu, Debian o HypriotOS
   • CentOS, RHEL o Fedora

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo apt-mark unhold kubelet kubectl && \
   sudo apt-get update && sudo apt-get install -y kubelet='1.36.x-*' kubectl='1.36.x-*' && \
   sudo apt-mark hold kubelet kubectl
   

   Para sistemas con DNF:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubelet-'1.36.x-*' kubectl-'1.36.x-*' --disableexcludes=kubernetes
   

   Para sistemas con DNF5:

   # sustituye x en 1.36.x-* por la última versión de parche
   sudo yum install -y kubelet-'1.36.x-*' kubectl-'1.36.x-*' --setopt=disable_excludes=kubernetes
   

2. Reinicia el kubelet:

   sudo systemctl daemon-reload
   sudo systemctl restart kubelet
   

Reincorpora el nodo

Vuelve a poner el nodo disponible marcándolo como programable:

# ejecuta este comando en un nodo controlador
# sustituye <nodo-a-reincorporar> por el nombre de tu nodo
kubectl uncordon <nodo-a-reincorporar>

¿Qué sigue?

• Consulta cómo actualizar nodos Windows.

2 - Administrar recursos de memoria, CPU y API

3 - Instalar un proveedor de políticas de red

4 - Drenar un nodo de forma segura

Esta página muestra cómo drenar de forma segura un nodo, opcionalmente con respecto al presupuesto de interrupción de pods definido.

Antes de empezar

Esta tarea asume que cumples los siguientes requisitos previos:

1. No requieres que tus aplicaciones sean altamente disponibles durante el drenaje del nodo, o
2. Has leído sobre el concepto de presupuesto de interrupción de pods y has configurado presupuestos de interrupción de pods para las aplicaciones que lo necesiten.

(Opcional) Configura un presupuesto de interrupción

Para asegurarte de que tus cargas de trabajo permanecen disponibles durante el mantenimiento, puedes configurar un presupuesto de interrupción de pods.

Si la disponibilidad es importante para cualquiera de las aplicaciones que podrían ejecutarse en el/los nodo(s) que estás drenando, configura un presupuesto de interrupción de pods antes de seguir con esta guía.

Se recomienda configurar AlwaysAllow como política de desalojo de pods no saludables en tu presupuesto de interrupción de pods para permitir el desalojo de aplicaciones que no funcionen correctamente durante el drenaje de un nodo. El comportamiento por defecto es esperar a que los pods de la aplicación pasen a estar saludables antes de proceder con el drenaje.

Usa kubectl drain para eliminar un nodo del servicio

Puedes usar kubectl drain para desalojar de forma segura todos los pods de un nodo antes de realizar las tareas de mantenimiento en dicho nodo (por ejemplo, la actualización del kernel, mantenimiento del hardware, etc.). Los desalojos seguros permiten que los contenedores de los pods no terminen abruptamente y respeten el presupuesto de interrupción de pods que has especificado.

Cuando kubectl drain devuelve un resultado exitoso, esto indica que todos los pods (excepto los descritos en el párrafo anterior) han sido desalojados de forma segura (respetando el periodo de terminación no abrupta y el presupuesto de interrupción de pods que hayas definido). En este momento, es seguro apagar el nodo desconectando su máquina física o, si se ejecuta en una plataforma en la nube, eliminando su máquina virtual.

En primer lugar, identifica el nombre del nodo que quieres drenar. Puedes ver la lista de todos los nodos de tu clúster con:

kubectl get nodes

A continuación, dile a Kubernetes que drene el nodo:

kubectl drain --ignore-daemonsets <nombre del nodo>

Si hay pods gestionados por un DaemonSet, necesitarás especificar --ignore-daemonsets con kubectl para poder drenar el nodo de forma exitosa. El subcomando kubectl drain en sí mismo no drena los pods del DaemonSet de un nodo: el controlador de DaemonSets (plano de control) inmediatamente reemplaza los pods que faltan por nuevos pods equivalentes. El controlador de DaemonSets también crea pods que toleran las taints no programables (node.kubernetes.io/unschedulable), lo que permite que los nuevos pods se inicien en el nodo que estás drenando.

Una vez que devuelva un resultado (sin dar ningún error), puedes apagar el nodo (o, si se trata de una plataforma en la nube, eliminar la máquina virtual que aloja el nodo).

Posteriormente, cuando el nodo vuelva a estar operativo después de las tareas de mantenimiento, necesitas ejecutar:

kubectl uncordon <nombre del nodo>

para indicarle a Kubernetes que puede reanudar la programación de nuevos pods en el nodo.

Drenando múltiples nodos en paralelo

El comando kubectl drain solo debe ejecutarse en un único nodo a la vez. Sin embargo, puedes ejecutar múltiples comandos kubectl drain para diferentes nodos en paralelo, en diferentes terminales o en segundo plano. Aunque se ejecuten varios comandos de drenaje al mismo tiempo, seguirán respetando el presupuesto de interrupción de pods que especifiques.

Por ejemplo, si tienes un StatefulSet con tres réplicas y un presupuesto de interrupción de minAvailable: 2 para él, kubectl drain solo desalojará un pod del StatefulSet si las tres réplicas están saludables; si ejecutas varios comandos de drenaje en paralelo, Kubernetes respetará el presupuesto de interrupción de pods y asegurará que solo 1 pod (calculado como replicas - minAvailable) esté no disponible en cualquier momento. Cualquier drenaje que pudiera causar que el número de réplicas saludables caiga debajo del presupuesto especificado, sería bloqueado.

La API de desalojos

Si prefieres no usar kubectl drain (por ejemplo, para evitar llamar a un comando externo o para tener un control más preciso sobre el proceso de desalojo de pods), puedes provocar los desalojos de manera programática usando la API de desalojos.

Para más información, consulta desalojo iniciado por API.

¿Qué sigue?

• Sigue estos pasos para proteger tu aplicación configurando un presupuesto de interrupción de pods.