Migra nodos a cgroupv2 de Linux

Autopilot estándar

A partir de la versión 1.33, Google Kubernetes Engine (GKE) migra los clústeres que ejecutan cgroupv1 a cgroupv2. En esta página, se explica cómo hacer lo siguiente:

• Verifica qué modo de cgroup ejecutan los nodos de tu clúster y si tus cargas de trabajo podrían verse afectadas por la transición entre modos de cgroup.
• Migra los nodos de clústeres de GKE Autopilot o los grupos de nodos de clústeres de Standard a cgroupv2.
• Inhabilita temporalmente la migración automática de nodos de GKE de cgroupv1 a cgroupv2. Sigue estas instrucciones si tu clúster ejecuta cargas de trabajo que podrían verse afectadas por la transición entre los modos de cgroup.

Puedes omitir la lectura de esta página si sabes que tus cargas de trabajo se ejecutan según lo previsto en cgroupv2 o si no se ven afectadas por la configuración del modo de cgroup. GKE migra automáticamente los clústeres que ejecutan cgroupv1 a cgroupv2 con la versión 1.33 y versiones posteriores.

Acerca de los grupos de control de Linux

kubelet y el entorno de ejecución del contenedor usan grupos de control (cgroups) de kernel de Linux para la administración de recursos, como limitar la cantidad de CPU o memoria a la que puede acceder cada contenedor en un Pod. Hay dos versiones del subsistema cgroup en el kernel: cgroupv1 y cgroupv2. La compatibilidad de Kubernetes con cgroupv2 se ingresó como alfa en la versión 1.18 de Kubernetes, Beta en 1.22 y en fase de disponibilidad general en 1.25. Para obtener más información, consulta la documentación de cgroups v2 de Kubernetes.

Para obtener información sobre cómo configurar un modo de cgroup para los clústeres estándar, consulta Opciones de configuración del modo cgroup de Linux.

Cómo GKE está realizando la transición a cgroupv2

Revisa la siguiente cronología para comprender cómo GKE realiza la transición de los clústeres existentes para usar cgroupv2:

• En las versiones anteriores a la 1.26, cgroupv1 era el valor predeterminado para los nodos. En las versiones 1.26 o posteriores, cgroupv2 es el valor predeterminado para los nodos nuevos. No hay cambios en los nodos existentes. Para obtener más información sobre el modo de cgroup que ejecutan los clústeres de GKE de forma predeterminada, consulta Verifica el modo de cgroup de los nodos del clúster.
• Con la versión secundaria 1.31, GKE dejó de admitir cgroupv1.
• A partir de la versión 1.33, GKE migra los clústeres que ejecutan cgroupv1 a cgroupv2. Puedes evitar temporalmente esta migración automática especificando de forma explícita que un grupo de nodos use cgroupv1.
• Con la versión secundaria 1.35, GKE quita la compatibilidad con cgroupv1.

Para conocer los tiempos aproximados de las actualizaciones automáticas a versiones secundarias posteriores, como la 1.31 y la 1.33, consulta el Programa estimado para los canales de versiones.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

• Habilita la API de Google Kubernetes Engine.
Habilitar la API de Google Kubernetes Engine
• Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se describen en este documento.
  Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

Verifica el modo de cgroup de los nodos del clúster

El modo cgroup predeterminado depende del tipo de clúster o grupo de nodos, y de la versión. En la versión 1.26 y posteriores, el valor predeterminado es cgroupv2. En la versión 1.25 o anteriores, el valor predeterminado es cgroupv1:

• En el caso de los clústeres de Autopilot y los grupos de nodos de clústeres de Standard nuevos creados con el aprovisionamiento automático de nodos, el modo de cgroup se basa en la versión inicial del clúster. No puedes establecer el modo de cgroup durante la creación del clúster de Autopilot. En el caso de los nodos nuevos aprovisionados automáticamente, no puedes establecer el modo de forma diferente al modo de cgroup predeterminado según la versión secundaria.
• En el caso de los grupos de nodos de clústeres de Standard creados manualmente sin aprovisionamiento automático de nodos, el modo de cgroup se basa en la versión inicial del grupo de nodos o en la configuración personalizada del sistema de nodos.

Para verificar el modo de cgroup, sigue las instrucciones según el modo de tu clúster.

Autopilot

Ejecuta el siguiente comando:

gcloud container clusters describe CLUSTER_NAME \
    --format='value(nodePools[0].config.effectiveCgroupMode)'

Reemplaza CLUSTER_NAME por el nombre del clúster.

Si el resultado es EFFECTIVE_CGROUP_MODE_V2, el clúster se está ejecutando en cgroupv2. Si el resultado es EFFECTIVE_CGROUP_MODE_V1, el clúster se está ejecutando en cgroupv1.

Los clústeres de GKE Autopilot que se crearon inicialmente con la versión 1.25 de GKE o una anterior ejecutan cgroupv1 hasta que los migres.

Estándar

