Ejecuta cargas de trabajo de Arm en GKE en AWS

GKE en AWS te permite ejecutar cargas de trabajo de Arm compiladas para Procesadores AWS Graviton basados en Arm.

Limitaciones

  • Los grupos de nodos Arm que ejecutan versiones de Kubernetes anteriores a 1.24.8-gke.1300 agregan un taint automáticamente durante la creación del grupo de nodos para evitar que las cargas de trabajo 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 este taint. Si actualizas desde un clúster anterior a la 1.24.8-gke.1300, debes crear este taint o tenerlo en cuenta cuando realices la actualización.

  • Los grupos de nodos Arm en GKE en AWS no son compatibles con Anthos Service Mesh, el Sincronizador de configuración ni el Policy Controller. Debes 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 Connect. 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 implementar cargas de trabajo de Arm y cómo programar cargas de trabajo de Arm.

Antes de comenzar

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

  • Un clúster de AWS existente para crear el grupo de nodos. Este clúster debe ejecutar la versión 1.24 de Kubernetes o una posterior.
  • Un perfil de instancia de IAM para las VM del grupo de nodos.
  • Una subred en la que se ejecutarán las VM del grupo de nodos.

  • Si tu clúster ejecuta la versión 1.24 de Kubernetes, un grupo de nodos x86 para ejecutar el agente de Connect.

    Si quieres obtener detalles sobre cómo crear un grupo de nodos en GKE en AWS, consulta Crea un grupo de nodos.

Crea un grupo de nodos Arm

GKE en AWS admite grupos de nodos compilados 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, 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

Reemplaza lo siguiente:

  • NODE_POOL_NAME: el nombre que eliges para el grupo de nodos
  • CLUSTER_NAME: el nombre del clúster al que se conectará 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 funcionan con procesadores AWS Graviton basados en ARM. También debes especificar el tamaño de instancia que deseas. Por ejemplo, m6g.medium. Para obtener una lista completa, consulta los tipos de instancias admitidas de AWS.

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

  • NODEPOOL_PROFILE: el perfil de la instancia de IAM para las VM del grupo de nodos

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

  • MIN_NODES: la cantidad mínima de nodos que puede contener el grupo de nodos

  • MAX_NODES: la cantidad máxima 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 único del grupo

  • GOOGLE_CLOUD_LOCATION: el nombre de la ubicación de Google Cloud

    desde la que se administrará 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 realizar pasos adicionales. Para obtener más información, consulta 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 del recurso de Amazon (ARN) de la clave de KMS de AWS que encripta los datos del usuario

Comprende las imágenes de varias arquitecturas

Las imágenes de contenedor deben ser compatibles con la arquitectura del nodo en el que deseas ejecutar las cargas de trabajo de Arm. Para asegurarte de que tu imagen de contenedor sea compatible con Arm, te recomendamos que uses imágenes de varias arquitecturas (“varios arcos”).

Una imagen de varios arcos es una imagen que admite varias arquitecturas. Se ve como una sola imagen con una sola etiqueta, pero contiene un conjunto de imágenes para ejecutar en diferentes arquitecturas de máquina. Las imágenes multiarquitectura son compatibles con Docker Image Manifest V2 Scheme 2 y con OCI Image Index Specifications.

Cuando implementas una imagen de varios arcos en un clúster, el entorno de ejecución del contenedor elige automáticamente la imagen que es compatible con la arquitectura del nodo en el que realizas la implementación. Una vez que tengas una imagen de varios arcos para una carga de trabajo, puedes implementar esta carga de trabajo sin problemas en varias arquitecturas. Programar una imagen de una sola arquitectura en un nodo incompatible provoca un error en el momento de la carga.

Para obtener más información sobre cómo usar imágenes de varios arcos con cargas de trabajo de Arm, consulta Compila imágenes de varias arquitecturas para cargas de trabajo de Arm en la documentación de Google Kubernetes Engine (GKE).

¿Qué sigue?