Personalizar la configuración del sistema de nodos

Estándar

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.

Una configuración del sistema de nodos es un archivo de configuración que permite ajustar un conjunto limitado de ajustes del sistema. En tu grupo de nodos, puedes usar una configuración del sistema de nodos para especificar ajustes personalizados para el agente de nodos de Kubernetes kubelet y para las configuraciones de kernel de Linux de bajo nivel sysctl.

Precaución: Si cambias los ajustes de kubelet o sysctl, puede que se produzcan comportamientos no deseados que afecten negativamente al estado de tus cargas de trabajo y nodos. Prueba exhaustivamente cualquier cambio en kubelet o sysctl antes de implementarlo en cargas de trabajo de producción.

En este documento se detallan las configuraciones disponibles para un sistema de nodos y cómo aplicarlas a tus grupos de nodos Estándar de GKE. Ten en cuenta que, como los clústeres de Autopilot de GKE tienen un entorno de nodos más gestionado, sus opciones de configuración directa del sistema de nodos son limitadas en comparación con los grupos de nodos de GKE Standard.

Por qué usar configuraciones del sistema de nodos

Las configuraciones del sistema de nodos ofrecen las siguientes ventajas:

• Ajuste del rendimiento: optimiza el rendimiento de la pila de red, la gestión de la memoria, la programación de la CPU o el comportamiento de E/S para aplicaciones exigentes, como el entrenamiento o el servicio de IA, las bases de datos, los servidores web con mucho tráfico o los servicios sensibles a la latencia.
• Refuerzo de la seguridad: aplica ajustes de seguridad específicos a nivel del kernel o restringe determinados comportamientos del sistema para reducir la superficie de ataque.
• Gestión de recursos: ajusta cómo gestiona kubelet los PIDs, el espacio en disco, la recogida de elementos no utilizados de imágenes o los recursos de CPU y memoria.
• Compatibilidad de las cargas de trabajo: ayuda a asegurar que el entorno de los nodos cumpla los requisitos previos específicos de software especializado o aplicaciones antiguas que requieran ajustes de kernel concretos.

Otras opciones para personalizar las configuraciones de los nodos

También puedes personalizar la configuración de tu nodo con otros métodos:

• Archivo de configuración del tiempo de ejecución: para personalizar un tiempo de ejecución de contenedores de containerd en tus nodos de GKE, puedes usar otro archivo llamado archivo de configuración del tiempo de ejecución. Para obtener más información, consulta Personalizar la configuración de containerd en nodos de GKE.
• ComputeClass puedes especificar atributos de nodo en tu especificación de ComputeClass de GKE. Puedes usar ComputeClasses tanto en el modo Autopilot como en el modo Estándar de GKE, en la versión 1.32.1-gke.1729000 de GKE y versiones posteriores. Para obtener más información, consulta Personalizar la configuración del sistema de nodos.
• DaemonSets también puedes usar DaemonSets para personalizar nodos. Para obtener más información, consulta Inicializar automáticamente nodos de GKE con DaemonSets.

Las configuraciones del sistema de nodos no se admiten en los nodos de Windows Server.

Antes de empezar

Antes de empezar, haz lo siguiente:

• Instala las herramientas de línea de comandos:
  • Si usas los ejemplos de la CLI gcloud de este documento, asegúrate de instalar y configurar la CLI gcloud.
  • Si usas los ejemplos de Terraform, asegúrate de instalar y configurar Terraform.
