Personaliza la configuración del sistema de nodos

En este documento, se muestra cómo personalizar la configuración de tu nodo de Google Kubernetes Engine (GKE) mediante un archivo de configuración denominado configuración del sistema de nodos.

Descripción general

Puedes personalizar la configuración de tu nodo mediante varios métodos. Por ejemplo, puedes especificar parámetros como el tipo de máquina y la plataforma de CPU mínima cuando creas un grupo de nodos.

La configuración del sistema de nodos es un archivo de configuración que proporciona una manera de ajustar un conjunto limitado de opciones de configuración del sistema. Puedes usar una configuración del sistema de nodos a fin de especificar opciones de configuración personalizadas para el agente del nodo de Kubernetes (kubelet) y opciones de configuración del kernel de Linux de nivel bajo ( sysctl) en tus grupos de nodos.

También puedes personalizar el entorno de ejecución de contenedores de containerd en tus nodos de GKE con un archivo diferente llamado archivo de configuración del entorno de ejecución. Para obtener instrucciones, consulta Cómo personalizar la configuración de containerd en nodos de GKE.

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

Usa una configuración de 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 Standard. Usas un archivo YAML que contiene los parámetros de configuración del kernel de kubelet y Linux. En los pasos de esta página, se muestra cómo crear y usar un archivo de configuración.
  • ComputeClass: Disponible en el modo Autopilot y el modo estándar. Especificas la configuración del sistema de nodos en la especificación de ComputeClass de GKE. Las clases de procesamiento te permiten definir conjuntos de atributos de nodos para que GKE los use cuando aumente la escala de tu clúster. Disponible en la versión 1.32.1-gke.1729000 y versiones posteriores de GKE. Para obtener más información, consulta Acerca de las clases de procesamiento 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 tus configuraciones de kubelet y sysctl.
  2. Agrega la configuración cuando crees o actualices un grupo de nodos.

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.

Crea un archivo de configuración

Escribe el archivo de configuración de tu sistema de nodos en YAML. En el siguiente ejemplo, se muestra cómo agregar configuraciones para las opciones de 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 kubelet para usar la política de administración de CPU estáticas.
  • net.core.somaxconn: '2048' limita las tareas pendientes socket listen() a 2,048 bytes.
  • net.ipv4.tcp_rmem: '4096 87380 6291456' establece el valor mínimo, predeterminado y máximo del buffer de recepción de sockets de TCP a 4,096 bytes, 87,380 bytes y 6,291,456 bytes, respectivamente.

Si deseas agregar parámetros de configuración solo para kubelet o sysctl, incluye solo esa sección en tu archivo de configuración. Por ejemplo, para agregar una configuración de kubelet, crea el siguiente archivo:

kubeletConfig:
  cpuManagerPolicy: static

Para obtener una lista completa de los campos que puedes agregar a tu archivo de configuración, consulta las secciones Opciones de configuración de Kubelet y Opciones de configuración de Sysctl.

Agrega la configuración a un grupo de nodos

Después de crear el archivo de configuración, agrega la marca --system-config-from-file mediante Google Cloud CLI.

Puedes usar gcloud CLI o Terraform para aplicar una configuración del sistema de nodos cuando creas un clúster estándar nuevo o un grupo de nodos nuevo. Si aplicas la configuración durante la creación del clúster, GKE la aplica al grupo de nodos predeterminado del clúster. También puedes actualizar la configuración del sistema de nodos de un grupo de nodos existente. No puedes agregar una configuración de sistema de nodo con la consola de Google Cloud .

Crea un grupo de nodos nuevo con la configuración del sistema de nodos

En las siguientes instrucciones, se aplica la configuración del sistema de nodos a un grupo de nodos nuevo:

gcloud CLI 

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 de tu grupo de nodos
  • CLUSTER_NAME: Es el nombre del clúster al que deseas agregar un grupo de nodos.
  • LOCATION: la zona o región de procesamiento del clúster.
  • SYSTEM_CONFIG_PATH: La ruta de acceso al archivo que contiene tus configuraciones de kubelet y sysctl

Terraform

Para crear un grupo de nodos con una configuración del sistema de nodos personalizada con 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"
      }
    }
  }
}

Si deseas obtener más información para usar Terraform, consulta Compatibilidad con Terraform para GKE.

Actualiza la configuración del sistema de nodos de un grupo de nodos existente

Ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

  • POOL_NAME: El nombre del grupo de nodos que quieres actualizar
  • CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.
  • LOCATION: la zona o región de procesamiento del clúster.
  • SYSTEM_CONFIG_PATH: La ruta de acceso al archivo que contiene tus configuraciones de kubelet y sysctl

