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 opciones de configuración del sistema. En tu grupo de nodos, puedes usar una configuración del sistema de nodos para especificar parámetros de configuración personalizados para el agente del nodo de Kubernetes kubelet y para los parámetros 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 de forma exhaustiva 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

La configuración del sistema de nodos ofrece 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 de alto 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 cargas de trabajo: Ayudan a garantizar que el entorno de nodos cumpla con los requisitos previos específicos para el software especializado o las aplicaciones más antiguas que requieren parámetros de configuración de 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 Personaliza la configuración de containerd en los 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 Standard de GKE, en la versión 1.32.1-gke.1729000 y posteriores de GKE. Para obtener más información, consulta Personaliza 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 de 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 las cargas de trabajo y usa presupuestos de interrupción de Pods (PDB) cuando corresponda.
• Crea una copia de seguridad y prueba todos los cambios: Siempre prueba los cambios de configuración en un entorno de etapa de pruebas o entorno de desarrollo antes de aplicarlos a la 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 nodo de GKE incluyen parámetros de configuración predeterminados optimizados. Personaliza los parámetros solo si tienes una necesidad específica y comprendes el impacto de los 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 una ComputeClass personalizada para personalizar ciertos parámetros en el kubelet y el kernel de Linux. Este método está disponible en GKE versión 1.32.1-gke.1729000 y 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 de ComputeClass, se 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 seleccione la 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. Aunque los parámetros de configuración del sistema de nodos también están disponibles en el modo Autopilot de GKE, en los pasos de este documento, se muestra cómo crear y usar un archivo de configuración para el modo Standard de GKE.

Para usar un archivo de 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 tus parámetros de configuración de kubelet y sysctl.
2. Agrega la configuración cuando crees un clúster o un grupo de nodos, o actualiza un grupo de nodos existente.

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 usar 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 de Standard

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 un grupo de nodos, o cuando actualizas un grupo de nodos existente. 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: Es la ruta de acceso al archivo que contiene tus parámetros de configuración de kubelet y sysctl.

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

Terraform

Para crear un clúster regional con una configuración personalizada del sistema de nodos con 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 para usar 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: 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.

Terraform

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

Si usas un archivo de configuración para administrar la configuración del sistema de nodos, puedes actualizar un grupo de nodos existente de una de las siguientes maneras:

• Actualización en vivo sin interrupciones: Aplica la configuración actualizada de sysctl y kubelet directamente a los nodos en ejecución sin volver a crear las VMs ni expulsar Pods. Usa este método cuando solo cambies la configuración de sysctl o kubelet y quieras minimizar las interrupciones.
• Estrategia de actualización estándar: Vuelve a crear los nodos con la configuración nueva. Usa este método cuando cambies parámetros de configuración que no admitan novedades en tiempo real, cuando tu clúster o grupo de nodos ejecute una versión de GKE anterior a la 1.37.1-gke.1954000 o cuando quieras que GKE vacíe y reprograme tus Pods en nodos nuevos.

Para cambiar la configuración de los nodos que usan una ComputeClass, consulta Edita una configuración del sistema de nodos para ComputeClasses en su lugar.

Precaución: Con cualquiera de los métodos, incluir la sección kubeletConfig o linuxConfig en tu archivo reemplaza toda esa sección de la configuración existente del grupo de nodos. Cualquier parámetro que omitas de una sección incluida se restablece a su valor predeterminado. Durante una actualización en vivo, omitir un parámetro configurado anteriormente que no admite novedades en tiempo real (como cpuManagerPolicy o cgroupMode) hace que GKE rechace la actualización. Antes de actualizar, obtén la configuración del sistema de nodos existente y agrega todos los parámetros de configuración que quieras conservar.

Actualiza con una actualización en vivo no disruptiva

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.

Puedes aplicar la configuración actualizada de sysctl y kubelet desde tu archivo de configuración directamente a los nodos en ejecución. Debido a que este proceso actualiza los parámetros sin volver a crear ni reiniciar las VMs subyacentes, reduce las interrupciones y acelera la actualización. Las siguientes opciones de linuxConfig aún requieren la estrategia de actualización estándar:

• Modo cgroup de Linux
• Hugepages de Linux
• Sincronización precisa de la hora en Linux
• VFIO de Linux
• Programador de E/S de disco de Linux

Cómo funcionan las novedades en tiempo real

Las novedades en tiempo real funcionan de la siguiente manera para cada configuración compatible:

• Configuración de sysctl: GKE reinicia el servicio systemd sysctl en cada nodo para aplicar los parámetros del kernel en el campo linuxConfig.sysctl. Si actualizas un parámetro sysctl con espacio de nombres, GKE también reinicia el servicio kubelet para actualizar la configuración de sysctl a nivel del Pod. Para conocer los parámetros compatibles, consulta Opciones de configuración de sysctl.
• Configuración de kubelet: GKE reinicia el servicio de kubelet en cada nodo para aplicar los parámetros en el campo kubeletConfig. La mayoría de las opciones de configuración de kubelet admiten actualizaciones en tiempo real. Sin embargo, las opciones cpuManagerPolicy, shutdownGracePeriodSeconds y shutdownGracePeriodCriticalPodsSeconds requieren la estrategia de actualización estándar.

En ambos casos, GKE aplica el cambio en el lugar en los nodos en ejecución sin volver a crear las VMs, expulsar tus Pods ni crear VMs de aumento temporal. GKE usa la suma de la configuración de --max-surge-upgrade y --max-unavailable-upgrade de tu grupo de nodos como el límite de simultaneidad para determinar cuántos nodos existentes se actualizan en paralelo.

Requisitos previos para las novedades en tiempo real

Para usar las novedades en tiempo real, tu clúster y grupo de nodos deben cumplir con los siguientes requisitos previos:

• Ejecuta la versión 1.37.1-gke.1954000 o posterior de GKE.
• Habilita el complemento NodeReadinessController en el clúster. Durante una actualización en vivo, este controlador aplica de forma temporal el reproche readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule a cada nodo que se actualiza para que GKE no programe Pods nuevos en el nodo hasta que se complete la actualización:
  • Para los clústeres nuevos, incluye el complemento NodeReadinessController en la marca --addons durante la creación del clúster. Esta marca habilita solo los complementos que especifiques y, además, inhabilita todos los demás, por lo que también debes incluir los complementos predeterminados que quieras conservar.
  • En el caso de los clústeres existentes, pasa la marca --update-addons=NodeReadinessController=ENABLED durante una actualización del clúster.

Cómo aplicar una actualización en vivo

Para aplicar una actualización en vivo, haz lo siguiente:

1. Crea o modifica el archivo YAML de configuración del sistema de nodos para que contenga la configuración completa del grupo de nodos, incluidos los parámetros de configuración de kubelet o sysctl que deseas cambiar. Para evitar restablecer la configuración que no quieres cambiar, comienza desde la configuración existente del grupo de nodos.

2. Actualiza el grupo de nodos con tu archivo de configuración y establece el valor de la marca --node-config-update-mode en LIVE_UPDATE_WITHOUT_DRAIN:

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

   Reemplaza lo siguiente:

   • POOL_NAME: Es el nombre del grupo de nodos que quieres actualizar.
   • CLUSTER_NAME: Es el nombre del clúster que contiene el grupo de nodos.
   • LOCATION: Es la zona de procesamiento o región del clúster.
   • SYSTEM_CONFIG_PATH: Es la ruta de acceso al archivo YAML que contiene la configuración del sistema de nodos.

3. Verifica que GKE haya aplicado la configuración actualizada a tu grupo de nodos:

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

   En el resultado del comando, se muestran los parámetros de configuración activos en el grupo de nodos en los campos config.kubeletConfig y config.linuxNodeConfig.

4. Opcional: Reinicia tus Pods existentes. La actualización en vivo no interrumpe los Pods en ejecución, por lo que GKE aplica la configuración actualizada solo a los Pods que se inician después de que se completa la actualización. Para aplicar la configuración a una carga de trabajo que ya se está ejecutando, reinicia sus Pods, por ejemplo, ejecutando kubectl rollout restart en el Deployment.

Si una actualización en vivo no se realiza como se esperaba, la ruta de recuperación dependerá de si la operación de actualización finalizó:

• Si la operación de novedades en tiempo real falla, consulta Recuperación de una operación de novedades en tiempo real con errores.
• Si la operación de actualización en vivo se realiza correctamente, pero la configuración nueva provoca un comportamiento no deseado de la carga de trabajo, consulta Revierte una actualización en vivo completada.

Recupérate de una actualización en vivo con errores

Si una actualización en vivo falla en un nodo, GKE detiene el lanzamiento de inmediato y deja el grupo de nodos en un estado de actualización parcial. Para inspeccionar los detalles de la falla, realiza una de las siguientes acciones:

• Ejecuta el comando gcloud container operations describe. En el resultado, el campo statusMessage identifica el nodo en el que fallaron las novedades en tiempo real y el error que informó el nodo, por ejemplo:

  statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
    Live update fails with error: failed to write new kubelet config: ...'
  

• En el Explorador de registros, comprueba si hay errores del componente gke-node-live-update-reconciler en los nodos afectados.

Debido a que una actualización en vivo con errores no cambia la configuración almacenada del grupo de nodos, volver a aplicar la configuración anterior con el comando gcloud container node-pools update no activa una actualización. Después de inspeccionar la falla, elige una de las siguientes opciones de recuperación:

• Corrige el problema y completa la actualización en vivo (recomendado): Resuelve el problema que causó la falla y, luego, vuelve a ejecutar el comando gcloud container node-pools update del procedimiento anterior con tu configuración de destino.
• Revierte a la configuración anterior: Si no puedes resolver el problema, ejecuta el comando gcloud container node-pools rollback para devolver el grupo de nodos a su configuración anterior. A diferencia de una actualización en vivo, este comando vuelve a crear todos los nodos del grupo de nodos, lo que interrumpe las cargas de trabajo que se ejecutan en ellos.

Cómo revertir una actualización en vivo completada

Si una operación de actualización en vivo se realiza correctamente, pero un parámetro de configuración recién aplicado provoca un comportamiento no deseado de la carga de trabajo, revierte el cambio aplicando otra actualización en vivo con tu configuración anterior. Esta actualización en vivo restablece la configuración anterior sin expulsar Pods ni reiniciar nodos. El comando gcloud container node-pools rollback no está disponible después de una operación correcta; solo funciona cuando la operación falla.

Para revertir una actualización en vivo completada, haz lo siguiente:

1. Actualiza el archivo YAML de configuración del sistema de nodos para que contenga la configuración anterior completa del grupo de nodos. Si un parámetro no se configuró anteriormente, establécelo de forma explícita en su valor predeterminado en lugar de omitirlo o dejar la sección vacía. Para conocer los valores predeterminados, consulta Opciones de configuración de Kubelet y Opciones de configuración de Sysctl.

2. Aplica la configuración anterior a tu grupo de nodos:

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

Actualiza con la estrategia de actualización estándar

Usa la estrategia de actualización estándar si actualizas opciones de configuración que no admiten actualizaciones en vivo, si tu clúster o grupo de nodos ejecuta una versión de GKE anterior a la 1.37.1-gke.1954000 o si quieres que GKE vacíe y vuelva a programar automáticamente tus Pods en los nodos recién creados.

Para actualizar un grupo de nodos existente con la estrategia de actualización estándar, ejecuta el siguiente comando:

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

Reemplaza lo siguiente:

• POOL_NAME: El nombre del grupo de nodos que quieres actualizar
• CLUSTER_NAME: Es el nombre del clúster que contiene el grupo de nodos.
• LOCATION: Es la zona de procesamiento o región del clúster.
• SYSTEM_CONFIG_PATH: Es la ruta de acceso al archivo YAML que contiene la configuración del sistema de nodos.

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 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 la 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 ComputeClass nueva 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 actualizadas de la carga de trabajo. El escalador automático del clúster aprovisionará nodos nuevos con la configuración nueva y, con el tiempo, reducirá la escala verticalmente de los nodos antiguos.
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 cambiar la configuración del sistema de nodos de un grupo de nodos existente, consulta Actualiza la configuración del sistema de nodos para un grupo de nodos existente.

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

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 en el 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:

```yaml
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 actualizadas de la carga de trabajo. GKE vuelve a crear las cargas de trabajo en los nodos predeterminados. Con el tiempo, el escalador automático del clúster 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.

kubelet parámetro de configuración	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 CPU, cpu.cfs_period_us, que especifica el período de la frecuencia con la que se debe reasignar el acceso de un cgroup a los recursos de CPU. Esta opción te permite ajustar el comportamiento de limitación de CPU.
reservedSystemCPUs (Versión preliminar)	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). Debido a que los núcleos se indexan desde cero, los valores deben ser menores que la cantidad de CPU virtuales en el 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 a los núcleos reservados en el inicio del nodo. Reservar las CPU 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. Debido a 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 en condiciones de carga alta, lo que puede causar inestabilidad o pérdida de paquetes de red.

Administración de la memoria y expulsión

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

kubelet parámetro 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 expulsión suave. 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 suave. Cada umbral de expulsión suave 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 el kubelet reclama cuando expulsa un 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 los nodos de cgroupv1 y false para los 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ámetro 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 de la expulsión suave. Define la cantidad de señal de memory.available en 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 señal de nodefs.available en kubelet .
nodefsInodesFree	El valor debe estar entre 5% y 50%.	none	Este parámetro de configuración representa los inodos de nodefs que están libres antes de la expulsión suave. Define la cantidad de señal de nodefs.inodesFree en kubelet .
imagefsAvailable	El valor debe estar entre 15% y 50%.	none	Este parámetro de configuración representa el imagefs disponible antes de la expulsión suave. Define la cantidad de señal de imagefs.available en kubelet .
imagefsInodesFree	El valor debe estar entre 5% y 50%.	none	Este parámetro de configuración 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 kubelet.
pidAvailable	El valor debe estar entre 10% y 50%.	none	Este parámetro de configuración representa los PID disponibles antes de la expulsión suave. Define la cantidad de la señal pid.available en kubelet.

Administración de PID

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

kubelet parámetro de configuración	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 modificables para el registro.

kubelet parámetro de configuración	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 (ambas cifras incluidas).	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.

kubelet parámetro de configuración	Restricciones	Parámetro de configuración predeterminado	Descripción
imageGcHighThresholdPercent	El valor debe ser un número entero entre 10 y 85, inclusive, 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 de tiempo no superior a 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 edad mínima de una imagen sin usar antes de que se recopile como elemento no utilizado.
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 recopile como elemento no utilizado. El valor predeterminado de este campo es 0s, lo que lo inhabilita. Por lo tanto, las imágenes no se someterán a la recolección de elementos no utilizados por no usarse. 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 parámetro de configuración	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.

kubelet parámetro de configuración	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 de 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 puerto de solo lectura no seguro kubelet 10255 en cada grupo de nodos nuevo de tu clúster. Si estableces este parámetro en este archivo, no puedes usar un cliente de API de GKE para cambiarlo a nivel de 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 los nodos para los Pods que se configuran con requisitos específicos de CPU, dispositivos y memoria (hugepages).

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

kubelet parámetro 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 administrador de CPU de kubelet. El valor predeterminado es none, que es el esquema de afinidad de CPU predeterminado, que no proporciona afinidad más allá de lo que hace automáticamente el programador del SO. Establecer este valor en static permite que los Pods que están en la clase de QoS Guaranteed y tienen solicitudes de CPU de números enteros se asignen a CPU exclusivas.
memoryManager.policy	El valor debe ser None o Static.	None	Este parámetro de configuración controla la política del administrador de memoria de kubelet. Con el valor predeterminado de None, Kubernetes actúa de la misma manera que si el administrador de memoria no estuviera presente. Si estableces este valor en Static, la política del administrador de memoria envía sugerencias de topología que dependen del tipo de Pod. Para obtener más información, consulta Política estática. Este parámetro de configuración es compatible con los clústeres con el plano de control que ejecuta la versión 1.32.3-gke.1785000 o posterior de GKE.
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 de Standard.	policy: none scope: container	Estos parámetros controlan la configuración del administrador de topología de kubelet con los campos secundarios 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 alcance 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 una 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 un contenedor se encuentra en un estado CrashLoopBackOff. Puedes establecer este parámetro de configuración para los grupos de nodos de Standard que ejecutan la versión 1.35 o posterior de GKE.

Precaución: Un retraso muy corto 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ámetro 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ámetro 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 cierre 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 establece 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.

kubelet parámetro de configuración	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.	Es la 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 una posterior, y menor que el 50% de la capacidad total de CPU del nodo.	Consulta Reservas de CPU.	Es 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 controladores 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 relojes 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 para el 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, 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 de 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 de software.
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: Sin ptrace. No se permiten las llamadas ptrace.
kernel.kptr_restrict	Debe ser entre [0, 2].	Este parámetro de configuración 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 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: máscara de bits de las funciones sysrq permitidas. Para obtener más información, consulta Trucos de la tecla 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 que no es raíz puede conservar 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 que no sea raíz.

Parámetros de red (net.*)

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

Parámetro de 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 de 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, menor que 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, menor que 2147483647.	Este parámetro de configuración define la cantidad máxima de paquetes, en cola en el lado de ENTRADA, 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 socket de recepción, en bytes.
net.core.rmem_max	Cualquier número entero positivo, menor que 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 valor predeterminado, en bytes, del búfer de envío del socket.
net.core.wmem_max	Cualquier número entero positivo, menor que 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 lista de tareas pendientes de socket listen(), que se conoce en el espacio de 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. La configuración predeterminada es de 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 conectados a ningún manejo de archivos de 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. La 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 se admite 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 también 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 estar entre {0, 1}.	Este parámetro de configuración habilita la contabilidad 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 o 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 ser un valor 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 o posteriores de GKE.
net.ipv4.neigh.default.gc_thresh1	Debe estar 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 elementos no utilizados no se ejecuta si la cantidad de entradas es inferior a este parámetro de configuración. Si estableces este valor en 0, se puede producir una sobrecarga de la 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 que comience la recolección de elementos no utilizados de forma no estricta.
net.ipv4.neigh.default.gc_thresh3	Debe estar entre [1024, 1048576].	Este parámetro de configuración define la cantidad máxima estricta de entradas que se deben mantener en la caché de ARP. El recolector de elementos no utilizados está diseñado para ejecutarse siempre que la cantidad de entradas supere 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 administra la memoria, el intercambio y la memoria 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 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 subprocesos de vaciado del kernel en segundo plano comiencen la reescritura. El valor debe ser menor que el 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 inician la reescritura. 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, 1000].	Este parámetro de configuración define el intervalo, en centésimas de segundo, en el que los subprocesos de vaciado del kernel se activan para escribir datos sucios antiguos en el disco.
vm.overcommit_memory	Debe ser {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, 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 ser un valor 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 inode.
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 de --system-config-from-file.

Los diferentes espacios de nombres de Linux pueden tener valores únicos para un parámetro sysctl determinado, pero 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 dará de baja 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 realiza 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 de 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 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 las 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 Container-Optimized OS con containerd o Ubuntu con la imagen de nodo 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

En el resultado, solo se muestra la configuración nueva de cgroup después de que se vuelven a crear los nodos en el grupo de nodos. El resultado está vacío 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 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 hugepages de Linux

Puedes usar páginas gigantes preasignadas de forma manual o páginas gigantes 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 asignadas previamente 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 ninguno de los siguientes valores:
  • 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 de las páginas grandes de Linux.

Parámetro de configuración	Restricciones	Valor predeterminado	Descripción
hugepage_size2m	Es un 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 grandes de 2 MB.
hugepage_size1g	Es un recuento de números enteros. Sujeto a las limitaciones de memoria y tipo de máquina descritas anteriormente.	0	Este parámetro de configuración asigna previamente una cantidad específica de páginas gigantes de 1 GB.

Hugepages 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 de forma automática páginas grandes a los procesos sin una asignación previa 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: La página gigante transparente está habilitada en todo el sistema. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: La página gigante transparente está habilitada dentro de las regiones 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 activar 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 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_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 entra en 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 precisa de la hora está disponible en GKE versión 1.36.0-gke.3241000 y posteriores. 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 habilita la sincronización precisa de la hora. 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 analizar el rendimiento y la confiabilidad de la sincronización de la 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 Monitoring que agrega los datos de error de la métrica basada en registros y la métrica de exactitud de 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 al dispositivo, 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 de 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 1.36.0-gke.3009000 o posteriores de GKE.

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