Personaliza la configuración del sistema de nodos

Estándar

En este documento, se muestra cómo personalizar la configuración de nodos de Google Kubernetes Engine (GKE) con un archivo de configuración llamado configuración del sistema 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 parámetros de configuración del sistema. En tu grupo de nodos, puedes usar una configuración del sistema de nodos para especificar opciones de configuración personalizadas para el agente del nodo de Kubernetes kubelet y para las opciones de configuración del kernel de Linux de nivel bajo sysctl.

Precaución: Si cambias la configuración de kubelet o sysctl, es posible que se produzca un comportamiento no deseado que podría afectar de manera negativa el estado de tus cargas de trabajo y tus nodos. Prueba exhaustivamente los cambios en kubelet o sysctl antes de implementarlos en las cargas de trabajo de producción.

En este documento, se detallan los parámetros de configuración disponibles para un sistema de nodos y cómo aplicarlos a tus grupos de nodos de GKE Standard. Ten en cuenta que, debido a que los clústeres de GKE Autopilot tienen un entorno de nodos más administrado, 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 parámetros de configuración del sistema de nodos

Los parámetros de configuración del sistema de nodos ofrecen los siguientes beneficios:

• Ajuste del rendimiento: Optimiza el rendimiento de la pila de red, la administración de la memoria, la programación de la CPU o el comportamiento de E/S para aplicaciones exigentes, como el entrenamiento o la entrega 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 parámetros de configuración de seguridad específicos a nivel del kernel o restringe ciertos comportamientos del sistema para reducir la superficie de ataque.
• Administración de recursos: Ajusta la forma en que kubelet administra los PID, el espacio en el disco, la recolección de elementos no utilizados de imágenes o los recursos de CPU y memoria.
• Compatibilidad de la carga de trabajo: Ayuda a garantizar que el entorno del nodo cumpla con los requisitos previos específicos para software especializado o aplicaciones más antiguas que requieren parámetros de configuración del kernel particulares.

Otras opciones para personalizar la configuración de los nodos

También puedes personalizar la configuración de tus nodos con otros métodos:

• Archivo de configuración del entorno de ejecución: Para personalizar un entorno de ejecución de contenedores de containerd en tus nodos de GKE, puedes usar un archivo diferente llamado archivo de configuración del entorno de ejecución. Para obtener más información, consulta Cómo personalizar la configuración de containerd en nodos de GKE.
• ComputeClass: Puedes especificar atributos de nodo en la 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 y versiones posteriores de GKE. Para obtener más información, consulta Cómo personalizar la configuración del sistema de nodos.
• DaemonSets: También puedes usar DaemonSets para personalizar nodos. Para obtener más información, consulta Inicia automáticamente los nodos de GKE con DaemonSets.

Los nodos de Windows Server no admiten la configuración del sistema de nodos.

Antes de comenzar

Antes de comenzar, asegúrate de hacer lo siguiente:

• Instala las herramientas de línea de comandos:
  • Si usas los ejemplos de gcloud CLI en este documento, asegúrate de instalar y configurar Google Cloud CLI.
  • Si usas los ejemplos de Terraform, asegúrate de instalar y configurar Terraform.
• Otorga permisos: Necesitas los permisos de IAM adecuados para crear y actualizar clústeres de GKE y grupos de nodos, como container.clusterAdmin o un rol diferente con permisos equivalentes.
• Planifica posibles interrupciones de la carga de trabajo: Las configuraciones de nodos personalizadas se aplican a nivel del grupo de nodos. Por lo general, los cambios activan una actualización progresiva de los nodos del grupo, lo que implica volver a crear los nodos. Planifica posibles interrupciones de la carga de trabajo y usa presupuestos de interrupción de Pods (PDB) cuando sea apropiado.
• Crea copias de seguridad y prueba todos los cambios: Siempre prueba los cambios de configuración en un entorno de desarrollo o de pruebas antes de aplicarlos a producción. La configuración incorrecta puede provocar inestabilidad en los nodos o fallas en las cargas de trabajo.
• Revisa la configuración predeterminada de GKE: Las imágenes de nodos de GKE incluyen configuraciones predeterminadas optimizadas. Personaliza los parámetros solo si tienes una necesidad específica y comprendes el impacto de tus cambios.

Agrega una configuración del sistema de nodos

Puedes personalizar la configuración del sistema de nodos con una ComputeClass o un archivo de configuración.

Usa una ComputeClass para la configuración del sistema de nodos

Puedes usar un ComputeClass personalizado para personalizar ciertos parámetros en kubelet y el kernel de Linux. Este método está disponible en GKE versión 1.32.1-gke.1729000 y versiones posteriores.

Para usar una ComputeClass y personalizar la configuración del sistema de nodos, haz lo siguiente:

1. Crea una ComputeClass que incluya el par de valor de campo spec.nodePoolAutoCreation.enabled: true y especifica los parámetros de configuración del sistema en el campo priorityDefaults.
2. Implementa una carga de trabajo que seleccione la ComputeClass.

Crea la ComputeClass

Escribe la configuración de ComputeClass en YAML. Usa el campo nodeSystemConfig dentro de la especificación priorityDefaults para establecer la configuración del sistema en todas las prioridades.

En el siguiente ejemplo, ComputeClass configura la política estática del administrador de CPU y los parámetros personalizados del kernel:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

Aplica la ComputeClass:

kubectl apply -f custom-sysconfig.yaml

Implementa una carga de trabajo que selecciona ComputeClass

En la especificación del Pod, agrega un selector de nodos para el nombre de ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

Aplica la carga de trabajo:

kubectl apply -f my-app.yaml

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

Usa un archivo de configuración para la configuración del sistema de nodos

Cuando usas un archivo de configuración del sistema de nodos, usas un archivo YAML que contiene los parámetros de configuración para kubelet y el kernel de Linux. Si bien las configuraciones del sistema de nodos también están disponibles en el modo GKE Autopilot, los pasos de este documento te muestran cómo crear y usar un archivo de configuración para el modo GKE Standard.