Este cambio requiere volver a crear los nodos, lo que puede causar interrupciones en tus cargas de trabajo en ejecución. Para obtener detalles sobre este cambio específico, busca la fila correspondiente en la tabla Cambios manuales que recrean los nodos con 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 Planifica las interrupciones de las actualizaciones de nodos.

Edita una configuración del sistema de nodos

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

Edita mediante la creación de un grupo de nodos

Para editar una configuración del sistema de nodos mediante la creación de un grupo de nodos, haz lo siguiente:

  1. Crea un archivo de configuración con la configuración que desees.
  2. Agrega la configuración a un grupo de nodos nuevo.
  3. Migra tus cargas de trabajo al grupo de nodos nuevo.
  4. Borra el grupo de nodos anterior.

Edita mediante la actualización de un grupo de nodos existente

Para editar la configuración del sistema de nodos de un grupo de nodos existente, sigue las instrucciones de la pestaña Actualizar grupo de nodos para agregar la configuración a un grupo de nodos. La actualización de una configuración del sistema de nodos anula la configuración del sistema del grupo de nodos con la nueva configuración, lo que requiere volver a crear los nodos. Si omites algún parámetro durante una actualización, se configurará con los respectivos valores predeterminados.

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

kubeletConfig: {}
linuxConfig:
  sysctl: {}

Borra una configuración del sistema de nodos

Para quitar una configuración del sistema de nodos, haz lo siguiente:

  1. Crea un grupo de nodos.
  2. Migra tus cargas de trabajo al grupo de nodos nuevo.
  3. Borra el grupo de nodos que tiene 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.

Opciones de configuración de Kubelet Restricciones Parámetro de configuración predeterminado Descripción
allowedUnsafeSysctls Es una lista de nombres o grupos de sysctl. Grupos de sysctl permitidos: kernel.shm*, kernel.msg*, kernel.sem, fs.mqueue.* y net.*. Ejemplo: [kernel.msg*, net.ipv4.route.min_pmtu]. none Este parámetro de configuración define una lista de entidades permitidas separada por comas de nombres o grupos de sysctl no seguros, que se pueden establecer en los Pods.sysctl

Disponible en las versiones 1.32.0-gke.1448000 y posteriores de GKE.
containerLogMaxSize El valor debe ser un número positivo y un sufijo de unidad entre 10Mi y 500Mi, inclusive. Las unidades válidas son Ki, Mi, Gi. 10Mi Este parámetro de configuración controla el parámetro de configuración containerLogMaxSize de la política de rotación del registro de contenedores, que te 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, incluidos ambos. 5 Este parámetro de configuración controla el parámetro de configuración containerLogMaxFiles de la política de rotación de archivos de registro de contenedores, que te permite configurar la cantidad máxima de archivos permitidos para cada contenedor, respectivamente. El valor predeterminado es 5. El tamaño total del registro (container_log_max_size*container_log_max_files) por contenedor no puede exceder el 1% del almacenamiento total del nodo.
cpuCFSQuota El valor debe ser true o false true Esta configuración aplica el límite de CPU del Pod. Establecer este valor en false significa que se ignoran los límites de CPU para Pods.

