Ejecuta cargas de trabajo de Arm en GKE en AWS

GKE on 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 automáticamente un taint 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 en la versión 1.24.8-gke.1300 o posterior ya no agregan este taint. Si actualizas desde un clúster anterior a la versión 1.24.8-gke.1300, debes crear este taint o tenerlo en cuenta cuando realices la actualización.

  • Los grupos de nodos de ARM en GKE on AWS no son compatibles con Anthos Service Mesh, el Sincronizador de configuración ni el controlador de políticas. 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 Kubernetes 1.25 o una versión 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 tus cargas de trabajo de Arm, necesitas los siguientes recursos:

  • Un clúster de AWS existente en el que se creará el grupo de nodos. Este clúster debe ejecutar Kubernetes 1.24 o una versión 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 deseas obtener detalles para crear un grupo de nodos en GKE on AWS, consulta Crea un grupo de nodos.

Crea un grupo de nodos de Arm

GKE on AWS admite grupos de nodos compilados en la imagen de nodo mínima de Canonical Ubuntu arm64 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: Es el nombre que eliges para el grupo de nodos.
  • CLUSTER_NAME: Es el nombre del clúster al que se conectará el grupo de nodos.

  • INSTANCE_TYPE: Uno de los siguientes tipos de instancias:

    • 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 de AWS admitidos.

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

  • NODEPOOL_PROFILE: Es el perfil de la instancia de IAM para las VMs 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 la versión 1.24 o posterior. Por ejemplo, 1.24.3-gke.200

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

  • MAX_NODES: Es 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 del grupo

  • GOOGLE_CLOUD_LOCATION: Es el nombre de la cuenta de Google Cloud.

    ubicación 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 multiarquitectónicas

Las imágenes de contenedor deben ser compatibles con la arquitectura del nodo en el que pretendes ejecutar las cargas de trabajo de Arm. Para asegurarte de que la imagen de contenedor sea compatible con ARM, te recomendamos que uses imágenes multiarquitectónicas (“múltiples arcos”).

Una imagen de varios arcos es una imagen que puede admitir varias arquitecturas. Parece una sola imagen con una sola etiqueta, pero contiene un conjunto de imágenes para ejecutar en diferentes arquitecturas de máquinas. Las imágenes de varios arcos son compatibles con el Scheme 2 de Docker Image Manifest V2 y las especificaciones del índice de imágenes OCI.

Cuando implementas una imagen de varios arcos en un clúster, el entorno de ejecución del contenedor elige de forma automática 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 implementarla en varias arquitecturas. Programar una imagen de una sola arquitectura en un nodo incompatible provoca un error en el tiempo de carga.

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

¿Qué sigue?