• Conceder permisos: necesitas los permisos de gestión de identidades y accesos adecuados para crear y actualizar clústeres y grupos de nodos de GKE, como container.clusterAdmin u otro rol con permisos equivalentes.
• Planifica posibles interrupciones de la carga de trabajo: las configuraciones de nodos personalizadas se aplican a nivel de grupo de nodos. Los cambios suelen activar una actualización gradual de los nodos del grupo, lo que implica volver a crear los nodos. Planifica posibles interrupciones de las cargas de trabajo y usa coberturas para interrupciones de pods (PDBs) cuando sea necesario.
• Crea una copia de seguridad y prueba todos los cambios: prueba siempre los cambios de configuración en un entorno de desarrollo o de pruebas antes de aplicarlos al entorno de producción. Si los ajustes son incorrectos, los nodos pueden volverse inestables o las cargas de trabajo pueden fallar.
• Revisa los ajustes predeterminados de GKE: las imágenes de nodos de GKE incluyen configuraciones predeterminadas optimizadas. Personaliza los parámetros solo si es estrictamente necesario y conoces el impacto de los cambios.

Usar una configuración del sistema de nodos en el modo GKE Standard

Cuando usas una configuración del sistema de nodos, utilizas un archivo YAML que contiene los parámetros de configuración de kubelet y del kernel de Linux. Aunque las configuraciones del sistema de nodos también están disponibles en el modo Autopilot de GKE, en este documento se explica cómo crear y usar un archivo de configuración para el modo Estándar de GKE.

Para usar una configuración del sistema de nodos en el modo estándar de GKE, 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 la configuración del sistema de nodos en YAML. En el ejemplo siguiente se añaden 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, se aplica lo siguiente:

• El campo cpuManagerPolicy: static configura el kubelet para que use la política de gestión de CPU estática. + El campo net.core.somaxconn: '2048' limita la socket listen() acumulación a 2048 bytes.
• El campo 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 solo esa sección en la configuración del sistema de nodos. 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 a la configuración de tu sistema de nodos, 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 estándar

Después de crear la configuración del sistema de nodos, añade la marca --system-config-from-file con la CLI 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 del sistema de nodos mediante 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 mediante 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

Después de aplicar 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.

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

Haz los cambios siguientes:

• 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

Para 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

Este cambio requiere 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.

Precaución: GKE empieza inmediatamente a volver a crear los nodos para este cambio mediante la estrategia de actualización de nodos, independientemente de las políticas de mantenimiento activas. GKE depende de la disponibilidad de recursos para el cambio. Desactivar las actualizaciones automáticas de nodos no impide este cambio.

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, siga 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 actualizando un grupo de nodos

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. Cuando actualizas la configuración de un sistema de nodos y la nueva configuración anula la configuración del sistema del grupo de nodos, los nodos deben volver a crearse. 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 en los campos 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, sigue estos pasos:

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 antigua.

Opciones de configuración de kubelet

En las tablas de esta sección se describen las opciones de kubelet que puedes modificar.

Gestión de la CPU

En la siguiente tabla se describen las opciones de gestión de la CPU de kubelet.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
cpuCFSQuota	Debe ser true o false.	true	Este ajuste aplica el límite de CPU de los pods. Si asignas el valor false, se ignorarán los límites de CPU de los pods. Ignorar los límites de CPU puede ser útil en determinados casos en los que los pods sean sensibles a estos límites. El riesgo de inhabilitar cpuCFSQuota es que un pod no autorizado puede consumir más recursos de CPU de lo previsto.
cpuCFSQuotaPeriod	Debe ser un periodo de tiempo.	"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 la limitación de la CPU.

Gestión de la memoria y desalojo

En la siguiente tabla se describen las opciones modificables para la gestión de la memoria y el desalojo. Esta sección también contiene una tabla independiente que describe las opciones modificables de la marca evictionSoft.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
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 una cantidad o un porcentaje que define los umbrales de desalojo suave. Un umbral de desalojo suave debe tener un periodo de gracia. El kubelet no expulsa los pods hasta que se supera el periodo de gracia.
evictionSoftGracePeriod	Mapa de nombres de señales. En cada nombre de señal, el valor debe ser una duración positiva inferior a 5m. Las unidades de tiempo válidas son ns, us (o µs), ms, s o m.	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. En cada nombre de señal, el valor debe ser un porcentaje positivo inferior a 10%.	none	Este ajuste 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 modificables de la marca evictionSoft. Las mismas opciones se aplican a las marcas evictionSoftGracePeriod y evictionMinimumReclaim, pero con diferentes restricciones.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
memoryAvailable	El valor debe ser una cantidad superior a 100Mi e inferior a 50% de la memoria del nodo.	none	Este ajuste 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	Este ajuste 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	Este ajuste 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	Este ajuste 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	Este ajuste 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 la kubelet.
pidAvailable	El valor debe estar entre 10% y 50%.	none	Este ajuste representa los PIDs disponibles antes de la expulsión suave. Define la cantidad de la señal pid.available en la 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.

