Personalizar la configuración del sistema de nodos

En este documento se explica cómo personalizar la configuración de los nodos de Google Kubernetes Engine (GKE) mediante un archivo de configuración llamado configuración del sistema de nodos.

Información general

Puedes personalizar la configuración de tu nodo de varias formas. Por ejemplo, puedes especificar parámetros como el tipo de máquina y la plataforma de CPU mínima al crear un pool de nodos.

Una configuración del sistema de nodos es un archivo de configuración que proporciona una forma de ajustar un conjunto limitado de ajustes del sistema. Puedes usar una configuración del sistema de nodos para especificar ajustes personalizados del agente de nodos de Kubernetes ( kubelet) y configuraciones de kernel de Linux de bajo nivel (sysctl) en tus grupos de nodos.

También puedes personalizar el tiempo de ejecución del contenedor de containerd en tus nodos de GKE mediante otro archivo llamado archivo de configuración del tiempo de ejecución. Para obtener instrucciones, consulta Personalizar la configuración de containerd en nodos de GKE.

También puedes usar DaemonSets para personalizar nodos, como en Inicializar automáticamente nodos de GKE con DaemonSets.

Usar una configuración del sistema de nodos

Puedes personalizar la configuración del sistema de nodos con cualquiera de los siguientes métodos:

  • Archivo de configuración: disponible en el modo Estándar. Se usa un archivo YAML que contiene los parámetros de configuración de kubelet y del kernel de Linux. En los pasos de esta página se explica cómo crear y usar un archivo de configuración.
  • ComputeClass disponible en los modos Autopilot y Standard. Puedes especificar la configuración del sistema de nodos en la especificación de ComputeClass de GKE. Las clases de computación te permiten definir conjuntos de atributos de nodo para que GKE los use cuando aumente la escala de tu clúster. Disponible en la versión 1.32.1-gke.1729000 de GKE y en versiones posteriores. Para obtener más información, consulta Información sobre las clases de computación en GKE.

Para usar un archivo de configuración del sistema de nodos, haz lo siguiente:

  1. Crea un archivo de configuración. Este archivo contiene las configuraciones de kubelet y sysctl.
  2. Añade la configuración cuando crees un clúster o cuando crees o actualices un grupo de nodos.

Crear un archivo de configuración

Escribe el archivo de configuración del sistema de nodos en YAML. En el ejemplo siguiente se muestra cómo añadir configuraciones para las opciones kubelet y sysctl:

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
  - 'kernel.shm*'
  - 'kernel.msg*'
  - 'kernel.sem'
  - 'fs.mqueue*'
  - 'net.*'
linuxConfig:
 sysctl:
   net.core.somaxconn: '2048'
   net.ipv4.tcp_rmem: '4096 87380 6291456'

En este ejemplo:

  • cpuManagerPolicy: static configura el kubelet para que use la política de gestión de CPU estática.
  • net.core.somaxconn: '2048' limita la acumulación de socket listen() a 2048 bytes.
  • net.ipv4.tcp_rmem: '4096 87380 6291456' define los valores mínimo, predeterminado y máximo del búfer de recepción de sockets TCP en 4096 bytes, 87.380 bytes y 6.291.456 bytes, respectivamente.

Si solo quieres añadir configuraciones para kubelet o sysctl, incluye únicamente esa sección en tu archivo de configuración. Por ejemplo, para añadir una configuración de kubelet, crea el siguiente archivo:

kubeletConfig:
  cpuManagerPolicy: static

Para ver una lista completa de los campos que puedes añadir al archivo de configuración, consulta las secciones Opciones de configuración de Kubelet y Opciones de configuración de Sysctl.

Añadir la configuración a un grupo de nodos

Una vez que hayas creado el archivo de configuración, añade la marca --system-config-from-file con la interfaz de línea de comandos de Google Cloud. Puedes añadir esta marca cuando crees un clúster o cuando crees o actualices un grupo de nodos. No puedes añadir una configuración de sistema de nodos con la consola Google Cloud .

Crear un clúster con la configuración del sistema de nodos

Puedes añadir una configuración del sistema de nodos durante la creación del clúster con la CLI de gcloud o Terraform. Las siguientes instrucciones aplican la configuración del sistema de nodos al grupo de nodos predeterminado:

CLI de gcloud 

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Haz los cambios siguientes:

  • CLUSTER_NAME: el nombre del clúster
  • LOCATION: la zona o región de computación del clúster
  • SYSTEM_CONFIG_PATH: la ruta al archivo que contiene las configuraciones de kubelet y sysctl

Una vez que hayas aplicado una configuración del sistema de nodos, el grupo de nodos predeterminado del clúster usará los ajustes que hayas definido.

Terraform

Para crear un clúster regional con una configuración de sistema de nodos personalizada mediante Terraform, consulta el siguiente ejemplo:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Para obtener más información sobre el uso de Terraform, consulta Compatibilidad de Terraform con GKE.

Crear un grupo de nodos con la configuración del sistema de nodos

Puedes añadir una configuración del sistema de nodos cuando utilices la CLI de gcloud o Terraform para crear un grupo de nodos. También puedes actualizar la configuración del sistema de nodos de un grupo de nodos.

Las siguientes instrucciones aplican la configuración del sistema de nodos a un nuevo grupo de nodos:

CLI de gcloud 

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

``` Replace the following:
  • POOL_NAME: el nombre del grupo de nodos
  • CLUSTER_NAME: el nombre del clúster al que quieres añadir un grupo de nodos
  • LOCATION: la zona o región de computación del clúster
  • SYSTEM_CONFIG_PATH: la ruta al archivo que contiene las configuraciones de kubelet y sysctl

Terraform

Para crear un grupo de nodos con una configuración del sistema de nodos personalizada mediante Terraform, consulta el siguiente ejemplo:

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Para obtener más información sobre el uso de Terraform, consulta Compatibilidad de Terraform con GKE.

Actualizar la configuración del sistema de nodos de un grupo de nodos

Ejecuta el siguiente comando:

  gcloud container node-pools update POOL_NAME \
      --cluster=CLUSTER_NAME \
      --location=LOCATION \
      --system-config-from-file=SYSTEM_CONFIG_PATH

Haz los cambios siguientes:

  • POOL_NAME: el nombre del grupo de nodos que quieras actualizar
  • CLUSTER_NAME: el nombre del clúster que quieras actualizar
  • LOCATION: la zona o región de computación del clúster
  • SYSTEM_CONFIG_PATH: la ruta al archivo que contiene las configuraciones de kubelet y sysctl

Para aplicar este cambio, es necesario volver a crear los nodos, lo que puede provocar interrupciones en las cargas de trabajo en ejecución. Para obtener más información sobre este cambio concreto, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos sin respetar las políticas de mantenimiento. Para obtener más información sobre las actualizaciones de nodos, consulta Planificar las interrupciones de las actualizaciones de nodos.

Editar una configuración del sistema de nodos

Para editar la configuración del sistema de nodos, puedes crear un grupo de nodos con la configuración que quieras o actualizar la configuración del sistema de nodos de un grupo de nodos.

Editar creando un grupo de nodos

Para editar la configuración del sistema de nodos creando un grupo de nodos, sigue estos pasos:

  1. Crea un archivo de configuración con la configuración que quieras.
  2. Añade la configuración a un nuevo grupo de nodos.
  3. Migra tus cargas de trabajo al nuevo grupo de nodos.
  4. Elimina el grupo de nodos antiguo.

Editar un grupo de nodos actualizándolo

Para editar la configuración del sistema de nodos de un grupo de nodos, sigue las instrucciones de la pestaña Actualizar grupo de nodos para añadir la configuración a un grupo de nodos. Al actualizar la configuración del sistema de nodos, se sustituye la configuración del sistema del grupo de nodos por la nueva configuración, lo que requiere volver a crear los nodos. Si omites algún parámetro durante una actualización, se le asignará el valor predeterminado correspondiente.

Si quieres restablecer la configuración predeterminada del sistema de nodos, actualiza el archivo de configuración con valores vacíos para kubelet y sysctl. Por ejemplo:

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Eliminar una configuración del sistema de nodos

Para quitar una configuración del sistema de nodos:

  1. Crea un grupo de nodos.
  2. Migra tus cargas de trabajo al nuevo grupo de nodos.
  3. Elimina el grupo de nodos que tenga la configuración del sistema de nodos anterior.

Opciones de configuración de Kubelet

En la siguiente tabla se muestran las opciones de kubelet que puedes modificar.

Ajustes de configuración de Kubelet Restricciones Ajuste predeterminado Descripción
allowedUnsafeSysctls Lista de sysctl nombres o grupos. Grupos sysctl permitidos: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* y net.*. Ejemplo: [kernel.msg*, net.ipv4.route.min_pmtu]. none Este ajuste define una lista de elementos permitidos separada por comas de nombres o grupos sysctl no seguros, que se pueden definir en los pods.sysctl

Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
containerLogMaxSize El valor debe ser un número positivo y un sufijo de unidad entre 10Mi y 500Mi, ambos incluidos. Las unidades válidas son Ki, Mi, Gi. 10Mi Este ajuste controla el ajuste containerLogMaxSize de la política de rotación de registros de contenedores, que le permite configurar el tamaño máximo de cada archivo de registro. El valor predeterminado es 10Mi.
containerLogMaxFiles El valor debe ser un número entero entre 2 y 10, ambos incluidos. 5 Este ajuste controla el ajuste containerLogMaxFiles de la política de rotación de archivos de registro de contenedores, que te permite configurar el número máximo de archivos permitidos para cada contenedor. El valor predeterminado es 5. El tamaño total de los registros (container_log_max_size*container_log_max_files) por contenedor no puede superar el 1 % del almacenamiento total del nodo.
cpuCFSQuota El valor debe ser true o false true Este ajuste aplica el límite de CPU de los pods. Si se asigna el valor false, se ignorarán los límites de CPU de los pods.

Ignorar los límites de CPU puede ser recomendable en determinados casos en los que los pods sean sensibles a los límites de CPU. El riesgo de inhabilitar cpuCFSQuota es que un pod no autorizado puede consumir más recursos de CPU de lo previsto.
cpuCFSQuotaPeriod El valor debe ser una duración "100ms" Este ajuste define el valor del periodo de cuota de CFS de la CPU, cpu.cfs_period_us, que especifica la frecuencia con la que se debe reasignar el acceso de un cgroup a los recursos de la CPU. Esta opción te permite ajustar el comportamiento de limitación de la CPU.
imageGcLowThresholdPercent El valor debe ser un número entero entre 10 y 85, ambos incluidos, e inferior a imageGcHighThresholdPercent. 80 Este ajuste define el porcentaje de uso del disco antes del cual nunca se ejecuta la recogida de elementos no utilizados de las imágenes. Uso de disco más bajo para la recolección de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo entre 100. Si se especifica, el valor debe ser inferior a imageGcHighThresholdPercent.
imageGcHighThresholdPercent El valor debe ser un número entero entre 10 y 85, ambos incluidos, y superior a imageGcLowThresholdPercent. 85 Este ajuste define el porcentaje de uso del disco por encima del cual se ejecuta la recogida de elementos no utilizados de las imágenes. Uso de disco máximo para la recolección de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo entre 100. Si se especifica, el valor debe ser superior a imageGcLowThresholdPercent.
imageMinimumGcAge El valor debe ser una duración no superior a "2m". Las unidades de tiempo válidas son "ns", "us" (or "µs"), "ms", "s", "m", "h". 2m imageMinimumGcAge es la edad mínima de una imagen no utilizada antes de que se recoja como elemento no utilizado.
imageMaximumGcAge El valor debe ser una duración 0s imageMaximumGcAge es la antigüedad máxima que puede tener una imagen sin usar antes de que se recoja como elemento no utilizado. El valor predeterminado de este campo es "0s", lo que lo inhabilita. Es decir, las imágenes no se eliminarán por no haberse usado durante demasiado tiempo. Si se especifica, el valor debe ser superior a imageMinimumGcAge.

Disponible en las versiones 1.30.7-gke.1076000, 1.31.3-gke.1023000 o posteriores de GKE.
insecureKubeletReadonlyPortEnabled El valor debe ser un valor booleano (true o false). true Este ajuste inhabilita el puerto de solo lectura de kubelet no seguro 10255 en cada grupo de nodos nuevo de tu clúster. Si configuras este ajuste en este archivo, no podrás usar un cliente de la API de GKE para cambiar el ajuste a nivel de clúster.
podPidsLimit El valor debe estar entre 1024 y 4194304 none Este ajuste define el número máximo de IDs de proceso (PIDs) que puede usar cada pod.
maxParallelImagePulls El valor debe ser un número entero entre 2 y 5, ambos incluidos. 2 o 3 en función del tipo de disco Este ajuste define el número máximo de extracciones de imágenes en paralelo. El valor predeterminado se decide en función del tipo de disco de arranque:

  • Valor predeterminado 3: pd-balanced, pd-ssd o SSD local efímero.
  • Predeterminado 2: pd-standard u otros tipos de disco de arranque.

    • Disponible en las versiones 1.33.1-gke.1918000 o posteriores de GKE.
    evictionSoft Mapa de nombres de señales. Para ver las restricciones de los valores, consulta la siguiente tabla. none Esta opción asigna nombres de señales a cantidades o porcentajes que definen los umbrales de desalojo flexible. Un umbral de desalojo suave debe tener un periodo de gracia. Kubelet no expulsa los pods hasta que se supera el periodo de gracia.
    evictionSoftGracePeriod Mapa de nombres de señales, que tiene las mismas opciones que evictionSoft con restricciones diferentes. En el caso de cada nombre de señal, el valor debe ser una duración positiva inferior a 5m (por ejemplo, 30s o 1m). Las unidades de tiempo válidas son "ns", "us" (o "µs"), "ms", "s", "m" o "h". none Este ajuste asigna nombres de señales a duraciones que definen los periodos de gracia de los umbrales de expulsión suave. Cada umbral de desalojo suave debe tener un periodo de gracia correspondiente.
    evictionMinimumReclaim Mapa de nombres de señales, que tiene las mismas opciones que evictionSoft con restricciones diferentes. En el caso de cada nombre de señal, el valor debe ser un porcentaje positivo inferior a 10% (por ejemplo, 5%). none Esta opción asigna nombres de señales a porcentajes que definen la cantidad mínima de un recurso determinado que reclama kubelet cuando realiza un desalojo de pods.
    evictionMaxPodGracePeriodSeconds El valor debe ser un número entero entre 0 y 300. 0 Este ajuste define, en segundos, el periodo de gracia máximo para la finalización de los pods durante el desalojo.

    En la siguiente tabla se muestran las opciones de la marca evictionSoft que puedes modificar. Las mismas opciones se aplican también a las marcas evictionSoftGracePeriod y evictionMinimumReclaim, pero con diferentes restricciones.

    Ajustes de configuración de Kubelet Restricciones Ajuste predeterminado Descripción
    memoryAvailable El valor debe ser una cantidad superior a 100Mi e inferior a 50% de la memoria del nodo. Por ejemplo, 100Mi, 1Gi. none Representa la cantidad de memoria disponible antes de la expulsión suave. Define la cantidad de la señal memory.available en el kubelet.
    nodefsAvailable El valor debe estar entre 10% y 50%. none Representa el nodefs disponible antes de la expulsión suave. Define la cantidad de la señal nodefs.available en el kubelet.
    nodefsInodesFree El valor debe estar entre 5% y 50%. none Representa los inodos de nodefs que están libres antes de la expulsión suave. Define la cantidad de la señal nodefs.inodesFree en el kubelet.
    imagefsAvailable El valor debe estar entre 15% y 50%. none Representa el espacio de almacenamiento de imágenes disponible antes de la expulsión suave. Define la cantidad de señal imagefs.available en el kubelet.
    imagefsInodesFree El valor debe estar entre 5% y 50%. none Representa los inodos de imagefs que están libres antes de la expulsión suave. Define la cantidad de la señal imagefs.inodesFree en el kubelet.
    pidAvailable El valor debe estar entre 10% y 50%. none Representa los PIDs disponibles antes de la expulsión suave. Define la cantidad de la señal pid.available en el kubelet.
    singleProcessOOMKill El valor debe ser true o false true para nodos cgroupv1 y false para nodos cgroupv2. Este ajuste determina si los procesos del contenedor se eliminan por falta de memoria individualmente o como grupo.

    Disponible en las versiones 1.32.4-gke.1132000, 1.33.0-gke.1748000 o posteriores de GKE.

    Gestores de recursos

    Kubernetes ofrece un conjunto de gestores de recursos. Puedes configurar estos gestores de recursos para coordinar y optimizar la asignación de recursos de nodos a pods configurados con requisitos específicos de recursos de CPU, dispositivos y memoria (páginas enormes). Para obtener más información, consulta Gestores de recursos de nodos.

    Con GKE, puedes configurar los siguientes ajustes para estos gestores de recursos. Puedes configurar estos ajustes de forma independiente, pero te recomendamos que los uses juntos para alinear la gestión de recursos. Puedes usar los ajustes de Topology Manager junto con los de CPU Manager y Memory Manager para alinear la CPU y la memoria con otros recursos solicitados en la especificación del pod.

    Ajustes de configuración de Kubelet Restricciones Ajuste predeterminado Descripción 
          cpuManagerPolicy:
    		El valor debe ser none o static none Este ajuste controla la política del gestor de CPU de kubelet. El valor predeterminado es none, que es el esquema de afinidad de CPU predeterminado. No proporciona ninguna afinidad más allá de lo que el programador del SO hace automáticamente.

    Si se asigna el valor static, los pods que estén en la clase de QoS Guaranteed y tengan solicitudes de CPU de números enteros podrán tener CPUs exclusivas.    		 
          memoryManager:
        policy:
    		El valor debe ser None o Static None

    Este ajuste controla la política del gestor de memoria de kubelet. Con el valor predeterminado None, Kubernetes se comporta como si no estuviera presente el gestor de memoria. Para obtener más información, consulta la política None.

    Si asignas el valor Static, la política de Gestor de memoria envía sugerencias de topología que dependen del tipo de pod. Para obtener más información, consulta Política estática.

    Este ajuste se puede aplicar a clústeres con el plano de control que ejecute la versión 1.32.3-gke.1785000 o posterior de GKE.

    		 
          topologyManager:
        policy:
        scope:
    		El valor debe ser uno de los ajustes admitidos para cada uno de los campos correspondientes.
    • El valor predeterminado de topologyManager.policy es none.
    • El valor predeterminado de topologyManager.scope es container.

    Estos ajustes controlan la política del gestor de topología de kubelet, que coordina el conjunto de componentes responsables de las optimizaciones de rendimiento relacionadas con el aislamiento de la CPU, la memoria y la localidad del dispositivo.

    Puedes definir la política y la configuración del ámbito de forma independiente. Para obtener más información sobre estos ajustes, consulta Ámbitos y políticas del gestor de topología.

    Los siguientes recursos de GKE admiten este ajuste:

    • Clústeres con el plano de control que ejecutan la versión 1.32.3-gke.1785000 de GKE o una posterior. En los clústeres con el plano de control y los nodos que ejecutan la versión 1.33.0-gke.1712000 o una posterior, Topology Manager también recibe información sobre la topología de la GPU.
    • Nodos con los siguientes tipos de máquinas: A2, A3, A4, C3, C4, C4A, G2, M3 y N4

    En el ejemplo siguiente se muestra una configuración del sistema de nodos en la que se han configurado las tres políticas de Resource Manager:

    cpuManagerPolicy: static
memoryManager:
  policy: Static
topologyManager:
  policy: best-effort
  scope: pod

    Opciones de configuración de sysctl

    Para optimizar el rendimiento de tu sistema, puedes modificar los siguientes atributos del kernel:

    Para obtener más información sobre los valores admitidos de cada marca sysctl, consulta la documentación de la CLI de gcloud --system-config-from-file.

    Los distintos espacios de nombres de Linux pueden tener valores únicos para un sysctl determinado, mientras que otros son globales para todo el nodo. Si actualiza las opciones de sysctl mediante una configuración del sistema de nodos, se asegura de que sysctl se aplique de forma global en el nodo y en cada espacio de nombres, lo que hace que cada pod tenga valores de sysctl idénticos en cada espacio de nombres de Linux.

    Opciones de configuración del modo cgroup de Linux

    El kubelet y el tiempo de ejecución del contenedor usan cgroups del kernel de Linux para gestionar los recursos, como limitar la cantidad de CPU o memoria a la que puede acceder cada contenedor de un pod. Hay dos versiones del subsistema cgroup en el kernel: cgroupv1 y cgroupv2. La compatibilidad con Kubernetes para cgroupv2 se introdujo como alfa en la versión 1.18 de Kubernetes, como beta en la 1.22 y como GA en la 1.25. Para obtener más información, consulta la documentación de cgroups v2 de Kubernetes.

    La configuración del sistema de nodos te permite personalizar la configuración de cgroup de tus grupos de nodos. Puedes usar cgroupv1 o cgroupv2. GKE usa cgroupv2 para los grupos de nodos Standard nuevos que ejecutan la versión 1.26 y posteriores, y cgroupv1 para las versiones anteriores a la 1.26. En los grupos de nodos creados con el aprovisionamiento automático de nodos, la configuración de cgroup depende de la versión inicial del clúster, no de la versión del grupo de nodos. cgroupv1 no es compatible con máquinas Arm.

    Puedes usar la configuración del sistema de nodos para cambiar el ajuste de un grupo de nodos y usar cgroupv1 o cgroupv2 de forma explícita. Si actualizas un grupo de nodos a la versión 1.26, el ajuste no cambiará a cgroupv2, ya que los grupos de nodos creados con una versión anterior a la 1.26 (sin una configuración de cgroup personalizada) seguirán usando cgroupv1 a menos que especifiques lo contrario.

    Por ejemplo, para configurar tu grupo de nodos de forma que use cgroupv2, utiliza un archivo de configuración del sistema de nodos como el siguiente:

    linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

    Las opciones de cgroupMode admitidas son las siguientes:

    • CGROUP_MODE_V1: usa cgroupv1 en el grupo de nodos.
    • CGROUP_MODE_V2: usa cgroupv2 en el grupo de nodos.
    • CGROUP_MODE_UNSPECIFIED: usa la configuración predeterminada de cgroup de GKE.

    Para usar cgroupv2, se aplican los siguientes requisitos y limitaciones:

    • En el caso de los grupos de nodos que ejecuten una versión anterior a la 1.26, debes usar la versión 408.0.0 o una posterior de la interfaz de línea de comandos de gcloud. También puedes usar gcloud beta con la versión 395.0.0 o una posterior.
    • Tu clúster y tus grupos de nodos deben ejecutar la versión 1.24.2-gke.300 de GKE o una posterior.
    • Debes usar la imagen de nodo de Container-Optimized OS con containerd o Ubuntu con containerd.
    • Si alguna de tus cargas de trabajo depende de la lectura del sistema de archivos cgroup (/sys/fs/cgroup/...), asegúrate de que sea compatible con la API cgroupv2.
      • Asegúrate de que las herramientas de monitorización o de terceros sean compatibles con cgroupv2.
    • Si usas JDK (carga de trabajo de Java), te recomendamos que utilices versiones que admitan cgroupv2 por completo, como JDK 8u372, JDK 11.0.16 o versiones posteriores, o JDK 15 o versiones posteriores.

    Verificar la configuración de cgroup

    Cuando añades una configuración del sistema de nodos, GKE debe volver a crear los nodos para implementar los cambios. Una vez que hayas añadido la configuración a un pool de nodos y se hayan recreado los nodos, podrás verificar la nueva configuración.

    Puedes verificar la configuración de cgroup de los nodos de un grupo de nodos con la CLI de gcloud o la herramienta de línea de comandos kubectl:

    CLI de gcloud

    Comprueba la configuración de cgroup de un grupo de nodos:

    gcloud container node-pools describe POOL_NAME \
    --format='value(Config.effectiveCgroupMode)'

    Sustituye POOL_NAME por el nombre de tu grupo de nodos.

    El resultado potencial es uno de los siguientes:

    • EFFECTIVE_CGROUP_MODE_V1: los nodos usan cgroupv1
    • EFFECTIVE_CGROUP_MODE_V2: los nodos usan cgroupv2

    El resultado solo muestra la nueva configuración del cgroup después de que se hayan recreado los nodos del node pool. La salida está vacía en los grupos de nodos de Windows Server, que no admiten cgroup.

    kubectl

    Para verificar la configuración de cgroup de los nodos de este grupo de nodos con kubectl, selecciona un nodo y conéctate a él siguiendo estas instrucciones:

    1. Crea un shell interactivo con cualquier nodo del grupo de nodos. Sustituye mynode en el comando por el nombre de cualquier nodo del grupo de nodos.
    2. Identifica la versión de cgroup en los nodos de Linux.

    Opciones de configuración de páginas enormes de Linux

    Puedes usar el archivo de configuración del sistema de nodos para usar la función páginas enormes del kernel de Linux.

    Kubernetes admite páginas enormes en los nodos como un tipo de recurso, de forma similar a la CPU o la memoria. Usa los siguientes parámetros para indicar a tus nodos de Kubernetes que preasignen páginas enormes para que las usen los pods. Para gestionar el consumo de páginas enormes de tus pods, consulta Gestionar páginas enormes.

    Para preasignar páginas enormes a tus nodos, especifica las cantidades y los tamaños. Por ejemplo, para configurar los nodos de forma que asignen tres páginas enormes de 1 GB y 1024 páginas enormes de 2 MB, utiliza una configuración del sistema de nodos como la siguiente:

    linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

    Para usar páginas enormes, se aplican las siguientes limitaciones y requisitos:

    • Para asegurarse de que el nodo no esté ocupado por completo por páginas enormes, el tamaño total de las páginas enormes asignadas no puede superar el 60% de la memoria total de las máquinas con menos de 30 GB de memoria, ni el 80% en las máquinas con más de 30 GB de memoria. Por ejemplo, en una máquina e2-standard-2 con 8 GB de memoria, no puedes asignar más de 4,8 GB a páginas enormes. En c4a-standard-8 con 32 GB de memoria, las páginas enormes no pueden superar los 25,6 GB.
    • Las páginas enormes de 1 GB solo están disponibles en los tipos de máquinas A3, C2D, C3, C3D, C4, C4A, C4D, CT5E, CT5LP, CT6E, H3, M2, M3, M4 o Z3.

    Compatibilidad con páginas enormes transparentes

    Puedes usar el archivo de configuración del sistema de nodos para habilitar la función del kernel de Linux Transparent HugePage Support. La compatibilidad con páginas enormes transparentes (THP) es una solución alternativa a las páginas enormes estáticas. Con THP, el kernel asigna automáticamente páginas enormes a los procesos, por lo que no es necesario reservar páginas enormes manualmente. Se admiten los siguientes campos:

    linuxConfig:
  transparentHugepageEnabled: TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS
  transparentHugepageDefrag: TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS

    • transparentHugepageEnabled controla la compatibilidad con páginas enormes transparentes para la memoria anónima. Los valores admitidos son los siguientes:

      • TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: las páginas enormes transparentes están habilitadas en todo el sistema.
      • TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: las páginas enormes transparentes están habilitadas en las regiones de MADV_HUGEPAGE. Esta es la configuración predeterminada del kernel.
      • TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Transparent hugepage está inhabilitado.
      • TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: valor predeterminado. GKE no modifica la configuración del kernel.

    • transparentHugepageDefrag define la configuración de desfragmentación de páginas enormes transparentes en el nodo. Los valores admitidos son los siguientes:

      • TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: una aplicación que solicita THP se bloquea si no se puede asignar y reclama directamente páginas y comprime la memoria para asignar un THP inmediatamente.
      • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: una aplicación activa kswapd en segundo plano para reclamar páginas y activa kcompactd para compactar la memoria, de modo que THP esté disponible en un futuro próximo. Es responsabilidad de khugepaged instalar las páginas THP más adelante.
      • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: una aplicación entra en la recuperación directa y la compactación como siempre, pero solo para las regiones que han usado madvise(MADV_HUGEPAGE). Todas las demás regiones activan kswapd en segundo plano para recuperar páginas y activan kcompactd para compactar la memoria, de modo que THP esté disponible en un futuro próximo.
      • TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: una aplicación entra en la recuperación directa y la compactación como siempre, pero solo para las regiones que han usado madvise(MADV_HUGEPAGE). Todas las demás regiones activan kswapd en segundo plano para recuperar páginas y activan kcompactd para compactar la memoria, de modo que THP esté disponible en un futuro próximo.
      • TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: una aplicación nunca entra en la reclamación directa ni en la compactación.
      • TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: valor predeterminado. GKE no modifica la configuración del kernel.

    THP está disponible en GKE 1.33.2-gke.4655000 o versiones posteriores. También está habilitado de forma predeterminada en los nuevos grupos de nodos de TPU en la versión 1.33.2-gke.4655000 de GKE o posterior. THP no se habilita cuando actualizas los grupos de nodos a una versión compatible o posterior.

    Siguientes pasos