Con los clústeres de GKE Standard, el modo cgroup se establece a nivel del grupo de nodos. Para verificar el modo de los grupos de nodos individuales, sigue las instrucciones para verificar la configuración de cgroup. Si los nodos de tu clúster ya usan cgroupv2, no es necesario que realices ninguna otra acción.

Migra nodos a cgroupv2

Te recomendamos que migres los nodos existentes antes de que GKE los migre automáticamente en la versión 1.33 o posterior.

Sigue estos pasos para migrar los nodos que ejecutan cgroupv1:

1. Verifica el modo de cgroup de los nodos. Si los nodos de tu clúster ya usan cgroupv2, no es necesario que realices ninguna otra acción.
2. Revisa las consideraciones sobre la migración, Migra a cgroup v2, para asegurarte de que tus cargas de trabajo estén preparadas para usar la nueva versión de la API.

3. Migra los nodos de tu clúster.

   Nota: Cuando ejecutas estos comandos para actualizar el modo de cgroup, GKE actualiza los nodos con la estrategia de actualización repentina. GKE inicia estas operaciones para actualizar los grupos de nodos o los grupos de nodos de Autopilot de inmediato en orden secuencial sin respetar las políticas de mantenimiento configuradas para el clúster.

   Autopilot

   Configura explícitamente los nodos de tu clúster para que usen cgroupv2:

   gcloud container clusters update CLUSTER_NAME \
       --autoprovisioning-cgroup-mode=v2
   

   Reemplaza CLUSTER_NAME por el nombre del clúster.

   Estándar

   1. Si usas el aprovisionamiento automático de nodos para el clúster, ejecuta el siguiente comando para asegurarte de que los grupos de nodos existentes y futuros creados con el aprovisionamiento automático de nodos usen cgroupv2:

      gcloud container clusters update CLUSTER_NAME \
          --autoprovisioning-cgroup-mode=v2
      

      Reemplaza CLUSTER_NAME por el nombre del clúster.

   2. En el caso de los grupos de nodos existentes creados sin aprovisionamiento automático de nodos, actualiza el grupo de nodos para agregar lo siguiente a la configuración del sistema de nodos:

      linuxConfig:
        cgroupMode: 'CGROUP_MODE_V2'
      

      Para obtener más información, consulta Cómo personalizar la configuración del sistema de nodos.

      Cuando creas manualmente grupos de nodos nuevos sin aprovisionamiento automático de nodos, GKE usa cgroupv2 de forma predeterminada.

Inhabilita temporalmente la migración automática a cgroupv2

Para evitar temporalmente la migración automática de nodos que ejecutan cgroupv1 a cgroupv2 con versiones secundarias 1.33 y posteriores, debes establecer cgroupv1 de forma explícita. También puedes usar estas instrucciones para revertir temporalmente a cgroupv1 si la migración de nodos a cgroupv2 causó un problema en las cargas de trabajo de tu clúster.

Nota: Cuando ejecutas estos comandos para actualizar el modo de cgroup, GKE actualiza los nodos con la estrategia de actualización de aumento. GKE inicia estas operaciones para actualizar los grupos de nodos o los grupos de nodos de Autopilot de inmediato en orden secuencial sin respetar las políticas de mantenimiento configuradas para el clúster.

Autopilot

Ejecuta el siguiente comando para los clústeres que creaste originalmente con la versión 1.25 o anterior. Si tu clúster se creó con la versión 1.26 o posterior, no puedes establecer el modo de cgroup en cgroupv1.

Configura explícitamente los nodos de tu clúster para que usen cgroupv1:

gcloud container clusters update CLUSTER_NAME \
    --autoprovisioning-cgroup-mode=v1

Reemplaza CLUSTER_NAME por el nombre del clúster.

Estándar

Para seguir ejecutando cgroupv1 con un grupo de nodos de clúster de GKE Standard que ejecute la versión 1.33 o posterior, sigue estos pasos:

1. Si usas el aprovisionamiento automático de nodos y tu clúster se creó con la versión 1.25 o una anterior, usa el siguiente comando para asegurarte de que los grupos de nodos existentes y futuros creados con el aprovisionamiento automático de nodos usen cgroupv1. Si tu clúster se creó con la versión 1.26 o una posterior, no puedes establecer el modo de cgroup en cgroupv1:

   gcloud container clusters update CLUSTER_NAME \
       --autoprovisioning-cgroup-mode=v1
   

   Reemplaza CLUSTER_NAME por el nombre del clúster.

2. En el caso de los grupos de nodos Standard existentes, actualiza el grupo de nodos para agregar lo siguiente a la configuración del sistema de nodos:

   linuxConfig:
     cgroupMode: 'CGROUP_MODE_V1'
   

   También debes establecer esta configuración de nodo para los grupos de nodos nuevos que crees de forma manual sin el aprovisionamiento automático de nodos.

   Para obtener más información, consulta Cómo personalizar la configuración del sistema de nodos.