Gestión de PIDs

En la siguiente tabla se describen las opciones modificables para la gestión de PIDs.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
podPidsLimit	El valor debe estar entre 1024 y 4194304.	none	Esta opción define el número máximo de IDs de proceso (PIDs) que puede usar cada pod.

Almacenamiento de registros

En la siguiente tabla se describen las opciones de registro que se pueden modificar.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
containerLogMaxSize	El valor debe ser un número positivo y un sufijo de unidad entre 10Mi y 500Mi, ambos incluidos.	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. Las unidades válidas son Ki, Mi y Gi.
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.

Recolección de elementos no utilizados de imágenes

En la siguiente tabla se describen las opciones modificables para la recogida de elementos no utilizados de imágenes.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
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. Representa el uso de disco más alto al que se debe aplicar la recogida de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo entre 100.
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. Representa el uso de disco más bajo para la recogida de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo entre 100.
imageMinimumGcAge	El valor debe ser una duración no superior a 2m. Las unidades de tiempo válidas son ns, us (o µs), ms, s, m o h.	2m	Este ajuste define la edad mínima de una imagen sin usar antes de que se recoja como elemento no utilizado.
imageMaximumGcAge	El valor debe ser una duración.	0s	Este ajuste define 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, que inhabilita el campo. Por lo tanto, las imágenes no se recogerán como elementos no utilizados. Cuando se especifica este valor, debe ser mayor que el valor del campo imageMinimumGcAge. Disponible en las versiones 1.30.7-gke.1076000, 1.31.3-gke.1023000 o posteriores de GKE.

Extracción de imágenes

En la siguiente tabla se describen las opciones modificables para extraer imágenes.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
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.

Seguridad y operaciones no seguras

En la siguiente tabla se describen las opciones que se pueden modificar para configurar la seguridad y gestionar las operaciones no seguras.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
allowedUnsafeSysctls	Lista de sysctl nombres o grupos. Los grupos de sysctl permitidos son los siguientes: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	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
insecureKubeletReadonlyPortEnabled	El valor debe ser un valor booleano, es decir, true o false.	true	Este ajuste inhabilita el puerto de solo lectura 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.

Administradores 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 que estén configurados con requisitos específicos de recursos de CPUs, dispositivos y memoria (páginas enormes).

En la siguiente tabla se describen las opciones modificables de los gestores de recursos.

kubelet ajustes de configuración	Restricciones	Ajuste predeterminado	Descripción
cpuManagerPolicy	El valor debe ser none o static.	none	Este ajuste controla la política de gestor de CPU de kubelet. El valor predeterminado es none, que es el esquema de afinidad de CPU predeterminado y no proporciona ninguna afinidad más allá de lo que hace automáticamente el programador del SO. 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 asignarse CPUs exclusivas.
memoryManager.policy	El valor debe ser None o Static.	None	Este ajuste controla la kubelet política Gestor de memoria. Con el valor predeterminado None, Kubernetes actúa como si no estuviera presente el gestor de memoria. Si asignas el valor Static, la política de Memory Manager 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	El valor debe ser uno de los ajustes admitidos para cada uno de los campos correspondientes. No puedes definir el campo topologyManager cuando usas las instrucciones de Terraform para añadir la configuración a un grupo de nodos estándar.	policy: none scope: container	Estos ajustes controlan la configuración de kubelet Topology Manager mediante los subcampos policy y scope. Topology Manager coordina el conjunto de componentes responsables de las optimizaciones de rendimiento relacionadas con el aislamiento de la CPU, la memoria y la localidad de los dispositivos. 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, G4, M3 y N4