Omitir los límites de CPU puede ser conveniente en ciertas situaciones en las que los Pods son sensibles a los límites de CPU. El riesgo de inhabilitar cpuCFSQuota es que un Pod fuera de control puede consumir más recursos de CPU de lo previsto.
cpuCFSQuotaPeriod El valor debe ser una duración de tiempo entre 1 ms y 1 s, inclusive. "100ms" Mediante esta opción de configuración, se establece el valor del período de la cuota de CFS de CPU, cpu.cfs_period_us, que especifica el período de con qué frecuencia se debe reasignar el acceso de un cgroup a los recursos de CPU. Esta opción te permite ajustar el comportamiento de limitación de CPU.
imageGcLowThresholdPercent El valor debe ser un número entero entre 10 y 85 (ambos incluidos) y menor que imageGcHighThresholdPercent. 80 Este parámetro de configuración define el porcentaje de uso del disco antes del cual nunca se ejecuta la recolección de elementos no utilizados de imágenes. Es el uso de disco más bajo para el que se realizará la recolección de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo por 100. Cuando 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 mayor que imageGcLowThresholdPercent. 85 Este parámetro de configuración define el porcentaje de uso del disco por encima del cual se ejecuta la recolección de elementos no utilizados de imágenes. Es el uso de disco más alto para la recolección de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo por 100. Cuando se especifica, el valor debe ser mayor que imageGcLowThresholdPercent.
imageMinimumGcAge El valor debe ser una duración que no supere los "2 min". 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 recolecte como elemento no utilizado.
imageMaximumGcAge El valor debe ser una duración de tiempo 0s imageMaximumGcAge es la antigüedad máxima que puede tener una imagen sin usar antes de que se recolecten los elementos no utilizados. El valor predeterminado de este campo es "0 s", lo que lo inhabilita. Es decir, las imágenes no se recolectarán como elementos no utilizados por no haberse usado durante demasiado tiempo. Cuando se especifica, el valor debe ser mayor que 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 parámetro de configuración inhabilita el puerto de solo lectura de kubelet no seguro 10255 en cada grupo de nodos nuevo de tu clúster. Si estableces esta configuración en este archivo, no puedes usar un cliente de API de GKE para cambiar la configuración a nivel de clúster.
podPidsLimit El valor debe ser entre 1024 y 4194304 none Esta configuración establece la cantidad máxima de ID de procesos (PID) que puede usar cada Pod.
maxParallelImagePulls El valor debe ser un número entero entre 2 y 5, inclusive 2 o 3 según el tipo de disco Este parámetro de configuración define la cantidad máxima de extracciones de imágenes en paralelo. El valor predeterminado se decide según el tipo de disco de arranque:

  • 3 predeterminado: pd-balanced, pd-ssd o existe una SSD local efímera.
  • 2 predeterminado: pd-standard o cualquier otro tipo de disco de arranque.

    • Disponible en las versiones 1.33.1-gke.1918000 y posteriores de GKE.
    evictionSoft Es un mapa de nombres de indicadores. Para conocer las restricciones de valores, consulta la siguiente tabla. none Este parámetro de configuración asigna nombres de indicadores a cantidades o porcentajes que definen los umbrales de descarte flexible. Un umbral de desalojo flexible debe tener un período de gracia. Kubelet no expulsa los Pods hasta que se supera el período de gracia.
    evictionSoftGracePeriod Mapa de nombres de señales, que tiene las mismas opciones que evictionSoft con diferentes restricciones. Para cada nombre de indicador, 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 parámetro de configuración asigna nombres de indicadores a duraciones que definen períodos de gracia para los umbrales de expulsión flexible. Cada umbral de desalojo temporal debe tener un período de gracia correspondiente.
    evictionMinimumReclaim Mapa de nombres de señales, que tiene las mismas opciones que evictionSoft con diferentes restricciones. Para cada nombre de indicador, el valor debe ser un porcentaje positivo inferior a 10%, por ejemplo, 5%. none Este parámetro de configuración asigna nombres de indicadores a porcentajes que definen la cantidad mínima de un recurso determinado que recupera kubelet cuando realiza un desalojo de Pod.
    evictionMaxPodGracePeriodSeconds El valor debe ser un número entero entre 0 y 300. 0 Este parámetro de configuración define, en segundos, el período de gracia máximo para la finalización del Pod durante el desalojo.

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

    Opciones de configuración de Kubelet Restricciones Parámetro de configuración predeterminado Descripción
    memoryAvailable El valor debe ser una cantidad mayor que 100Mi y menor que 50% de la memoria del nodo. Por ejemplo: 100Mi, 1Gi. none Representa la cantidad de memoria disponible antes del descarte temporal. Define la cantidad del indicador memory.available en el kubelet.
    nodefsAvailable El valor debe estar entre 10% y 50%. none Representa los nodefs disponibles antes del desalojo temporal. Define la cantidad del indicador nodefs.available en el kubelet.
    nodefsInodesFree El valor debe estar entre 5% y 50%. none Representa los nodos inode de nodefs que están libres antes del desalojo no definitivo. Define la cantidad del indicador nodefs.inodesFree en el kubelet.
    imagefsAvailable El valor debe estar entre 15% y 50%. none Representa el sistema de archivos de imagen disponible antes del desalojo temporal. Define la cantidad de indicador imagefs.available en el kubelet.
    imagefsInodesFree El valor debe estar entre 5% y 50%. none Representa los nodos i de imagefs que están libres antes del descarte temporal. Define la cantidad del indicador imagefs.inodesFree en el kubelet.
    pidAvailable El valor debe estar entre 10% y 50%. none Representa los PIDs disponibles antes del descarte temporal. Define la cantidad del indicador pid.available en el kubelet.
    singleProcessOOMKill El valor debe ser true o false true para nodos de cgroupv1 y false para nodos de cgroupv2 Este parámetro de configuración establece si los procesos del contenedor se cierran de forma individual o como grupo por falta de memoria.

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

    Administradores de recursos

    Kubernetes ofrece un conjunto de administradores de recursos. Puedes configurar estos administradores de recursos para coordinar y optimizar la alineación de los recursos del nodo para los Pods configurados con requisitos específicos para los recursos de CPU, dispositivos y memoria (hugepages). Para obtener más información, consulta Administradores de recursos de nodos.

    Con GKE, puedes configurar los siguientes parámetros para estos administradores de recursos. Puedes configurar estos parámetros de forma independiente, pero te recomendamos que los uses juntos para alinear la administración de recursos. Puedes usar la configuración de Topology Manager junto con la configuración de CPU Manager y Memory Manager para alinear la CPU y la memoria con otros recursos solicitados en la especificación del Pod.

    Opciones de configuración de Kubelet Restricciones Parámetro de configuración predeterminado Descripción 
          cpuManagerPolicy:
    		El valor debe ser none o static none Este parámetro de configuración controla la política del administrador de CPU de kubelet. El valor predeterminado es none, que es el esquema de afinidad de CPU predeterminado, que no proporciona afinidad más allá de lo que el programador de SO proporciona automáticamente.

    Establecer este valor en static permite que a los Pods que se encuentran en la clase de QoS Guaranteed y tienen solicitudes de CPU de número entero se les asignen CPU exclusivas.    		 
          memoryManager:
        policy:
    		El valor debe ser None o Static None

    Este parámetro de configuración controla la política del administrador de memoria de kubelet. Con el valor predeterminado de None, Kubernetes actúa como si el Administrador de memoria no estuviera presente. Para obtener más información, consulta la política de None.

    Si estableces este valor en Static, la política del Administrador de memoria envía sugerencias de topología que dependen del tipo de Pod. Para obtener más información, consulta la Política de contenido estático.

    Este parámetro de configuración es compatible con los clústeres cuyo plano de control ejecuta la versión 1.32.3-gke.1785000 o posterior de GKE.

    		 
          topologyManager:
        policy:
        scope:
    		El valor debe ser uno de los parámetros de configuración admitidos para cada uno de los campos respectivos.
    • El valor predeterminado de topologyManager.policy es none.
    • El valor predeterminado de topologyManager.scope es container.

    Estos parámetros de configuración controlan la política del Administrador de topología de kubelet, que coordina el conjunto de componentes responsables de las optimizaciones del rendimiento relacionadas con el aislamiento de la CPU, la memoria y la localidad del dispositivo.

    Puedes establecer la política y la configuración del alcance de forma independiente. Para obtener más información sobre estos parámetros de configuración, consulta Alcances y políticas del administrador de topología.

    Los siguientes recursos de GKE admiten este parámetro de configuración:

    • Clústeres con el plano de control que ejecuta la versión 1.32.3-gke.1785000 de GKE o una posterior En el caso de los clústeres con el plano de control y los nodos que ejecutan la versión 1.33.0-gke.1712000 o posterior, el Administrador de topología 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 siguiente ejemplo, se muestra una configuración del sistema de nodos en la que se configuran 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 ajustar el rendimiento de tu sistema, puedes modificar los siguientes atributos del kernel:

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

    Los diferentes espacios de nombres de Linux pueden tener valores únicos para un sysctl determinado, mientras que otros son globales para todo el nodo. La actualización de las opciones de sysctl mediante una configuración del sistema de nodos garantiza 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

    kubelet y el entorno de ejecución del contenedor usan 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.

    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 el caso de 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 a fin de cambiar la configuración para que un grupo de nodos use cgroupv1 o cgroupv2 de manera explícita. Actualizar un grupo de nodos existente a la versión 1.26 no cambia el parámetro de configuración a cgroupv2, ya que los grupos de nodos existentes creados con una versión anterior a la 1.26 (sin una configuración de cgroup personalizada) siguen usando cgroupv1, a menos que especifiques lo contrario de forma explícita.

    Por ejemplo, para configurar tu grupo de nodos a fin de usar cgroupv2, usa un archivo de configuración del sistema de nodos, como el siguiente:

    linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

    Las opciones de cgroupMode compatibles 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:

    • Para un grupo de nodos que ejecuta una versión anterior a la 1.26, debes usar la versión de gcloud CLI 408.0.0 o posterior. Como alternativa, usa gcloud beta con la versión 395.0.0 o posterior.
    • Tu clúster y los grupos de nodos deben ejecutar la versión 1.24.2-gke.300 o posterior de GKE.
    • 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 de cgroup (/sys/fs/cgroup/...), asegúrate de que sean compatibles con la API de cgroupv2.
      • Asegúrate de que las herramientas de supervisión o de terceros sean compatibles con cgroupv2.
    • Si usas JDK (carga de trabajo de Java), te recomendamos que uses versiones que admiten por completo cgroupv2, lo que incluye JDK 8u372, JDK 11.0.16 o posterior, o JDK 15 o una versión posterior.

    Verifica la configuración de cgroup

    Cuando agregas una configuración del sistema de nodos, GKE debe volver a crear los nodos para implementar los cambios. Después de agregar la configuración a un grupo de nodos y volver a crear los nodos, puedes verificar la configuración nueva.

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

    gcloud CLI

    Verifica la configuración de cgroup para un grupo de nodos:

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

    Reemplaza POOL_NAME por el nombre de tu grupo de nodos.

    El posible resultado 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 vuelvan a crear los nodos del grupo de nodos. El resultado está vacío para los grupos de nodos de Windows Server, que no admiten cgroup.

    kubectl

    A fin de verificar la configuración de cgroup para nodos en este grupo de nodos con kubectl, elige un nodo y conéctate a él mediante las siguientes instrucciones:

    1. Crea una shell interactiva con cualquier nodo del grupo de nodos. Reemplaza mynode en el comando por el nombre de cualquier nodo en el grupo de nodos.
    2. Identifica la versión de cgroup en nodos de Linux.

    Opciones de configuración de página enorme de Linux

    Puedes usar el archivo de configuración del sistema de nodos para usar las hugepages de la función del kernel de Linux.

    Kubernetes admite páginas grandes en los nodos como un tipo de recurso, similar a la CPU o la memoria. Usa los siguientes parámetros a fin de indicar a tus nodos de Kubernetes que asignen previamente páginas enormes para el consumo por parte de los Pods. Para administrar el consumo de páginas enormes de tus pods, consulta Administra HugePages.

    Para asignar previamente páginas enormes a tus nodos, especifica las cantidades y los tamaños. Por ejemplo, a fin de configurar tus nodos para asignar tres páginas enormes de 1 gigabyte y páginas enormes de 1,024 megabytes, usa una configuración del sistema de nodos como la que se muestra a continuación:

    linuxConfig:
  hugepageConfig:
    hugepage_size2m: 1024
    hugepage_size1g: 3

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

    • Para garantizar que el nodo no esté ocupado por completo por páginas enormes, el tamaño general de las páginas grandes asignadas no puede exceder el 60% de la memoria total en máquinas con menos de 30 GB de memoria y el 80% en 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 para páginas enormes. Y 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 HugePages 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 HugePages transparentes (THP) es una solución alternativa a las HugePages estáticas. Con THP, el kernel asigna automáticamente páginas grandes a los procesos, por lo que no es necesario reservar páginas grandes de forma manual. Se admiten los siguientes campos:

    linuxConfig:
  transparentHugepageEnabled: TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS
  transparentHugepageDefrag: TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS

    • transparentHugepageEnabled controla la compatibilidad con páginas grandes 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 dentro de las regiones de MADV_HUGEPAGE. Esta es la configuración predeterminada del kernel.
      • TRANSPARENT_HUGEPAGE_ENABLED_NEVER: Las páginas enormes transparentes están inhabilitadas.
      • 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 detiene si falla la asignación y reclama directamente páginas y compacta la memoria en un intento por asignar una THP de inmediato.
      • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: Una aplicación activa kswapd en segundo plano para recuperar páginas y activa kcompactd para compactar la memoria, de modo que THP esté disponible en el futuro cercano. Luego, khugepaged es responsable de instalar las páginas de THP.
      • TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: Una aplicación ingresa en la recuperación y compactación directas como siempre, pero solo para las regiones que usaron 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 el futuro cercano.
      • TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: Una aplicación ingresa en la recuperación y compactación directas como siempre, pero solo para las regiones que usaron 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 el futuro cercano.
      • TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: Una aplicación nunca ingresa en la recuperación o compactación directa.
      • TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: valor predeterminado. GKE no modifica la configuración del kernel.

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

    ¿Qué sigue?