Para usar un archivo de configuración del sistema de nodos en el modo Standard de GKE, haz lo siguiente:

1. Crea un archivo de configuración. Este archivo contiene tus parámetros de configuración de kubelet y sysctl.
2. Agrega la configuración cuando crees un clúster o cuando crees o actualices un grupo de nodos.

Crea un archivo de configuración

Escribe la configuración del sistema de nodos en YAML. En el siguiente ejemplo, se agregan parámetros de configuración 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 administración de CPU estática.
• El campo net.core.somaxconn: '2048' limita la lista de tareas pendientes de socket listen() a 2,048 bytes.
• El campo net.ipv4.tcp_rmem: '4096 87380 6291456' establece el valor mínimo, predeterminado y máximo del búfer de recepción del socket TCP en 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 la configuración del sistema de nodos. 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 la configuración del sistema de nodos, 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 estándar

Después de crear la configuración del sistema de nodos, agrega la marca --system-config-from-file con Google Cloud CLI. Puedes agregar esta marca cuando creas un clúster o cuando creas o actualizas un grupo de nodos. No puedes agregar una configuración de sistema de nodo con la consola de Google Cloud .

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

Puedes agregar una configuración del sistema de nodos durante la creación del clúster con gcloud CLI o Terraform. En las siguientes instrucciones, se aplica la configuración del sistema de nodos al grupo de nodos predeterminado:

gcloud CLI

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

Reemplaza lo siguiente:

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

Después de aplicar una configuración del sistema de nodos, el grupo de nodos predeterminado del clúster usa la configuración que definiste.

Terraform

Para crear un clúster regional con una configuración del sistema de nodos personalizada a través de 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"
      }
    }
  }
}

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

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

Puedes agregar una configuración del sistema de nodos cuando usas gcloud CLI o Terraform para crear un grupo de nodos nuevo.

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

Reemplaza lo siguiente:

• 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 de procesamiento o región 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 para un grupo de nodos existente

Puedes establecer o actualizar la configuración del sistema de nodos para un grupo de nodos existente. Para obtener más información específica sobre cómo actualizar una configuración existente, consulta Edita mediante la actualización de un grupo de nodos existente.

Ejecuta el siguiente comando para actualizar el grupo de nodos existente:

   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: El nombre del clúster que deseas actualizar
• LOCATION: Es la zona de procesamiento o región del clúster.
• SYSTEM_CONFIG_PATH: Es la ruta de acceso al archivo que contiene tus configuraciones de kubelet y sysctl.

Este cambio requiere que se vuelvan a crear los nodos, lo que puede causar interrupciones en las cargas de trabajo en ejecución. Para obtener más información sobre este cambio específico, busca la fila correspondiente en la tabla de cambios manuales que vuelven a crear 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.

Precaución: GKE comienza a volver a crear los nodos para este cambio de inmediato con la estrategia de actualización de nodos, sin importar las políticas de mantenimiento activas. GKE depende de la disponibilidad de recursos para el cambio. Inhabilitar las actualizaciones automáticas de nodos no evita este cambio.

Edita una configuración del sistema de nodos

Puedes editar la configuración del sistema de un nodo según si usas ComputeClasses o un archivo de configuración.

Para ComputeClasses

Para editar la configuración del sistema de nodos cuando usas ComputeClasses, elige uno de los siguientes métodos:

Método 1: Actualiza la ComputeClass existente

Si actualizas el nodeSystemConfig en una ComputeClass existente, GKE aplica la configuración actualizada solo a los nodos recién creados. Los nodos existentes no se actualizan automáticamente.

Para migrar tus cargas de trabajo a nodos con la configuración nueva, puedes realizar una de las siguientes acciones:

• Configura la migración activa en tu ComputeClass.
• Para activar un escalamiento vertical de nodos nuevos, reinicia o vuelve a crear tus cargas de trabajo de forma manual.

Para actualizar ComputeClass, edita el archivo YAML y aplícalo:

kubectl apply -f custom-sysconfig.yaml

Método 2: Crea una ComputeClass nueva

Para asegurarte de que tus cargas de trabajo se migren a nodos nuevos con la configuración actualizada, haz lo siguiente:

1. Crea una nueva ComputeClass con un nombre diferente y la configuración actualizada.
2. Actualiza el selector de nodos en las especificaciones de tu carga de trabajo para que haga referencia a la nueva ComputeClass.
3. Aplica las especificaciones de carga de trabajo actualizadas. El escalador automático del clúster aprovisionará nodos nuevos con la nueva configuración y, finalmente, reducirá la escala de los nodos anteriores.
4. Borra el objeto ComputeClass anterior.

Para archivos de configuración

Para editar la configuración del sistema de nodos cuando usas un archivo de configuración, 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 la configuración del sistema de nodos creando 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 existente de un grupo de nodos existente, sigue las instrucciones de la pestaña Actualiza el grupo de nodos para agregar la configuración a un grupo de nodos. Cuando actualizas la configuración del sistema de un nodo y la configuración nueva anula la configuración del sistema existente del grupo de nodos, se deben volver a crear los nodos. Si omites algún parámetro durante una actualización, se establecerán los valores predeterminados respectivos.

Obtén la configuración existente del sistema de nodos

Para recuperar la configuración del sistema de nodos existente de tu grupo de nodos, por ejemplo, si ya personalizaste la configuración y quieres agregarla, usa el comando gcloud container node-pools describe. En el resultado del comando, se enumeran los parámetros de configuración existentes en kubeletConfig y linuxNodeConfig.

Precaución: Cuando actualices la configuración del nodo de Linux según este resultado, debes especificar los parámetros en el campo linuxConfig del comando de actualización. El comando describe muestra estos parámetros de configuración en linuxNodeConfig, pero para las actualizaciones, el campo correcto es linuxConfig. Si usas el campo de salida linuxNodeConfig en una solicitud de actualización, no se aplicarán los cambios.

Por ejemplo, consulta el siguiente fragmento que muestra el formato de salida del comando describe:

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

Si aún no estableciste una configuración del sistema de nodos, el resultado no incluirá kubeletConfig ni linuxNodeConfig.