Opciones de configuración de sysctl

Para optimizar el rendimiento de tu sistema, puedes modificar los parámetros del kernel de Linux. En las tablas de esta sección se describen los distintos parámetros del kernel que puede configurar.

Parámetros del sistema de archivos (fs.*)

En la siguiente tabla se describen los parámetros modificables del sistema de archivos de Linux. Estos ajustes controlan el comportamiento del sistema de archivos de Linux, como los límites de los controladores de archivos y la monitorización de eventos.

Parámetro Sysctl	Restricciones	Descripción
fs.aio-max-nr	Debe estar entre [65536, 4194304].	Este ajuste define el número máximo de solicitudes de E/S asíncronas en todo el sistema.
fs.file-max	Debe estar entre [104857 y 67108864].	Este ajuste define el número máximo de identificadores de archivos que puede asignar el kernel de Linux.
fs.inotify.max_user_instances	Debe estar entre [8192 y 1048576].	Este ajuste define el número máximo de instancias de inotify que puede crear un usuario.
fs.inotify.max_user_watches	Debe estar entre [8192 y 1048576].	Este ajuste define el número máximo de monitorizaciones inotify que puede crear un usuario.
fs.nr_open	Debe estar entre [1048576, 2147483584].	Este ajuste define el número máximo de descriptores de archivo que puede abrir un proceso.

Parámetros del kernel (kernel.*)

En la siguiente tabla se describen los parámetros modificables del kernel de Linux. Estos ajustes configuran las funciones principales del kernel, incluida la asignación de memoria compartida.

Parámetro sysctl	Restricciones	Descripción
kernel.shmmni	Debe estar entre [4096, 32768].	Este ajuste define el número máximo de segmentos de memoria compartida en todo el sistema. Si no se define este valor, se utiliza 4096 de forma predeterminada.
kernel.shmmax	Debe estar entre [0, 18446744073692774399].	Este ajuste define el tamaño máximo, en bytes, de un único segmento de memoria compartida permitido por el kernel. Este valor se ignora si es superior a la cantidad real de RAM, lo que significa que se puede compartir toda la RAM disponible.
kernel.shmall	Debe estar entre [0, 18446744073692774399].	Este ajuste define la cantidad total de páginas de memoria compartida que se pueden usar en el sistema al mismo tiempo. Una página tiene 4096 bytes en la arquitectura AMD64 e Intel 64.
kernel.perf_event_paranoid	Debe estar comprendido entre -1 y 3.	Este ajuste controla el uso del sistema de eventos de rendimiento por parte de usuarios sin privilegios que no tengan CAP_PERFMON. El valor predeterminado es 2 en el kernel.
kernel.sched_rt_runtime_us	Debe estar entre [-1, 1000000].	Este ajuste define un límite global sobre el tiempo que puede usar la programación en tiempo real.
kernel.softlockup_panic	Opcional (booleano).	Este ajuste controla si el kernel entra en pánico cuando se detecta un bloqueo suave.
kernel.yama.ptrace_scope	Debe estar entre [0, 3].	Este ajuste define el alcance y las restricciones de la llamada al sistema ptrace(), lo que afecta a la depuración y al seguimiento de procesos. Entre los valores admitidos se incluyen los siguientes: 0: permisos ptrace clásicos. 1: ptrace restringido, que es el valor predeterminado en muchas distribuciones. Solo procesos secundarios o CAP_SYS_PTRACE. 2: ptrace solo para administradores. Solo procesos con CAP_SYS_PTRACE. 3: no ptrace. No se permiten las llamadas ptrace.
kernel.kptr_restrict	Debe estar entre [0, 2].	Este ajuste indica si se aplican restricciones a la exposición de direcciones del kernel a través de /proc y otras interfaces.
kernel.dmesg_restrict	Opcional (booleano).	Este ajuste indica si se impide que los usuarios sin privilegios usen dmesg(8) para ver los mensajes del búfer de registro del kernel.
kernel.sysrq	Debe estar entre [0 y 511].	Este ajuste controla las funciones que se pueden invocar mediante la tecla SysRq. Entre los posibles valores se incluyen los siguientes: 0: inhabilita sysrq por completo. 1: habilita todas las funciones de sysrq. >1: máscara de bits de las funciones sysrq permitidas. Para obtener más información, consulta Combinaciones de teclas mágicas del sistema Linux.

