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

Puedes usar las ComputeClasses Balanced y Scale-Out en los clústeres de Autopilot de Google Kubernetes Engine (GKE) para ejecutar cargas de trabajo que requieren capacidad de procesamiento adicional o parámetros de configuración de CPU especializados. 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 ComputeClasses Balanced y Scale-Out

De forma predeterminada, los Pods de 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 optimizada para contenedores predeterminada:

  • Balanced: Proporciona una capacidad máxima de CPU y memoria más alta 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 optimizada para contenedores predeterminada, Autopilot administra el tamaño de los nodos y la asignación de recursos en función de tus Pods en ejecución.

ComputeClasses personalizadas para mayor flexibilidad

Si las clases de procesamiento equilibradas o de escalamiento 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 de ComputeClass en tus clústeres con conjuntos de atributos de nodo que GKE usa para configurar nodos nuevos en el clúster. Estas ComputeClasses personalizadas pueden, por ejemplo, permitirte 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 coloca los Pods en la plataforma de procesamiento optimizada para contenedores de forma predeterminada. 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 que se pueden cambiar de tamaño. Debido a 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 conectado depende de la compatibilidad del tipo de disco:

  • Discos persistentes heredados: Los Pods con discos persistentes heredados conectados (como pd-standard) se ejecutan solo en series de máquinas que los admiten, como E2.
  • Hyperdisk: Los Pods con almacenamiento de nueva generación conectado (como hyperdisk-balanced) se ejecutan en series de máquinas más nuevas, como C3.
  • Estado pendiente: Si configuras de forma explícita un Pod para que se ejecute en una serie de máquinas más nueva (por ejemplo, con selectores de nodos para solicitar nodos C3 o con la configuración de una ComputeClass personalizada), pero conectas 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 del disco. Cuando seleccionas de forma explícita una serie de máquinas, eres responsable de garantizar la compatibilidad de PersistentVolume y del disco.

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

ComputeClasses Balanced y Scale-Out
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 una versión 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:
    • El SMT está inhabilitado, 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 las 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 una 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 un 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 ComputeClass 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 tu especificación de carga de trabajo, Autopilot programa Pods en nodos que usan la plataforma de procesamiento predeterminada optimizada para contenedores. La mayoría de las cargas de trabajo de uso general se pueden ejecutar 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 disco persistente SSD (pd-ssd), en series de máquinas que no los admiten. El uso de almacenamiento incompatible puede hacer que los Pods permanezcan en el estado Pending si GKE no puede encontrar ni aprovisionar un nodo que cumpla con todas las restricciones. Si se programa un Pod, pero el almacenamiento no se conecta ni se activa, el Pod permanece en el estado ContainerCreating. Para obtener más información sobre cómo solucionar problemas de compatibilidad de almacenamiento, consulta La carga de trabajo se programó en una serie de máquinas más antigua o se detuvo en el estado Pending debido a una 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 ComputeClass de escalamiento horizontal admite varias arquitecturas de CPU. Puedes solicitar una arquitectura específica junto con tu solicitud de ComputeClass especificando 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 la 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 especificada.

Si no solicitas una arquitectura de manera explícita, Autopilot usa la arquitectura predeterminada de la 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?