Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Implementación de nodos del modo automático de EKS en Zonas locales

El modo automático de EKS proporciona una administración de clústeres simplificada con aprovisionamiento automático de nodos. Las Zonas locales de AWS amplían la infraestructura de AWS a ubicaciones geográficas más cercanas a los usuarios finales, lo que reduce la latencia de las aplicaciones sensibles a la latencia. En esta guía, obtendrá los pasos del proceso de implementación de nodos del modo automático de EKS en Zonas locales de AWS, lo que le permite ejecutar aplicaciones en contenedores con una latencia más baja para los usuarios de áreas geográficas específicas.

Además, también se muestra cómo utilizar taints y tolerancias de Kubernetes para garantizar que solo se ejecuten cargas de trabajo específicas en los nodos de Zonas locales, lo que lo ayuda a controlar los costos y optimizar el uso de recursos.

Requisitos previos

Antes de comenzar a implementar los nodos del modo automático de EKS en Zonas Locales, asegúrese de cumplir los siguientes requisitos previos.

Paso 1: creación de la subred de la Zona local

El primer paso para implementar los nodos del modo automático de EKS en una Zona local es crear una subred en esa Zona local. Esta subred proporciona la infraestructura de red para los nodos y les permite comunicarse con el resto de la VPC. Siga las instrucciones de Creación de una subred de Zona local (en la Guía del usuario de Zonas locales de AWS) para crear una subred en la Zona local que elija.

Paso 2: creación de NodeClass para la subred de la Zona local

Después de crear la subred de la zona local, debe definir una NodeClass que haga referencia a esta subred. NodeClass es un recurso personalizado de Kubernetes que especifica los atributos de infraestructura de los nodos, lo que incluye las subredes, los grupos de seguridad y las configuraciones de almacenamiento que se deben utilizar. En el siguiente ejemplo, creamos una NodeClass llamada “local-zone” que tiene como destino una subred de la Zona local basada en su nombre. También puede usar el ID de la subred. Deberá adaptar esta configuración para que su destino sea la subred de la Zona local.

Para obtener más información, consulte Cómo crear una clase de nodos para Amazon EKS.

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: local-zone
spec:
  subnetSelectorTerms:
    - id: <local-subnet-id>

Paso 3: creación de NodePool con NodeClass y Taint

Con la NodeClass configurada, ahora debe crear un NodePool que use esta NodeClass. Un NodePool define las características de computación de los nodos, lo que incluye los tipos de instancias. El NodePool usa la NodeClass como referencia para determinar dónde se lanzarán las instancias.

En el siguiente ejemplo, creamos un NodePool que hace referencia a nuestra NodeClass “local-zone”. También agregamos una taint a los nodos para asegurarnos de que solo se puedan programar los pods con una tolerancia coincidente en estos nodos de la Zona local. Esto es especialmente importante para los nodos de la Zona local, que suelen tener costos más elevados y solo deberían utilizarlos las cargas de trabajo que se beneficien específicamente de la reducción de la latencia.

Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: my-node-pool
spec:
  template:
    metadata:
      labels:
        node-type: local-zone
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: local-zone
      taints:
        - key: "aws.amazon.com/local-zone"
          value: "true"
          effect: NoSchedule

      requirements:
        - key: "eks.amazonaws.com/instance-category"
          operator: In
          values: ["c", "m", "r"]
        - key: "eks.amazonaws.com/instance-cpu"
          operator: In
          values: ["4", "8", "16", "32"]

La taint con la clave aws.amazon.com/local-zone y el efecto NoSchedule garantiza que los pods que no tengan una tolerancia igual no se programen en estos nodos. De este modo, se evita que las cargas de trabajo normales se ejecuten accidentalmente en la Zona local, lo que podría generar costos inesperados.

Paso 4: implementación de cargas de trabajo con tolerancia y afinidad de nodos

Para tener un control óptimo de la ubicación de la carga de trabajo en los nodos de la Zona local, utilice simultáneamente taints y tolerancias con la afinidad de nodos. A continuación se enumeran las ventajas de este enfoque combinado:

A continuación se muestra un ejemplo de una implementación configurada para ejecutarse específicamente en los nodos de la Zona local:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: low-latency-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: low-latency-app
  template:
    metadata:
      labels:
        app: low-latency-app
    spec:
      tolerations:
      - key: "aws.amazon.com/local-zone"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "node-type"
                operator: "In"
                values: ["local-zone"]
      containers:
      - name: application
        image: my-low-latency-app:latest
        resources:
          limits:
            cpu: "1"
            memory: "1Gi"
          requests:
            cpu: "500m"
            memory: "512Mi"

Esta implementación tiene dos configuraciones de programación clave:

En conjunto, garantizan que la aplicación sensible a la latencia se ejecute solo en los nodos de la Zona local y que las aplicaciones normales no consuman los recursos de la Zona local a menos que estén configuradas explícitamente para hacerlo.

Paso 5: verificar con la consola de AWS

Tras configurar la NodeClass, el NodePool y las implementaciones, debe comprobar que los nodos se aprovisionen en la Zona local según lo previsto y que las cargas de trabajo se ejecuten en ellos. Puede usar la Consola de administración de AWS para comprobar que las instancias de EC2 se estén lanzando en la subred de la Zona local correcta.

Además, puede consultar la lista de nodos de Kubernetes que utilizan kubectl get nodes -o wide para confirmar que los nodos se unen al clúster con las etiquetas y los caracteres correctos:

kubectl get nodes -o wide
kubectl describe node <node-name> | grep -A 5 Taints

También puede verificar que los pods de las cargas de trabajo estén programados en los nodos de la Zona local:

kubectl get pods -o wide

Este enfoque garantiza que solo las cargas de trabajo que toleren específicamente la taint de la Zona local se programen en estos nodos, lo que lo ayuda a controlar los costos y a hacer un uso más eficiente de los recursos de la Zona local.