Parámetros de red (net.*)

En la siguiente tabla se describen los parámetros de red que se pueden modificar. Estos ajustes modifican el rendimiento y el comportamiento de la pila de redes, desde los búferes de sockets hasta el seguimiento de conexiones.

Parámetro sysctl	Restricciones	Descripción
net.core.busy_poll	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tiempo de espera de sondeo ocupado con baja latencia para las funciones de sondeo y selección. Representa el tiempo aproximado en µs que se dedica a esperar eventos en un bucle ocupado.
net.core.busy_read	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tiempo de espera de sondeo ocupado con baja latencia para las lecturas de sockets. Representa el tiempo aproximado en µs que se tarda en esperar paquetes en bucle ocupado en la cola del dispositivo.
net.core.netdev_max_backlog	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el número máximo de paquetes en cola en el lado INPUT cuando la interfaz recibe paquetes más rápido de lo que el kernel puede procesarlos.
net.core.rmem_default	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tamaño predeterminado del búfer de socket de recepción, en bytes.
net.core.rmem_max	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tamaño máximo del búfer de socket de recepción, en bytes.
net.core.wmem_default	Cualquier número entero positivo menor que 2147483647.	Este ajuste define la configuración predeterminada, en bytes, del búfer de envío del socket.
net.core.wmem_max	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tamaño máximo del búfer de socket de envío, en bytes.
net.core.optmem_max	Cualquier número entero positivo menor que 2147483647.	Este ajuste define el tamaño máximo del búfer auxiliar permitido por socket.
net.core.somaxconn	Debe estar entre [128, 2147483647].	Este ajuste define el límite del backlog de socket listen(), que se conoce en el espacio de usuario como SOMAXCONN. El valor predeterminado de este ajuste es 128.
net.ipv4.tcp_rmem	{min, default, max} (cada valor debe ser > 0; memoria en bytes).	Este ajuste define el tamaño mínimo, en bytes, del búfer de recepción que usan los sockets UDP en la moderación. El ajuste predeterminado es 1 página.
net.ipv4.tcp_wmem	{min, default, max} (cada valor debe ser > 0; memoria en bytes).	Este ajuste define el tamaño mínimo, en bytes, del búfer de envío que usan los sockets UDP en la moderación. El ajuste predeterminado es 1 página.
net.ipv4.tcp_tw_reuse	Debe ser un valor entre 0 y 1.	Este ajuste define si se permite la reutilización de sockets en el estado TIME_WAIT para nuevas conexiones cuando sea seguro desde el punto de vista del protocolo. El valor predeterminado es 0.
net.ipv4.tcp_max_orphans	Debe estar entre [16384, 262144].	Este ajuste define el número máximo de sockets TCP que no están asociados a ningún identificador de archivo de usuario.
net.ipv4.tcp_max_tw_buckets	Debe ser un valor entre [4096, 2147483647].	Este ajuste define el número máximo de sockets de espera que puede tener el sistema simultáneamente. Si se supera este número, el socket de espera se destruye inmediatamente y se muestra una advertencia.
net.ipv4.tcp_syn_retries	Debe estar entre [1 y 127].	Este ajuste define el número de veces que se retransmite el SYN inicial de un intento de conexión TCP activo.
net.ipv4.tcp_ecn	Debe estar entre [0, 2].	Este ajuste controla el uso de la notificación explícita de congestión (ECN) por parte de TCP. ECN solo se usa cuando ambos extremos de la conexión TCP indican que es compatible.
net.ipv4.tcp_mtu_probing	Debe estar entre [0, 2].	Este ajuste controla el descubrimiento de MTU de la ruta de la capa de paquetización de TCP. Los valores admitidos son los siguientes: 0: inhabilitada. 1: inhabilitado de forma predeterminada y habilitado cuando se detecta un agujero negro ICMP. 2: siempre está habilitada. Usa el MSS inicial de tcp_base_mss.
net.ipv4.tcp_congestion_control	Debe ser uno de los valores admitidos de la columna Descripción.	Este ajuste no se admite cuando GKE Dataplane V2 está habilitado en el clúster. Los siguientes valores admitidos dependen del tipo de imagen: COS: reno, cubic, bbr, lp Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood y yeah
net.ipv6.conf.all.disable_ipv6	Booleano.	Cambiar este valor es lo mismo que cambiar el ajuste conf/default/disable_ipv6 y todos los ajustes disable_ipv6 por interfaz al mismo valor.
net.ipv6.conf.default.disable_ipv6	Booleano.	Este ajuste inhabilita el funcionamiento de IPv6.
net.netfilter.nf_conntrack_acct	Debe ser {0, 1}.	Este ajuste habilita el flujo de seguimiento de conexiones. El valor predeterminado es 0, lo que significa que el ajuste está inhabilitado. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_max	Debe estar entre [65536, 4194304].	Este ajuste define el tamaño de la tabla de seguimiento de conexiones. Si se alcanza el valor máximo, la nueva conexión fallará. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_buckets	Debe estar entre [65536 y 524288].	Este ajuste define el tamaño de la tabla hash. El ajuste recomendado es el resultado de lo siguiente: nf_conntrack_max = nf_conntrack_buckets * 4. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Debe estar entre [60 y 3600].	Este ajuste define el periodo, en segundos, durante el cual las conexiones TCP pueden permanecer en el estado CLOSE_WAIT. El valor predeterminado es 3600. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_tcp_timeout_established	Debe estar entre [600, 86400].	Este ajuste define la duración, en segundos, de las conexiones inactivas antes de que se eliminen automáticamente de la tabla de seguimiento de conexiones. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Debe estar comprendido entre 1 y 600.	Este ajuste define el periodo, en segundos, durante el cual las conexiones TCP pueden permanecer en el estado TIME_WAIT. El valor predeterminado es 120. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.