Restablece la configuración del sistema de nodos existente

Si deseas restablecer la configuración del sistema de nodos a los valores predeterminados, actualiza el archivo de configuración con valores vacíos para los campos 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, sigue los pasos que se indican a continuación, según si usas ComputeClasses o un archivo de configuración.

Para ComputeClasses

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

1. Quita el selector de nodos cloud.google.com/compute-class de las especificaciones de tu carga de trabajo.
2. Aplica las especificaciones de carga de trabajo actualizadas. GKE vuelve a crear las cargas de trabajo en los nodos predeterminados. Con el tiempo, el escalador automático de clústeres reducirá la escala verticalmente y borrará los nodos que se aprovisionaron para la ComputeClass.

3. Borra el objeto ComputeClass del clúster:

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

Para archivos de configuración

Para quitar una configuración del sistema de nodos que se aplicó con un archivo de configuración, haz lo siguiente:

1. Crea un grupo de nodos nuevo sin el archivo de configuración.
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 para kubelet

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

Administración de CPU

En la siguiente tabla, se describen las opciones de administración de CPU para kubelet.

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
cpuCFSQuota	Debe ser true o false.	true	Este parámetro de configuración aplica el límite de CPU del Pod. Si estableces este valor en false, se ignorarán los límites de CPU para los Pods. Ignorar los límites de CPU puede ser beneficioso 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 no autorizado puede consumir más recursos de CPU de lo previsto.
cpuCFSQuotaPeriod	Debe ser una duración de tiempo.	"100ms"	Este parámetro de configuración establece el valor del período de cuota de CFS de la CPU, cpu.cfs_period_us, que especifica el período con el 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 CPU.
reservedSystemCPUs (Vista previa)	Debe ser una lista de núcleos de CPU específicos para reservar (por ejemplo, 0-1 o 0,1 para reservar los núcleos 0 y 1). Dado que los núcleos se indexan a partir de cero, los valores deben ser menores que la cantidad de CPU virtuales del tipo de máquina.	none	Reserva de forma explícita núcleos de CPU específicos para los servicios del sistema host, como los daemons del SO y el servicio kubelet. De forma predeterminada, estos servicios se pueden ejecutar en cualquier núcleo de CPU, lo que puede causar problemas de rendimiento en las cargas de trabajo sensibles a la CPU. Si bien el parámetro de configuración cpuManagerPolicy: static asigna núcleos dedicados a los Pods Guaranteed con solicitudes de CPU de números enteros, no impide que los servicios del sistema host usen esos núcleos. Agregar el parámetro de configuración reservedSystemCPUs limita los servicios del sistema host a sus propios núcleos reservados, lo que evita que interrumpan los núcleos exclusivos de tus cargas de trabajo. Para realizar esta tarea, GKE fija automáticamente el cgroup system.slice en los núcleos reservados durante el inicio del nodo. Reservar las CPUs del sistema reduce la capacidad asignable general de tus nodos. Si bien los Pods Burstable y BestEffort pueden seguir ejecutándose en estos núcleos reservados, sus solicitudes de CPU, incluidas las solicitudes fraccionarias de los DaemonSets de GKE, siguen contando para la capacidad asignable del nodo. Dado que las cargas de trabajo exclusivas de Guaranteed requieren núcleos completos, incluso las solicitudes fraccionarias pequeñas reducen la cantidad de núcleos exclusivos disponibles. Asegúrate de reservar suficientes núcleos de CPU en reservedSystemCPUs. Si reservas muy pocos núcleos, los daemons del sistema host y los procesos del SO podrían verse limitados por la CPU cuando la carga sea alta, lo que puede causar inestabilidad o pérdida de paquetes de red.

Administración y expulsión de la memoria

En la siguiente tabla, se describen las opciones modificables para la administración de la memoria y el descarte. En esta sección, también se incluye una tabla independiente que describe las opciones modificables para la marca evictionSoft.

kubelet parámetros de configuración	Restricciones	Parámetro de configuración predeterminado	Descripción
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 una cantidad o un porcentaje que define los umbrales de descarte flexible. Un umbral de expulsión suave debe tener un período de gracia. El kubelet no expulsa Pods hasta que se supera el período de gracia.
evictionSoftGracePeriod	Es un mapa de nombres de indicadores. Para cada nombre de indicador, 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 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	Es un mapa de nombres de indicadores. Para cada nombre de indicador, el valor debe ser un porcentaje positivo inferior a 10%.	none	Este parámetro de configuración asigna nombres de indicadores a porcentajes que definen la cantidad mínima de un recurso determinado que kubelet recupera 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.
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 finalizan por falta de memoria de forma individual o como grupo. Disponible en las versiones 1.32.4-gke.1132000, 1.33.0-gke.1748000 o posteriores de GKE.

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

kubelet parámetros de configuración	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.	none	Este parámetro de configuración representa la cantidad de memoria disponible antes del desalojo temporal. Define la cantidad de señal de memory.available en el kubelet .
nodefsAvailable	El valor debe estar entre 10% y 50%.	none	Este parámetro de configuración representa los nodefs disponibles antes de la expulsión suave. Define la cantidad de la señal nodefs.available en kubelet .
nodefsInodesFree	El valor debe estar entre 5% y 50%.	none	Este parámetro de configuración representa los nodos inodefs que están libres antes del desalojo temporal. Define la cantidad de la señal nodefs.inodesFree en el kubelet .
imagefsAvailable	El valor debe estar entre 15% y 50%.	none	Este parámetro de configuración representa el espacio de imagefs disponible antes de la expulsión no forzada. Define la cantidad de señal de imagefs.available en el kubelet .
imagefsInodesFree	El valor debe estar entre 5% y 50%.	none	Este parámetro de configuración representa los nodos i de imagefs que están libres antes del desalojo temporal. Define la cantidad de la señal imagefs.inodesFree en kubelet.
pidAvailable	El valor debe estar entre 10% y 50%.	none	Este parámetro de configuración representa los PIDs disponibles antes del desalojo temporal. Define la cantidad de la señal pid.available en el kubelet.

