Acerca de las clases de procesamiento equilibradas y de expansión en los clústeres de Autopilot

Puedes usar Balanced y Scale-Out ComputeClasses en clústeres de Google Kubernetes Engine (GKE) Autopilot para ejecutar cargas de trabajo que requieren capacidad de procesamiento adicional o configuraciones de CPU especializadas. Esta página está destinada a los administradores de clústeres que desean opciones de procesamiento más flexibles que las que proporciona la configuración predeterminada del clúster de Autopilot.

Descripción general de las clases de procesamiento balanceadas y de expansión

De forma predeterminada, los Pods en los clústeres de GKE Autopilot se ejecutan en una plataforma de procesamiento optimizada para contenedores. Esta plataforma es ideal para cargas de trabajo de uso general, como servidores web y trabajos por lotes de intensidad media. La plataforma de procesamiento optimizada para contenedores proporciona una configuración de hardware confiable, escalable y con optimización de costos que puede manejar los requisitos de la mayoría de las cargas de trabajo.

Si tienes cargas de trabajo que tienen requisitos de hardware únicos (como realizar tareas de IA o aprendizaje automático, ejecutar bases de datos de tráfico alto en tiempo real o necesitar arquitecturas y plataformas de CPU específicas), puedes usar ComputeClasses para aprovisionar ese hardware.

Solo en los clústeres de Autopilot, GKE proporciona las siguientes ComputeClasses seleccionadas que te permiten ejecutar Pods que necesitan más flexibilidad que la plataforma de procesamiento predeterminada optimizada para contenedores:

  • Balanced: Proporciona una mayor capacidad máxima de CPU y memoria que la plataforma de procesamiento optimizada para contenedores.
  • Scale-Out: Inhabilita el multiprocesamiento simultáneo (SMT) y está optimizada para el escalamiento horizontal.

Estas ComputeClasses solo están disponibles en clústeres de Autopilot. De manera similar a la plataforma de procesamiento predeterminada optimizada para contenedores, Autopilot administra el tamaño de los nodos y la asignación de recursos en función de tus Pods en ejecución.

Clases de procesamiento personalizadas para mayor flexibilidad

Si las clases de procesamiento equilibradas o de expansión horizontal en los clústeres de Autopilot no cumplen con los requisitos de tu carga de trabajo, puedes configurar tus propias clases de procesamiento. Implementas recursos personalizados de Kubernetes ComputeClass en tus clústeres con conjuntos de atributos de nodos que GKE usa para configurar nodos nuevos en el clúster. Por ejemplo, estas ComputeClasses personalizadas te permiten implementar cargas de trabajo en el mismo hardware que las ComputeClasses Balanced o Scale-Out en cualquier clúster de GKE Autopilot o Standard. Para obtener más información, consulta Acerca de las cargas de trabajo del modo Autopilot en GKE Standard.

Precios

Los Pods que usan las ComputeClasses Balanced o Scale-Out se facturan según los siguientes SKUs:

Para obtener más información, consulta Precios de GKE.

Detalles técnicos de Balanced y Scale-Out

En esta sección, se describen los tipos de máquinas y los casos de uso de las clases Balanced y Scale-Out. Si no solicitas una ComputeClass en tus Pods, Autopilot los colocará de forma predeterminada en la plataforma de procesamiento optimizada para contenedores. La plataforma de procesamiento optimizada para contenedores usa cualquiera de las series de máquinas de la familia de máquinas de uso general de Compute Engine, con preferencia por los tipos de máquinas redimensionables. Dado que la serie de máquinas subyacente no es fija, el rendimiento por CPU varía según la serie de máquinas en la que GKE programa tu Pod.