Parámetros de memoria virtual (vm.*)

En la siguiente tabla se describen los parámetros modificables del subsistema de memoria virtual. Estos ajustes gestionan el subsistema de memoria virtual, que controla cómo gestiona el kernel la memoria, el intercambio y el almacenamiento en caché del disco.

Parámetro sysctl	Restricciones	Descripción
vm.max_map_count	Debe ser un valor entre [65536, 2147483647].	Este archivo define el número máximo de áreas de asignación de memoria que puede tener un proceso.
vm.dirty_background_ratio	Debe ser un valor entre 1 y 100.	Este ajuste define el porcentaje de memoria del sistema que se puede llenar con páginas sucias antes de que los subprocesos de vaciado del kernel en segundo plano empiecen a escribir. El valor debe ser inferior al del campo vm.dirty_ratio.
vm.dirty_background_bytes	Debe estar entre [0, 68719476736].	Este ajuste define la cantidad de memoria sucia en la que los subprocesos de vaciado del kernel en segundo plano empiezan a escribir. Ten en cuenta que vm.dirty_background_bytes es la contraparte de vm.dirty_background_ratio. Solo se puede especificar uno de estos ajustes.
vm.dirty_expire_centisecs	Debe estar entre [0 y 6000].	Este ajuste define la antigüedad máxima, en centésimas de segundo, que pueden tener los datos sucios en la memoria antes de que los subprocesos de vaciado del kernel los escriban en el disco.
vm.dirty_ratio	Debe ser un valor entre 1 y 100.	Este ajuste define el porcentaje de memoria del sistema que se puede llenar con páginas sucias antes de que los procesos que realizan escrituras se vean obligados a bloquearse y escribir datos sucios de forma síncrona.
vm.dirty_bytes	Debe estar entre [0, 68719476736].	Este ajuste define la cantidad de memoria sucia en la que un proceso que genera escrituras en disco empieza a escribir en el disco. El valor mínimo permitido para vm.dirty_bytes es de dos páginas en bytes. Se ignorará cualquier valor inferior a este límite y se conservará la configuración anterior. Ten en cuenta que vm.dirty_bytes es la contraparte de vm.dirty_ratio. Solo se puede especificar uno de estos ajustes.
vm.dirty_writeback_centisecs	Debe estar entre [0, 1000].	Este ajuste define el intervalo, en centésimas de segundo, en el que los subprocesos de vaciado del kernel se activan para escribir datos antiguos en el disco.
vm.overcommit_memory	Debe ser un valor entre {0, 1, 2}.	Este ajuste determina la estrategia del kernel para gestionar la sobreasignación de memoria. Los valores son los siguientes: 0: rechazar asignaciones grandes 1: permitir siempre 2: impide que se confirme más allá de la memoria de intercambio + la proporción de RAM
vm.overcommit_ratio	Debe estar entre [0, 100].	Este ajuste define el porcentaje de RAM física que se puede sobreasignar cuando el valor del campo vm.overcommit_memory es 2.
vm.vfs_cache_pressure	Debe estar entre [0, 100].	Este ajuste modifica la preferencia del kernel para reclamar la memoria usada en las cachés de dentry (directorio) e inode.
vm.swappiness	Debe estar entre [0, 200].	Este ajuste controla la tendencia del kernel a mover procesos de la memoria física al disco de intercambio. El valor predeterminado es 60.
vm.watermark_scale_factor	Debe estar entre [10, 3000].	Este ajuste controla la agresividad de kswapd. Define la memoria que queda antes de que se active kswapd y la memoria que se debe liberar antes de que se suspenda. El valor predeterminado es 10.
vm.min_free_kbytes	Debe estar entre [67584 y 1048576].	Este ajuste define la memoria libre mínima antes de que se produzca un error de falta de memoria. El valor predeterminado es 67584.

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