Administración de PID

En la siguiente tabla, se describen las opciones modificables para la administración de PID.

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
podPidsLimit	El valor debe estar entre 1024 y 4194304.	none	Esta configuración establece la cantidad máxima de ID de procesos (PID) que puede usar cada Pod.

Logging

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

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
containerLogMaxSize	El valor debe ser un número positivo y un sufijo de unidad entre 10Mi y 500Mi, inclusive.	10Mi	Este parámetro de configuración controla el parámetro 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. Las unidades válidas son Ki, Mi y Gi.
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 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 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 recolección de elementos no utilizados de imágenes.

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
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. Representa 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.
imageGcLowThresholdPercent	El valor debe ser un número entero entre 10 y 85, inclusive, 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. Representa el uso de disco más bajo para la recolección de elementos no utilizados. El porcentaje se calcula dividiendo el valor de este campo por 100.
imageMinimumGcAge	El valor debe ser una duración que no supere 2m. Las unidades de tiempo válidas son ns, us (o µs), ms, s, m o h.	2m	Este parámetro de configuración define la antigüedad mínima de una imagen no utilizada antes de que se realice la recolección de elementos no utilizados.
imageMaximumGcAge	El valor debe ser una duración de tiempo.	0s	Este parámetro de configuración define 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 0s, lo que lo inhabilita. Por lo tanto, no se recolectarán los elementos no utilizados de las imágenes en función de que no se usen. Cuando se especifica este valor, debe ser mayor que el valor del campo imageMinimumGcAge. Disponible en las versiones 1.30.7-gke.1076000 y 1.31.3-gke.1023000 de GKE, o versiones posteriores.

Extracción de imágenes

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

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
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.

Seguridad y operaciones no seguras

En la siguiente tabla, se describen las opciones modificables para configurar la seguridad y controlar las operaciones no seguras.

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
allowedUnsafeSysctls	Es la lista de nombres o grupos de sysctl. Los grupos de sysctl permitidos son los siguientes: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*	none	Este parámetro de configuración define una lista de entidades permitidas separada por comas de nombres sysctl o grupos de sysctl no seguros que se pueden establecer en los Pods.
insecureKubeletReadonlyPortEnabled	Debe ser un valor booleano: true o false.	false	Este parámetro de configuración inhabilita el kubelet puerto de solo lectura 10255 no seguro en cada grupo de nodos nuevo de tu clúster. Si estableces este parámetro de configuración en este archivo, no puedes usar un cliente de API de GKE para cambiar el parámetro de configuración a nivel del clúster.

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 de nodo para los Pods que se configuran con requisitos específicos para los recursos de CPU, dispositivos y memoria (páginas grandes).

En la siguiente tabla, se describen las opciones modificables para los administradores de recursos.

kubelet parámetros de configuración	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 CPU Manager de kubelet. El valor predeterminado es none, que es el esquema de afinidad de CPU predeterminado y no proporciona afinidad más allá de lo que el programador del SO hace automáticamente. Si se establece este valor en static, se permite que se asignen CPUs exclusivas a los Pods que se encuentran en la clase de QoS Guaranteed y tienen solicitudes de CPU de números enteros.
memoryManager.policy	El valor debe ser None o Static.	None	Este parámetro de configuración controla la política de administración de la memoria de kubelet. Con el valor predeterminado de None, Kubernetes actúa de la misma manera que si el administrador de la memoria no estuviera presente. Si configuras este valor como 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 de GKE o una posterior.
topologyManager	El valor debe ser uno de los parámetros de configuración admitidos para cada uno de los campos respectivos. No puedes establecer el campo topologyManager cuando usas las instrucciones de Terraform para agregar la configuración a un grupo de nodos estándar.	policy: none scope: container	Estos parámetros de configuración controlan la configuración del administrador de topología de kubelet con los subcampos policy y scope. El administrador de topología 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 establecer la configuración de la política y del permiso de forma independiente. Para obtener más información sobre estos parámetros de configuración, consulta Permisos y políticas del administrador de topologías. 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 o posterior de GKE. 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, C4N, G2, G4, M3 y N4

Demora en el reinicio del contenedor

Este parámetro de configuración controla el tiempo máximo de espera entre los intentos de reinicio del contenedor cuando este se encuentra en un estado CrashLoopBackOff. Puedes configurar este parámetro para los grupos de nodos Standard que ejecutan la versión 1.35 o posterior de GKE.

Precaución: Una demora muy corta en un contenedor que falla de forma persistente puede generar un alto consumo de CPU y recursos en el nodo, lo que podría afectar otras cargas de trabajo debido al agotamiento de recursos. Considera reducirlo solo cuando los beneficios de los reintentos más rápidos superen los riesgos de un mayor uso de recursos.

En la siguiente tabla, se describen las opciones modificables para crashLoopBackOff.

kubelet parámetros de configuración	Restricciones	Parámetro de configuración predeterminado	Descripción
crashLoopBackOff.maxContainerRestartPeriod	El valor debe ser una duración positiva menor o igual que 5 minutos (5m). Las unidades de tiempo válidas son ns, us (o µs), ms, s o m.	none	Es la duración máxima que puede acumularse el retraso de la retirada para los reinicios de contenedores. La demora entre los reinicios aumenta de forma exponencial desde un valor inicial hasta este límite máximo. El límite máximo predeterminado para un clúster de Kubernetes es de 5 minutos. Para obtener más información, consulta Retraso configurable del reinicio del contenedor.

Cierre ordenado de las VMs Spot en GKE

En la siguiente tabla, se describen las opciones modificables para el período de finalización y cierre ordenado de las VMs Spot en GKE. Para usar estas opciones, el plano de control de tu clúster debe ejecutar la versión 1.35.0-gke.1171000 o posterior de GKE. Para obtener más información, consulta Cómo funcionan las VMs Spot en GKE.