Además, la programación de Pods con almacenamiento persistente adjunto depende de la compatibilidad del tipo de disco:

  • Discos persistentes heredados: Los Pods con discos persistentes heredados conectados (como pd-standard) solo se ejecutan en series de máquinas que los admiten, como E2.
  • Hyperdisk: Los Pods con almacenamiento de nueva generación adjunto (como hyperdisk-balanced) se ejecutan en series de máquinas más nuevas, como C3.
  • Estado pendiente: Si configuras explícitamente un Pod para que se ejecute en una serie de máquinas más reciente (por ejemplo, usando selectores de nodos para solicitar nodos C3 o configurando una ComputeClass personalizada), pero adjuntas un Persistent Disk heredado, el Pod permanecerá en el estado Pending de forma indefinida. Esto ocurre porque GKE no puede encontrar un nodo que satisfaga las restricciones de compatibilidad del tipo de máquina y el disco. Cuando seleccionas explícitamente una serie de máquinas, eres responsable de garantizar la compatibilidad del PersistentVolume y el disco.

En la siguiente tabla, se proporciona una descripción general técnica de las clases de procesamiento Balanced y Scale-Out.

ComputeClasses balanceadas y de escalamiento horizontal
Balanced

Proporciona más capacidad de CPU y memoria que los valores máximos de la plataforma de procesamiento optimizada para contenedores. Proporciona plataformas de CPU adicionales y la capacidad de establecer plataformas de CPU mínimas para Pods, como Intel Ice Lake o posterior.

  • CPU disponibles: AMD EPYC Milan, Intel Ice Lake, Intel Cascade Lake
  • Arquitectura disponible: amd64
  • Serie de máquinas: N2 (CPU de Intel) o serie de máquinas N2D (CPU de AMD).

Usa la clase Balanced para aplicaciones como las siguientes:

  • Servidores web
  • Bases de datos medianas a grandes
  • Almacenamiento en caché
  • Transmisión y entrega de contenido multimedia
  • Almacenamiento Hyperdisk Throughput y Extreme
Scale-Out

Proporciona procesamiento de un solo subproceso por núcleo y escalamiento horizontal.

  • CPU disponibles: Ampere Altra Arm o AMD EPYC Milan
  • Arquitectura disponible: arm64 o amd64
  • Serie de máquinas: T2A (Arm) o T2D (x86).
  • Funciones adicionales:
    • Los SMT están inhabilitados, por lo que una CPU virtual equivale a un núcleo físico.
    • Velocidad de reloj máxima de 3.5 GHz

Usa la clase Scale-Out para aplicaciones como las siguientes:

  • Servidores web
  • Microservicios en contenedores
  • Procesamiento de registros de datos
  • Apps de Java a gran escala
  • Almacenamiento Hyperdisk Throughput

Selección de ComputeClass en cargas de trabajo

Para usar una ComputeClass en una carga de trabajo de GKE, selecciona la ComputeClass en el manifiesto de la carga de trabajo con un selector de nodos para la etiqueta cloud.google.com/compute-class.

En el siguiente ejemplo de manifiesto de Deployment, se selecciona un ComputeClass:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Replace with the name of a compute class
        cloud.google.com/compute-class: COMPUTE_CLASS 
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "1Gi"

Reemplaza COMPUTE_CLASS por el nombre de una ComputeClass, como Balanced o Scale-Out. Puedes seleccionar un máximo de una ComputeClass en una carga de trabajo.

Cuando implementas la carga de trabajo, GKE hace lo siguiente:

  • Aprovisiona de forma automática los nodos respaldados por la configuración especificada para ejecutar tus Pods.
  • Agrega automáticamente etiquetas de nodo y taints a los nodos nuevos para evitar que otros Pods se programen en esos nodos. Los taints son únicos para cada ComputeClass. Si también seleccionas una arquitectura de CPU, GKE agrega un taint independiente a esa arquitectura.
  • Agrega automáticamente tolerancias correspondientes a los taints aplicados a tus Pods implementados, lo que permite que GKE coloque esos Pods en los nodos nuevos.

