Ejecutar cargas de trabajo de Arm en GKE en AWS

GKE en AWS le permite ejecutar cargas de trabajo Arm creadas para procesadores AWS Graviton basados ​​en Arm.

Limitaciones

  • Los grupos de nodos de Arm que ejecutan versiones de Kubernetes anteriores a la 1.24.8-gke.1300 agregan automáticamente una condición de taint durante la creación del grupo de nodos para evitar que las cargas de trabajo de Arm se programen en nodos que no sean de Arm. Los grupos de nodos de Arm en clústeres con la versión 1.24.8-gke.1300 o superior ya no agregan esta condición de taint. Si actualiza desde un clúster anterior a la 1.24.8-gke.1300, debe crear esta condición de taint usted mismo o tenerla en cuenta al actualizar.

  • Los grupos de nodos de Arm en GKE en AWS no son compatibles con Cloud Service Mesh, Config Sync ni Policy Controller. Debe ejecutar estos productos en un grupo de nodos x86.

  • Los clústeres que ejecutan la versión 1.24 de Kubernetes necesitan un grupo de nodos x86 para ejecutar el Agente de Conexión . Si su clúster ejecuta la versión 1.25 o posterior de Kubernetes, no necesita un grupo de nodos x86.

Esta página explica cómo crear un grupo de nodos de Arm, por qué las imágenes de múltiples arquitecturas son la forma recomendada de implementar cargas de trabajo de Arm y cómo programar cargas de trabajo de Arm.

Antes de empezar

Antes de crear grupos de nodos para sus cargas de trabajo de Arm, necesita los siguientes recursos:

  • Un clúster de AWS existente para crear el grupo de nodos. Este clúster debe ejecutar Kubernetes versión 1.24 o posterior.
  • Un perfil de instancia de IAM para las máquinas virtuales del grupo de nodos.
  • Una subred donde se ejecutarán las máquinas virtuales del grupo de nodos.

  • Si su clúster ejecuta Kubernetes versión 1.24, un grupo de nodos x86 para ejecutar Connect Agent .

    Para obtener detalles sobre cómo crear un grupo de nodos en GKE en AWS, consulte Crear un grupo de nodos .

Crear un grupo de nodos Arm

GKE en AWS admite grupos de nodos creados en la imagen de nodo mínima arm64 de Ubuntu de Canonical y el entorno de ejecución containerd .

Para crear un grupo de nodos Arm y agregarlo a un clúster existente, ejecute el siguiente comando:

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN

Reemplace lo siguiente:

  • NODE_POOL_NAME : el nombre que elija para su grupo de nodos
  • CLUSTER_NAME : el nombre del clúster al que se adjuntará el grupo de nodos

  • INSTANCE_TYPE : uno de los siguientes tipos de instancia:

    • m6g
    • m6gd
    • t4g
    • r6g
    • r6gd
    • c6g
    • c6gd
    • c6gn
    • x2gd
    • c7g
    • im4gn

    • g5g

      Estos tipos de instancias se basan en procesadores Graviton de AWS basados ​​en Arm. También debe especificar el tamaño de instancia deseado. Por ejemplo, m6g.medium . Para obtener una lista completa, consulte Tipos de instancias de AWS compatibles .

  • ROOT_VOLUME_SIZE : el tamaño deseado para el volumen raíz de cada nodo, en Gb

  • NODEPOOL_PROFILE : el perfil de instancia de IAM para las máquinas virtuales del grupo de nodos

  • NODE_VERSION : la versión de Kubernetes que se instalará en cada nodo del grupo de nodos, que debe ser la 1.24 o posterior. Por ejemplo, 1.24.3-gke.200 .

  • MIN_NODES : el número mínimo de nodos que puede contener el grupo de nodos

  • MAX_NODES : el número máximo de nodos que puede contener el grupo de nodos

  • MAX_PODS_PER_NODE : la cantidad máxima de pods que se pueden crear en cualquier nodo individual del grupo

  • GOOGLE_CLOUD_LOCATION : el nombre de la Google Cloud

    Ubicación desde la que se administrará este grupo de nodos

  • NODEPOOL_SUBNET : ID de la subred donde se ejecutará el grupo de nodos. Si esta subred está fuera del bloque CIDR principal de la VPC, deberá realizar pasos adicionales. Para obtener más información, consulte los grupos de seguridad .

  • SSH_KEY_PAIR_NAME : el nombre del par de claves SSH de AWS creado para el acceso SSH (opcional)

  • CONFIG_KMS_KEY_ARN : el nombre de recurso de Amazon (ARN) de la clave AWS KMS que cifra los datos del usuario

Comprender imágenes multiarquitectura

Las imágenes de contenedor deben ser compatibles con la arquitectura del nodo donde se ejecutarán las cargas de trabajo de Arm. Para garantizar que su imagen de contenedor sea compatible con Arm, le recomendamos utilizar imágenes multiarquitectura.

Una imagen multiarquitectura es compatible con múltiples arquitecturas. Parece una sola imagen con una sola etiqueta, pero contiene un conjunto de imágenes para ejecutarse en diferentes arquitecturas de máquina. Las imágenes multiarquitectura son compatibles con el Esquema 2 del Manifiesto de Imagen de Docker V2 o las Especificaciones del Índice de Imagen OCI.

Al implementar una imagen multiarquitectura en un clúster, el entorno de ejecución del contenedor selecciona automáticamente la imagen compatible con la arquitectura del nodo donde se implementa. Una vez que se tiene una imagen multiarquitectura para una carga de trabajo, se puede implementar en múltiples arquitecturas. Programar una imagen de una sola arquitectura en un nodo incompatible provoca un error al cargar.

Para obtener más información sobre cómo usar imágenes de múltiples arquitecturas con cargas de trabajo de Arm, consulte Crear imágenes de múltiples arquitecturas para cargas de trabajo de Arm en la documentación de Google Kubernetes Engine (GKE).

¿Qué sigue?