kubelet parámetros de configuración	Restricciones	Parámetro de configuración predeterminado	Descripción
shutdownGracePeriodSeconds	El valor debe ser un número entero que represente la duración en segundos. Los valores permitidos son 0, 30 o 120.	30	Especifica la duración total en segundos que el nodo retrasa el apagado para finalizar los Pods de forma correcta.
shutdownGracePeriodCriticalPodsSeconds	El valor debe ser un número entero entre 0 y 120 (inclusive), y debe ser menor que shutdownGracePeriodSeconds. Solo es válido si también se configura shutdownGracePeriodSeconds.	15	Especifica la duración en segundos que se usa para finalizar los Pods esenciales durante el cierre de un nodo.

Reservas de recursos del sistema

Vista previa

Este producto o función está sujeto a las "Condiciones de la oferta previa a la DG" en la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Los productos y las funciones de la fase previa a la DG están disponibles “tal como están” y pueden estar sujetos a asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En el caso de los grupos de nodos de Standard que ejecutan Linux y GKE 1.37 o una versión posterior, puedes personalizar la cantidad de memoria y CPU reservadas para los componentes del sistema. Esto te permite ajustar la capacidad asignable para situaciones específicas, como controlar extracciones de imágenes de gran volumen o ejecutar DaemonSets de nodos personalizados. Para obtener más información sobre las reservas predeterminadas, consulta Acerca del tamaño de los nodos de GKE.

En la siguiente tabla, se describen las opciones modificables para las reservas de recursos del sistema.

Parámetros de configuración de kubelet	Restricciones	Parámetro de configuración predeterminado	Descripción
reservedResourcesConfig.memoryReservedMib	El valor debe ser un número entero. Debe ser mayor o igual que la reserva de memoria predeterminada para los grupos de nodos creados que ejecutan la versión 1.37 o posterior, y menor que el 50% de la capacidad de memoria total del nodo.	Consulta Reservas de memoria.	Cantidad de memoria que se reservará para los componentes del sistema, en mebibytes (MiB).
reservedResourcesConfig.cpuReservedMillicore	El valor debe ser un número entero. Debe ser mayor o igual que la reserva de CPU predeterminada para los grupos de nodos creados que ejecutan la versión 1.37 o posterior, y menor que el 50% de la capacidad total de CPU del nodo.	Consulta Reservas de CPU.	La cantidad de CPU que se reservará para los componentes del sistema, en milicores.

Verifica las reservas efectivas

Para verificar las reservas activas aplicadas a tu grupo de nodos, inspecciona los campos de salida effectiveMemoryReservedMib y effectiveCpuReservedMillicore:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

Opciones de configuración de Sysctl

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

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

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

Parámetro Sysctl	Restricciones	Descripción
fs.aio-max-nr	Debe estar entre [65536, 4194304].	Este parámetro de configuración define la cantidad máxima de solicitudes de E/S asíncronas en todo el sistema.
fs.file-max	Debe estar entre [104857, 67108864].	Este parámetro de configuración define la cantidad máxima de identificadores de archivos que puede asignar el kernel de Linux.
fs.inotify.max_user_instances	Debe estar entre [8192, 1048576].	Este parámetro de configuración define la cantidad máxima de instancias de inotify que puede crear un usuario.
fs.inotify.max_user_watches	Debe estar entre [8192, 1048576].	Este parámetro de configuración define la cantidad máxima de supervisores de inotify que puede crear un usuario.
fs.nr_open	Debe estar entre [1048576, 2147483584].	Este parámetro de configuración define la cantidad máxima de descriptores de archivos 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 parámetros de configuración establecen las funciones principales del kernel, incluida la asignación de memoria compartida.

Parámetro de sysctl	Restricciones	Descripción
kernel.shmmni	Debe estar entre [4096 y 32768].	Este parámetro de configuración define la cantidad máxima de segmentos de memoria compartida en todo el sistema. Si no se establece este valor, el valor predeterminado es 4096.
kernel.shmmax	Debe estar entre [0, 18446744073692774399].	Este parámetro de configuración define el tamaño máximo, en bytes, de un solo segmento de memoria compartida que permite el kernel. Este valor se ignora si es mayor que la cantidad real de RAM, lo que significa que se puede compartir toda la RAM disponible.
kernel.shmall	Debe estar entre [0, 18446744073692774399].	Este parámetro de configuración define la cantidad total de páginas de memoria compartida que se pueden usar en el sistema a la vez. Una página tiene 4,096 bytes en la arquitectura AMD64 e Intel 64.
kernel.perf_event_paranoid	Debe estar entre [-1, 3].	Este parámetro de configuración controla el uso del sistema de eventos de rendimiento por parte de usuarios sin privilegios y sin CAP_PERFMON. El valor predeterminado es 2 en el kernel.
kernel.sched_rt_runtime_us	Debe estar entre [-1, 1000000].	Este parámetro de configuración define un límite global sobre la cantidad de tiempo que puede usar la programación en tiempo real.
kernel.softlockup_panic	Opcional (booleano).	Este parámetro de configuración controla si el kernel entra en pánico cuando se detecta un bloqueo temporal.
kernel.yama.ptrace_scope	Debe estar entre [0, 3].	Este parámetro de configuración define el alcance y las restricciones de la llamada al sistema ptrace(), lo que afecta la depuración y el seguimiento de procesos. Entre los valores admitidos, se incluyen los siguientes: 0: permisos de 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 los procesos con CAP_SYS_PTRACE. 3: No se permite ptrace. No se permiten llamadas a ptrace.
kernel.kptr_restrict	Debe estar entre [0, 2].	Este parámetro de configuración indica si se aplican restricciones para exponer direcciones del kernel a través de /proc y otras interfaces.
kernel.dmesg_restrict	Opcional (booleano).	Este parámetro de configuración 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, 511].	Este parámetro de configuración controla las funciones que se pueden invocar a través de la tecla SysRq. Entre los valores posibles, se incluyen los siguientes: 0: inhabilita sysrq por completo. 1: habilita todas las funciones de sysrq. >1: Es una máscara de bits de las funciones de sysrq permitidas. Para obtener más información, consulta Trucos de la clave de solicitud del sistema mágico de Linux.
kernel.keys.maxbytes	Debe estar entre [20000, 2097152].	Este parámetro de configuración define la cantidad máxima de bytes que un usuario no raíz puede tener en la sección de carga útil de todas sus claves.
kernel.keys.maxkeys	Debe estar entre [200, 1048576].	Este parámetro de configuración define la cantidad máxima de claves que puede tener un usuario no raíz.

