Lo mejor de dos mundos: workloads en modo Autopilot dentro de GKE Standard

Estos son algunos de los problemas que enfrentan las organizaciones con clusters puramente Standard o puramente Autopilot, y por qué ninguno de los dos modos basta por sí solo.

• Carga operativa en clusters Standard: tienes control total, pero también asumes la responsabilidad del escalado, el mantenimiento y la seguridad, algo que puede ser exigente para equipos pequeños.
• Pérdida de flexibilidad en clusters Autopilot: aunque Autopilot te da más operaciones gestionadas, también impone restricciones: solicitudes mínimas de recursos, imágenes de SO específicas, menos control sobre la configuración de los nodos, etc.
• Costos y facturación: en un cluster Standard pagas por las máquinas virtuales (VMs) que componen tus node pools, sin importar si tus workloads están aprovechando o no todos los recursos disponibles. Si no se administra con cuidado, esto puede derivar en sobreaprovisionamiento y costos innecesarios.

Por eso, muchas organizaciones se han visto obligadas a elegir entre el modo Standard completo (flexible, pero con más mantenimiento) o el modo Autopilot completo (menos mantenimiento, pero menos control y más restricciones). Ninguna opción resulta ideal cuando hay workloads mixtos.

El mecanismo de "Autopilot ComputeClasses en clusters Standard" de GKE se apoya en las ComputeClasses (un recurso personalizado de Kubernetes que define una lista de configuraciones de nodos, como tipos de máquina o ajustes de funcionalidades) para hacer posible este modelo híbrido, que aporta un nuevo nivel de flexibilidad y varios beneficios clave.

El modo Autopilot dentro de Standard se construye sobre una nueva base de plataforma de cómputo optimizada para contenedores, diseñada para ofrecer mínima latencia y máximo rendimiento. Este nuevo cómputo optimizado para contenedores consigue tiempos de programación de pods hasta 7 veces más rápidos, mejorando de forma significativa los tiempos de respuesta de las aplicaciones para los workloads configurados con Autopilot ComputeClasses.

Otros beneficios clave:

• Ejecutar workloads específicos en modo Autopilot, totalmente gestionados por Google.
• Conservar el control manual sobre los workloads y la infraestructura que no usen el modo Autopilot, como los node pools creados manualmente.
• Definir una Autopilot ComputeClass como predeterminada para tu cluster o namespace, de modo que los workloads hereden los beneficios de Autopilot salvo que se indique lo contrario.

Requisitos y limitaciones

¿Te resulta interesante? Revisa los requisitos y limitaciones antes de habilitar workloads de Autopilot dentro de un cluster Standard.

• Los nodos de Autopilot tienen reglas estrictas de funcionalidades y seguridad. Los workloads Standard pueden ser rechazados si no cumplen estos requisitos, así que revisa la configuración de los nodos para asegurar la compatibilidad.
• El cluster debe estar registrado en el canal de lanzamiento Rapid y ejecutar la versión 1.33.1-gke.1107000 o posterior.
• El canal Rapid incorpora funcionalidades y nuevas versiones de Kubernetes con mayor rapidez, pero también puede traer cambios disruptivos. Revisa y corrige cualquier cambio en la API u otros antes de actualizar el cluster.
• Al menos un node pool del cluster debe estar libre de node taints para ejecutar los pods de sistema estándar.
• El cluster debe ser VPC-native, con Shielded GKE Nodes habilitados de forma predeterminada.

Autopilot ComputeClasses integradas

GKE configura automáticamente los recursos personalizados autopilot y autopilot-spot de ComputeClasses una vez que el cluster se actualiza a una versión compatible.

Ejemplo de Autopilot ComputeClasses

Para seleccionar una Autopilot ComputeClass en un workload, usa un node selector con la etiqueta cloud.google.com/compute-class.

#Workload de ejemplo que usa una Autopilot ComputeClass integrada
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      nodeSelector:
        # Reemplaza COMPUTE_CLASS con el nombre de la compute class a usar.
        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: "4Gi"

Los recursos del contenedor se ajustan automáticamente para cumplir con los requisitos de Autopilot y se programan en nodos de la plataforma de cómputo optimizada para contenedores.

ComputeClasses personalizadas

Si las ComputeClasses integradas no cubren tus necesidades, puedes crear Autopilot ComputeClasses personalizadas a la medida de workloads específicos. Esto resulta especialmente útil para workloads que requieren GPUs o ciertas familias de máquinas.

Si ya estás usando ComputeClasses personalizadas y quieres actualizar los recursos ComputeClass existentes del cluster para que usen el modo Autopilot, debes recrear esa ComputeClass con una especificación actualizada. Para más información, consulta Habilitar Autopilot para una ComputeClass personalizada existente.

#ComputeClass personalizada de ejemplo con modo autopilot habilitado
---
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: autopilot-n2-class
spec:
  autopilot:
    enabled: true
  priorities:
  - machineFamily: n2
    spot: true
    minCores: 64
  - machineFamily: n2
    spot: true
  - machineFamily: n2
    spot: false
  activeMigration:
    optimizeRulePriority: true
  whenUnsatisfiable: DoNotScaleUp

No puedes usar la regla de prioridad podFamily en tus propias ComputeClasses. Esa regla solo está disponible en las Autopilot ComputeClasses integradas.

Puedes usar las ComputeClasses personalizadas con el modo Autopilot habilitado para definir una compute class predeterminada a nivel de cluster de GKE o de namespace. La clase predeterminada que configures se aplicará a cualquier Pod de ese cluster o namespace que no especifique otra compute class. Cuando despliegas un Pod sin compute class definida, GKE aplica las compute classes predeterminadas en este orden:

1. Si el namespace tiene una compute class predeterminada, GKE modifica la especificación del Pod para seleccionar esa compute class.
2. Si no, se aplica la configuración predeterminada del cluster, en caso de estar configurada, y GKE no modifica el Pod.

Para más detalles, consulta el enlace.