Ejecutar cargas de trabajo de Arm en GKE en AWS

GKE on AWS te permite ejecutar cargas de trabajo de Arm creadas para procesadores AWS Graviton basados en Arm.

Limitaciones

  • Los grupos de nodos de Arm que ejecuten versiones de Kubernetes anteriores a la 1.24.8-gke.1300 añadirán automáticamente un 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 posterior ya no añaden este taint. Si vas a actualizar un clúster anterior a la versión 1.24.8-gke.1300, debes crear este taint o tenerlo en cuenta al actualizar.

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

  • Los clústeres que ejecuten la versión 1.24 de Kubernetes necesitan un grupo de nodos x86 para ejecutar el agente de conexión. Si tu clúster ejecuta la versión 1.25 de Kubernetes o una posterior, no necesitas un grupo de nodos x86.

En esta página se explica cómo crear un grupo de nodos Arm, por qué las imágenes de varias arquitecturas son la forma recomendada de desplegar cargas de trabajo Arm y cómo programar cargas de trabajo Arm.

Antes de empezar

Antes de crear grupos de nodos para tus cargas de trabajo de Arm, necesitas los siguientes recursos:

Crear un grupo de nodos Arm

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

Para crear un grupo de nodos Arm y añadirlo a un clúster, ejecuta 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

Haz los cambios siguientes:

  • NODE_POOL_NAME: el nombre que elijas para tu grupo de nodos
  • CLUSTER_NAME: el nombre del clúster al que se va a 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 AWS Graviton basados en Arm. También debe especificar el tamaño de la instancia que quiera. Por ejemplo, m6g.medium. Para ver una lista completa, consulta Tipos de instancias de AWS admitidos.

  • ROOT_VOLUME_SIZE: tamaño deseado del volumen raíz de cada nodo, en GB.

  • NODEPOOL_PROFILE: el perfil de instancia de gestión de identidades y accesos de las VMs del grupo de nodos

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

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

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

  • MAX_PODS_PER_NODE: el número máximo de pods que se pueden crear en cualquier nodo del grupo.

  • GOOGLE_CLOUD_LOCATION: el nombre de la Google Cloud

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

  • NODEPOOL_SUBNET: el ID de la subred en la que se ejecutará el grupo de nodos. Si esta subred está fuera del bloque CIDR principal de la VPC, debes seguir pasos adicionales. Para obtener más información, consulta Grupos de seguridad.

  • SSH_KEY_PAIR_NAME: 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 de AWS KMS que cifra los datos de usuario.

Información sobre las imágenes de varias arquitecturas

Las imágenes de contenedor deben ser compatibles con la arquitectura del nodo en el que quieras ejecutar las cargas de trabajo de Arm. Para asegurarte de que tu imagen de contenedor sea compatible con Arm, te recomendamos que utilices imágenes de varias arquitecturas ("multi-arch").

Una imagen multiarquitectura es una imagen que puede admitir varias arquitecturas. Parece una sola imagen con una sola etiqueta, pero contiene un conjunto de imágenes que se ejecutan en diferentes arquitecturas de máquina. Las imágenes de varias arquitecturas son compatibles con las especificaciones del esquema 2 de Manifest V2 de imágenes de Docker o del índice de imágenes de OCI.

Cuando despliegas una imagen de varias arquitecturas en un clúster, el tiempo de ejecución del contenedor elige automáticamente la imagen que es compatible con la arquitectura del nodo en el que estás haciendo el despliegue. Una vez que tengas una imagen de varias arquitecturas para una carga de trabajo, podrás desplegarla en varias arquitecturas. Si se programa una imagen de una sola arquitectura en un nodo incompatible, se produce un error en el tiempo de carga.

Para obtener más información sobre cómo usar imágenes multiarquitectura con cargas de trabajo de Arm, consulta el artículo Crear imágenes multiarquitectura para cargas de trabajo de Arm en la documentación de Google Kubernetes Engine (GKE).

Siguientes pasos