Parámetros de red (net.*)

En la siguiente tabla, se describen los parámetros modificables para las redes. Estos parámetros ajustan el rendimiento y el comportamiento de la pila de redes, desde los búferes de socket hasta el seguimiento de conexiones.

Parámetro sysctl	Restricciones	Descripción
net.core.busy_poll	Cualquier número entero positivo, menor que 2147483647.	Este parámetro de configuración define el tiempo de espera de sondeo ocupado de baja latencia para el sondeo y la selección. Representa el tiempo aproximado en µs para el bucle de espera de eventos.
net.core.busy_read	Cualquier número entero positivo, inferior a 2147483647.	Este parámetro de configuración define el tiempo de espera de sondeo de ocupado de baja latencia para las lecturas de sockets. Representa el tiempo aproximado en µs para el bucle de espera de paquetes en la cola del dispositivo.
net.core.netdev_max_backlog	Cualquier número entero positivo, inferior a 2147483647.	Este parámetro de configuración define la cantidad máxima de paquetes en cola del lado de 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 parámetro de configuración define el tamaño predeterminado del búfer de sockets de recepción, en bytes.
net.core.rmem_max	Cualquier número entero positivo, inferior a 2147483647.	Este parámetro de configuración 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 parámetro define el parámetro de configuración predeterminado, en bytes, del búfer de envío del socket.
net.core.wmem_max	Cualquier número entero positivo, inferior a 2147483647.	Este parámetro de configuración 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 parámetro de configuración define el tamaño máximo del búfer auxiliar permitido por socket.
net.core.somaxconn	Debe estar entre [128, 2147483647].	Este parámetro de configuración define el límite de la acumulación de socket listen(), que se conoce en el espacio del usuario como SOMAXCONN. El valor predeterminado de este parámetro de configuración es 128.
net.ipv4.tcp_rmem	{min, default, max} (cada uno > 0, memoria en bytes)	Este parámetro de configuración define el tamaño mínimo, en bytes, del búfer de recepción que usan los sockets UDP con moderación. La configuración predeterminada es de 1 página.
net.ipv4.tcp_wmem	{min, default, max} (cada uno > 0, memoria en bytes).	Este parámetro de configuración define el tamaño mínimo, en bytes, del búfer de envío que usan los sockets UDP con moderación. El parámetro de configuración predeterminado es 1 página.
net.ipv4.tcp_tw_reuse	Debe estar entre {0, 1}.	Este parámetro de configuración define si se permite la reutilización de sockets en el estado TIME_WAIT para conexiones nuevas cuando es seguro desde el punto de vista del protocolo. El valor predeterminado es 0.
net.ipv4.tcp_max_orphans	Debe estar entre [16384, 262144].	Este parámetro de configuración define la cantidad máxima de sockets TCP que no están asociados a ningún identificador de manejo de archivos del usuario.
net.ipv4.tcp_max_tw_buckets	Debe estar entre [4096, 2147483647].	Este parámetro de configuración define la cantidad máxima de sockets de espera de tiempo que el sistema mantiene de forma simultánea. Si se supera este número, el socket de espera se destruye de inmediato y se imprime una advertencia.
net.ipv4.tcp_syn_retries	Debe estar entre [1, 127].	Este parámetro de configuración define la cantidad de veces que se retransmiten los SYN iniciales para un intento de conexión TCP activa.
net.ipv4.tcp_ecn	Debe ser entre [0, 2].	Este parámetro de configuración controla el uso de la notificación de congestión explícita (ECN) por parte de TCP. ECN solo se usa cuando ambos extremos de la conexión TCP indican que la admiten.
net.ipv4.tcp_mtu_probing	Debe ser entre [0, 2].	Este parámetro de configuración controla el descubrimiento de MTU de ruta de la capa de empaquetado de TCP. Los valores admitidos son los siguientes: 0: Inhabilitado. 1: Está inhabilitado de forma predeterminada y se habilita cuando se detecta un agujero negro de ICMP. 2: siempre habilitado. 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 parámetro de configuración no es compatible cuando GKE Dataplane V2 está habilitado en el clúster. Los siguientes valores admitidos dependen del tipo de imagen: Container-Optimized OS: reno, cubic, bbr, lp, htcp (disponible en las versiones 1.34.1-gke.3355001 o posteriores de GKE) Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Booleano.	Cambiar este valor es lo mismo que cambiar el parámetro de configuración conf/default/disable_ipv6 y todos los parámetros de configuración disable_ipv6 por interfaz al mismo valor.
net.ipv6.conf.default.disable_ipv6	Booleano.	Este parámetro de configuración inhabilita el funcionamiento de IPv6.
net.netfilter.nf_conntrack_acct	Debe ser un valor entre {0, 1}.	Este parámetro de configuración habilita la contabilización del flujo de seguimiento de conexiones. El valor predeterminado es 0, lo que significa que el parámetro de configuración está inhabilitado. Disponible en las versiones 1.32.0-gke.1448000 y posteriores de GKE.
net.netfilter.nf_conntrack_max	Debe estar entre [65536, 4194304].	Este parámetro de configuración define el tamaño de la tabla de seguimiento de conexiones. Si se alcanza el valor máximo, la conexión nueva fallará. Disponible en las versiones 1.32.0-gke.1448000 o posteriores de GKE.
net.netfilter.nf_conntrack_buckets	Debe estar entre [65536, 524288].	Este parámetro de configuración define el tamaño de la tabla hash. El parámetro de configuración 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 3, 600].	Este parámetro de configuración define el período, 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 parámetro de configuración define la duración, en segundos, de las conexiones inactivas antes de que se borren 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 entre [1, 600].	Este parámetro de configuración define el período, 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 y posteriores de GKE.
net.ipv4.neigh.default.gc_thresh1	Debe ser un valor entre [0, 262144].	Este parámetro de configuración define la cantidad mínima de entradas que se deben mantener en la caché de ARP. El recolector de basura no se ejecuta si la cantidad de entradas es inferior a este parámetro de configuración. Establecer este valor en 0 puede provocar un intercambio excesivo de caché y un rendimiento deficiente.
net.ipv4.neigh.default.gc_thresh2	Debe estar entre [512, 524288].	Este parámetro de configuración define la cantidad máxima flexible de entradas que se deben mantener en la caché de ARP. El recolector de elementos no utilizados permite que la cantidad de entradas supere este valor durante 5 segundos antes de iniciar la recolección de elementos no utilizados parcial.
net.ipv4.neigh.default.gc_thresh3	Debe estar entre [1024, 1048576].	Este parámetro de configuración define la cantidad máxima de entradas que se pueden conservar en la caché de ARP. El recolector de basura está diseñado para ejecutarse siempre si la cantidad de entradas supera este parámetro de configuración.