Por ejemplo, si solicitas la clase de procesamiento Scale-Out para un Pod:

  1. Autopilot agrega un taint específico a Scale-Out para esos nodos.
  2. Autopilot agrega una tolerancia para ese taint a los Pods Scale-Out.

Los Pods que no solicitan Scale-Out no recibirán la tolerancia. Como resultado, GKE no programará esos Pods en los nodos Scale-Out.

Si no solicitas de manera explícita una ComputeClass en la especificación de tu carga de trabajo, Autopilot programa Pods en nodos que usan la plataforma de procesamiento optimizada para contenedores predeterminada. La mayoría de las cargas de trabajo de uso general pueden ejecutarse sin problemas en esta plataforma.

Si usas ComputeClasses o solicitas series de máquinas específicas, asegúrate de que tus cargas de trabajo no usen almacenamiento incompatible. Por ejemplo, no uses tipos de volúmenes de Persistent Disk anteriores, como los volúmenes de disco persistente estándar (pd-standard) o de disco persistente SSD (pd-ssd), en series de máquinas que no los admitan. El uso de almacenamiento incompatible puede hacer que los Pods permanezcan en el estado Pending si GKE no puede encontrar o aprovisionar un nodo que satisfaga todas las restricciones. Si se programa un Pod, pero el almacenamiento no se puede adjuntar o montar, el Pod permanece en el estado ContainerCreating. Para obtener más información sobre la solución de problemas de compatibilidad de almacenamiento, consulta La carga de trabajo se programó en una serie de máquinas más antiguas o se quedó en el estado Pending debido a la incompatibilidad de almacenamiento.

Cómo solicitar una arquitectura de CPU

En algunos casos, tus cargas de trabajo pueden compilarse para una arquitectura específica, como Arm. La clase de procesamiento Scale-Out admite varias arquitecturas de CPU. Puedes solicitar una arquitectura específica junto con tu solicitud de ComputeClass si especificas una etiqueta en tu selector de nodos o en la regla de afinidad de nodos, como en el siguiente ejemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-arm
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-arm
  template:
    metadata:
      labels:
        app: nginx-arm
    spec:
      nodeSelector:
        cloud.google.com/compute-class: COMPUTE_CLASS
        kubernetes.io/arch: ARCHITECTURE
      containers:
      - name: nginx-arm
        image: nginx
        resources:
          requests:
            cpu: 2000m
            memory: 2Gi

Reemplaza ARCHITECTURE por la arquitectura de CPU que desees, como arm64 o amd64. Puedes seleccionar un máximo de una arquitectura en tu carga de trabajo. La ComputeClass que selecciones debe admitir la arquitectura que especificaste.

Si no solicitas una arquitectura de manera explícita, Autopilot usa la arquitectura predeterminada de ComputeClass.

Arquitectura de Arm en Autopilot

Autopilot admite solicitudes de nodos que usan la arquitectura de CPU Arm. Los nodos Arm son más rentables que los nodos x86 similares y ofrecen mejoras de rendimiento. Si deseas obtener instrucciones para solicitar nodos de Arm, consulta Implementa cargas de trabajo de Autopilot en la arquitectura de Arm.

Asegúrate de usar las imágenes correctas en tus implementaciones. Si tus Pods usan imágenes de Arm y no solicitas nodos de Arm, Autopilot programa los Pods en nodos x86 y los Pods fallarán. Del mismo modo, si usas imágenes x86 por accidente, pero solicitas nodos Arm para los Pods, los Pods fallarán.

Solicitudes de recursos predeterminadas, mínimas y máximas

Cuando elijas una ComputeClass para tus cargas de trabajo de Autopilot, asegúrate de especificar solicitudes de recursos que cumplan con las solicitudes mínimas y máximas de esa ComputeClass. Para obtener información sobre las solicitudes predeterminadas y las solicitudes mínimas y máximas para cada ComputeClass, consulta Solicitudes y límites de recursos en GKE Autopilot.

¿Qué sigue?