Es posible que los distintos espacios de nombres de Linux tengan valores únicos para una marca sysctl determinada, pero otros pueden ser globales para todo el nodo. Actualizar las opciones de sysctl mediante un sistema de nodos ayuda a garantizar que sysctl se aplique de forma global en el nodo y en cada espacio de nombres, de modo 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

Precaución: GKE dejará de usar cgroupv1 en la versión secundaria 1.31 y eliminará la compatibilidad con cgroupv1 en la versión 1.35. Para obtener más información sobre cómo se está llevando a cabo la transición de GKE a cgroupv2 y cómo puedes preparar tus clústeres para esta transición, consulta el artículo Migrar nodos a Linux cgroupv2

.

El tiempo de ejecución del contenedor y kubelet 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 los grupos de nodos que ejecutan versiones anteriores a la 1.26. En los grupos de nodos que se crearon 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. Al actualizar un grupo de nodos que usa cgroupv1 a la versión 1.26, no se cambia el ajuste a cgroupv2. Los grupos de nodos que ejecuten una versión anterior a la 1.26 y que no incluyan una configuración de cgroup personalizada seguirán usando cgroupv1. Para cambiar el ajuste, debes especificar explícitamente cgroupv2 en el grupo de nodos.

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'

Estas son las opciones de cgroupMode admitidas:

• 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 gcloud CLI. 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 de 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 sean compatibles con la API cgroupv2.
• Si utilizas herramientas de monitorización o de terceros, asegúrate de que sean compatibles con cgroupv2.
• Si usas cargas de trabajo de Java (JDK), 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. Después de añadir la configuración a un grupo de nodos y de que se vuelvan a crear los nodos, puedes verificar la nueva configuración.

Puedes verificar la configuración de cgroup de los nodos de un grupo de nodos mediante 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

La salida solo muestra la nueva configuración de cgroup después de que se hayan vuelto a crear los nodos del grupo de nodos. La salida está vacía para los grupos de nodos de Windows Server, que no admiten cgroup.

kubectl

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

1. Crea un shell interactivo con cualquier nodo del grupo de nodos. En el comando, sustituye mynode por el nombre de cualquier nodo del grupo de nodos.
2. Identificar la versión de cgroup en nodos Linux

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

Puedes usar un archivo de configuración del sistema de nodos para preasignar páginas enormes. Kubernetes admite páginas enormes preasignadas como un tipo de recurso, de forma similar a la CPU o la memoria.

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

• Para asegurarte 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 ninguno de los siguientes valores:
  • En máquinas con menos de 30 GB de memoria: el 60% de la memoria total. Por ejemplo, en una máquina e2-standard-2 con 8 GB de memoria, no puedes asignar más de 4,8 GB a las páginas enormes.
  • En máquinas con más de 30 GB de memoria: el 80% de la memoria total. Por ejemplo, en las máquinas 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.

En la siguiente tabla se describen los ajustes modificables de las páginas enormes de Linux.

Parámetro de configuración	Restricciones	Valor predeterminado	Descripción
hugepage_size2m	Número entero. Sujeto a los límites de asignación de memoria descritos anteriormente.	0	Este ajuste preasigna un número específico de páginas enormes de 2 MB.
hugepage_size1g	Número entero. Sujeto a las limitaciones de memoria y de tipo de máquina descritas anteriormente.	0	Este ajuste preasigna un número específico de páginas enormes de 1 GB.

Páginas enormes transparentes (THP)

Puedes usar un archivo de configuración del sistema de nodos para habilitar la opción Transparent HugePage Support (Compatibilidad con páginas enormes transparentes) del kernel de Linux. Con THP, el kernel asigna automáticamente páginas enormes a los procesos sin necesidad de preasignación manual.

En la siguiente tabla se describen los parámetros modificables de THP.

Parámetro de configuración	Valores admitidos	Valor predeterminado	Descripción
transparentHugepageEnabled	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 opción es la configuración predeterminada del kernel. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: las páginas enormes transparentes están inhabilitadas. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: el valor predeterminado. GKE no modifica la configuración del kernel.	UNSPECIFIED	Este ajuste controla si THP está habilitado para la memoria anónima.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: una aplicación que solicita THP se bloquea si no se puede asignar y reclama directamente las páginas y la memoria compacta para intentar 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 fase de reclamación directa y compactación como de costumbre, pero solo para las regiones que han usado madvise(MADV_HUGEPAGE). En el resto de las regiones, kswapd se activa en segundo plano para recuperar páginas y kcompactd se activa 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 fase de reclamación directa y compactación como de costumbre, pero solo para las regiones que han usado madvise(MADV_HUGEPAGE). En el resto de las regiones, kswapd se activa en segundo plano para reclamar páginas y kcompactd se activa 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 recuperación directa ni en la compactación. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: el valor predeterminado. GKE no modifica la configuración del kernel.	UNSPECIFIED	Este ajuste define la configuración de desfragmentación de THP.

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 en versiones posteriores. THP no se habilita al actualizar los node pools a una versión compatible o posterior.

Siguientes pasos

• Obtén más información sobre los grupos de nodos.
• Consulta cómo crear grupos de nodos.