Parámetros de memoria virtual (vm.*)

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

Parámetro sysctl	Restricciones	Descripción
vm.max_map_count	Debe estar entre [65536, 2147483647].	Este archivo define la cantidad máxima de áreas de asignación de memoria que puede tener un proceso.
vm.dirty_background_ratio	Debe estar entre [1 y 100].	Este parámetro de configuración 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 comiencen la reescritura. El valor debe ser inferior al del campo vm.dirty_ratio.
vm.dirty_background_bytes	Debe estar entre [0, 68719476736].	Este parámetro de configuración define la cantidad de memoria sucia en la que los subprocesos de vaciado del kernel en segundo plano comienzan la escritura diferida. Ten en cuenta que vm.dirty_background_bytes es la contraparte de vm.dirty_background_ratio. Solo se puede especificar uno de estos parámetros de configuración.
vm.dirty_expire_centisecs	Debe estar entre [0, 6000].	Este parámetro de configuración define la antigüedad máxima, en centésimas de segundo, que los datos sucios pueden permanecer 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, 100].	Este parámetro de configuración 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 bloquear y escribir datos sucios de forma síncrona.
vm.dirty_bytes	Debe estar entre [0, 68719476736].	Este parámetro de configuración define la cantidad de memoria sucia en la que un proceso que genera escrituras en el disco inicia la reescritura por sí mismo. 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 parámetros de configuración.
vm.dirty_writeback_centisecs	Debe ser un valor entre 0 y 1, 000.	Este parámetro de configuración define el intervalo, en centésimas de segundo, en el que se activan los subprocesos de vaciado del kernel para escribir datos sucios antiguos en el disco.
vm.overcommit_memory	Debe ser un valor entre {0, 1, 2}.	Este parámetro de configuración determina la estrategia del kernel para controlar la sobreasignación de memoria. Los valores son los siguientes: 0: Rechaza las asignaciones grandes 1: Permitir siempre (valor predeterminado) 2: Evita la confirmación más allá del intercambio y la proporción de RAM Este parámetro de configuración no se admite en máquinas con menos de 15 GB de memoria.
vm.overcommit_ratio	Debe ser un valor entre 0 y 100.	Este parámetro de configuración define el porcentaje de RAM física que se permite para la asignación excesiva cuando el valor del campo vm.overcommit_memory se establece en 2.
vm.vfs_cache_pressure	Debe estar entre [0, 100].	Este parámetro de configuración ajusta la preferencia del kernel para recuperar la memoria que se usa para las memorias caché de dentry (directorio) y de inodo.
vm.swappiness	Debe ser un valor entre 0 y 200.	Este parámetro de configuración controla la tendencia del kernel de mover procesos fuera de la memoria física y al disco de intercambio. El valor predeterminado es 60.
vm.watermark_scale_factor	Debe estar entre [10, 3000].	Este parámetro de configuración controla la agresividad de kswapd. Define la memoria restante 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, 1048576].	Este parámetro de configuración define la memoria libre mínima antes de que se produzca un error de OOM. El valor predeterminado es 67584.

Para obtener más información sobre los valores admitidos para cada marca 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 una marca sysctl determinada, mientras que otros pueden ser globales para todo el nodo. La actualización de las opciones de sysctl con una configuración del 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 admitir cgroupv1 con la versión secundaria 1.31 y quitará la compatibilidad con cgroupv1 con la versión 1.35. Para obtener más información sobre cómo GKE está realizando la transición a cgroupv2 y cómo puedes preparar tus clústeres para esta transición, consulta Migra nodos a cgroupv2 de Linux.

El entorno de ejecución del contenedor y kubelet usan cgroups del 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 introdujo 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 nuevos de Standard 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 el caso de 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 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 que usa cgroupv1 a la versión 1.26 no cambia el parámetro de configuración a cgroupv2. Los grupos de nodos existentes que ejecutan una versión anterior a la 1.26 y que no incluyen una configuración de cgroup personalizada seguirán usando cgroupv1. Para cambiar la configuración, debes especificar de forma explícita cgroupv2 para el grupo de nodos existente.

Por ejemplo, para configurar tu grupo de nodos para que use 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.
• Si usas herramientas de supervisión o de terceros, asegúrate de que sean compatibles con cgroupv2.
• Si usas cargas de trabajo de Java (JDK), te recomendamos que uses versiones que admitan 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 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 vuelven a crear los nodos en el 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 para nodos en este grupo de nodos, selecciona un nodo y conéctate a él con las siguientes instrucciones:

1. Crea una shell interactiva con cualquier nodo del grupo de nodos. En el comando, reemplaza mynode 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áginas enormes de Linux

Puedes usar hugepages preasignadas de forma manual o hugepages transparentes asignadas automáticamente.

Hugepages preasignadas

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

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 enormes asignadas no puede exceder lo siguiente:
  • En máquinas con menos de 30 GB de memoria: 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 para páginas enormes.
  • En máquinas con más de 30 GB de memoria: 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, C4N, CT5E, CT5LP, CT6E, H3, M2, M3, M4, Z3 o Z4D.

En la siguiente tabla, se describen los parámetros de configuración modificables para las páginas enormes de Linux.

Parámetro de configuración	Restricciones	Valor predeterminado	Descripción
hugepage_size2m	Recuento de números enteros. Sujeto a los límites de asignación de memoria descritos anteriormente.	0	Este parámetro de configuración asigna previamente una cantidad específica de páginas gigantes de 2 MB.
hugepage_size1g	Es un recuento de números enteros. Sujeto a las dos limitaciones de memoria y tipo de máquina descritas anteriormente.	0	Este parámetro de configuración preasigna una cantidad específica 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 compatibilidad con Transparent HugePage del kernel de Linux. Con THP, el kernel asigna automáticamente hugepages a los procesos sin necesidad de una asignación previa manual.

En la siguiente tabla, se describen los parámetros modificables para el 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 dentro de las regiones de MADV_HUGEPAGE. Este parámetro de configuración es la configuración predeterminada del kernel. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: La página enorme transparente está inhabilitada. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: Es el valor predeterminado. GKE no modifica la configuración del kernel.	UNSPECIFIED	Este parámetro de configuración controla si las THP están habilitadas para la memoria anónima.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: Una aplicación que solicita THP se detiene cuando falla la asignación y recupera directamente las páginas y compacta la memoria en un esfuerzo 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 se encarga de instalar las páginas de THP más adelante. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: Una aplicación ingresa en la recuperación y la compactación directas como de costumbre, pero solo para las regiones que usaron madvise(MADV_HUGEPAGE). En todas las demás 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 el futuro cercano. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: Una aplicación ingresa a la recuperación y compactación directas como de costumbre, 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: Es el valor predeterminado. GKE no modifica la configuración del kernel.	UNSPECIFIED	Este parámetro define la configuración de desfragmentación para THP.

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

Opción de sincronización de hora precisa de Linux

Si la sincronización precisa de la hora y la supervisión de la exactitud de la sincronización de la hora son importantes para tus cargas de trabajo, puedes configurar la hora precisa para sincronizar el reloj de tu VM con el reloj del host con chrony y ptp_kvm. La sincronización de hora precisa está disponible en la versión 1.36.0-gke.3241000 y posteriores de GKE. Esta configuración está diseñada para lograr una precisión de 1 ms en las configuraciones compatibles. Para obtener más información sobre los tipos de máquinas, los sistemas operativos y las zonas compatibles, consulta Configura la hora exacta para las VMs de Compute Engine.

En la siguiente tabla, se describe el parámetro para configurar la sincronización de hora precisa con GKE:

Parámetro de configuración	Valores admitidos	Valor predeterminado	Descripción
Archivo de configuración: accurateTimeConfig.enablePtpKvmTimeSync Terraform: accurate_time_config.enable_ptp_kvm_time_sync	true o false	false	Este parámetro de configuración permite una sincronización de hora precisa. Esta función solo es compatible con tipos de máquinas, sistemas operativos y zonas específicos.

Después de habilitar la sincronización de hora precisa, GKE recopila y exporta la siguiente información:

• La métrica compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, que indica la exactitud del reloj del host de la VM con respecto a la hora UTC.
• El registro projects/PROJECT_ID/logs/chrony.tracking, que contiene los registros de seguimiento de chrony. Estos registros proporcionan información como la tasa de ganancia o pérdida del reloj del sistema.

Puedes usar esta información para crear métricas basadas en registros y paneles en Cloud Monitoring y, así, analizar el rendimiento y la confiabilidad de la sincronización de hora.

Por ejemplo, la siguiente configuración de gke-clock-metric.json define una métrica basada en registros del error máximo del reloj del host:

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

La siguiente configuración de gke-metrics-dashboard.json define un panel de supervisión que agrega los datos de error de la métrica basada en registros y la métrica de precisión del UTC:

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

Opciones de configuración de VFIO de Linux

En la siguiente tabla, se describe el parámetro para configurar VFIO (E/S de función virtual) en un nodo. VFIO permite que los controladores de espacio de usuario seguros y sin privilegios accedan a los dispositivos de E/S.

Parámetro de configuración	Restricciones	Valor predeterminado	Descripción
nodeVfioConfig.dmaEntryLimit	Debe ser un número entero entre 65535 y 4194304.	65535	Especifica la cantidad máxima de entradas de DMA (páginas) que puede asignar el controlador VFIO IOMMU de tipo 1 para un contenedor. Este límite afecta la cantidad total de memoria del host que se puede fijar para el acceso directo a los dispositivos, lo que suele ser fundamental para los dispositivos de alto rendimiento, como las TPU y las GPU. Este parámetro de configuración corresponde al siguiente parámetro del kernel: /sys/module/vfio_iommu_type1/parameters/dma_entry_limit. Es posible que se necesiten valores más altos para las cargas de trabajo que asignan regiones de memoria grandes. Disponible en las versiones de GKE 1.36.0-gke.3009000 o posteriores.

Opciones de configuración del programador de E/S de disco de Linux

En la siguiente tabla, se describen los parámetros para configurar el programador de E/S de disco para los grupos de nodos.

Parámetro de configuración	Valores admitidos	Valor predeterminado	Descripción
diskIoScheduler.nodeSystemIoScheduler	mq-deadline, bfq, kyber, none	bfq para la imagen de Container-Optimized OS y none para la imagen de Ubuntu	Configura el programador de E/S para el disco de arranque o la SSD local efímera que ejecuta las cargas de trabajo del sistema del nodo. Disponible en las versiones 1.36.0-gke.3009000 o posteriores de GKE.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Configura el programador de E/S para los discos conectados. Disponible en las versiones 1.36.0-gke.3009000 o posteriores de GKE.

¿Qué sigue?

• Obtén más información para migrar nodos a cgroupv2 de Linux.
• Obtén más información para agregar y administrar grupos de nodos.
• Obtén información para personalizar la configuración de containerd en los nodos de GKE.
• Obtén información para iniciar los nodos de GKE de forma automática con DaemonSets.