Contribuisci a migliorare questa pagina

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Per contribuire a questa guida per l'utente, scegli il GitHub link Modifica questa pagina nel riquadro destro di ogni pagina.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Implementazione dei nodi EKS Auto Mode su Local Zones

EKS Auto Mode offre una gestione semplificata dei cluster con il provisioning automatico dei nodi. AWS Local Zones estendono l' AWS infrastruttura alle aree geografiche più vicine agli utenti finali, riducendo la latenza per le applicazioni sensibili alla latenza. Questa guida illustra il processo di implementazione dei nodi EKS Auto Mode su AWS Local Zones, consentendoti di eseguire applicazioni containerizzate con latenza inferiore per gli utenti in aree geografiche specifiche.

Questa guida dimostra anche come utilizzare i limiti e le tolleranze di Kubernetes per garantire che sui nodi della zona locale vengano eseguiti solo carichi di lavoro specifici, aiutandoti a controllare i costi e ottimizzare l'utilizzo delle risorse.

Prerequisiti

Prima di iniziare a distribuire i nodi EKS Auto Mode su Local Zones, assicurati di avere i seguenti prerequisiti:

Fase 1: Creare una sottorete di zona locale

Il primo passo per implementare i nodi EKS Auto Mode in una zona locale consiste nella creazione di una sottorete in quella zona locale. Questa sottorete fornisce l'infrastruttura di rete per i nodi e consente loro di comunicare con il resto del VPC. Segui le istruzioni Create a Local Zone subnet (nella AWS Local Zones User Guide) per creare una sottorete nella Local Zone prescelta.

Fase 2: Creazione NodeClass per la sottorete della zona locale

Dopo aver creato la sottorete Local Zone, è necessario definire una sottorete NodeClass che faccia riferimento a questa sottorete. NodeClass Si tratta di una risorsa personalizzata Kubernetes che specifica gli attributi di infrastruttura per i nodi, incluse le sottoreti, i gruppi di sicurezza e le configurazioni di archiviazione da utilizzare. Nell'esempio seguente, creiamo una NodeClass chiamata «zona locale» che ha come target una sottorete di zona locale in base al suo nome. È inoltre possibile utilizzare l'ID della sottorete. Dovrai adattare questa configurazione per indirizzare la tua sottorete Local Zone.

Per ulteriori informazioni, consulta Creazione di una classe di nodi per Amazon EKS.

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

Fase 3: Crea NodePool con NodeClass e Taint

Una volta NodeClass configurato, ora devi crearne uno NodePool che lo NodeClass utilizzi. A NodePool definisce le caratteristiche di calcolo dei nodi, inclusi i tipi di istanza. NodePool utilizza il NodeClass come riferimento per determinare dove avviare le istanze.

Nell'esempio seguente, creiamo un NodePool riferimento alla nostra «zona locale». NodeClass Aggiungiamo anche una macchia ai nodi per garantire che solo i pod con una tolleranza corrispondente possano essere programmati su questi nodi della Zona Locale. Ciò è particolarmente importante per i nodi della zona locale, che in genere hanno costi più elevati e devono essere utilizzati solo da carichi di lavoro che beneficiano specificamente della latenza ridotta.

Per ulteriori informazioni, consulta Crea un pool di nodi per EKS Auto Mode.

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 contaminazione tra key aws.amazon.com/local-zone ed effect NoSchedule assicura che i pod senza una tolleranza corrispondente non vengano programmati su questi nodi. Ciò impedisce l'esecuzione accidentale di carichi di lavoro regolari nella zona locale, il che potrebbe comportare costi imprevisti.

Fase 4: Implementazione dei carichi di lavoro con tolleranza e affinità tra nodi

Per un controllo ottimale sul posizionamento dei carichi di lavoro sui nodi della zona locale, utilizzate entrambi taints/tolerations e l'affinità dei nodi insieme. Questo approccio combinato offre i seguenti vantaggi:

Ecco un esempio di distribuzione configurata per l'esecuzione specifica sui nodi della zona locale:

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"

Questa distribuzione ha due configurazioni di pianificazione chiave:

Insieme, garantiscono che l'applicazione sensibile alla latenza venga eseguita solo sui nodi della zona locale e che le applicazioni normali non consumino le risorse della zona locale a meno che non siano configurate esplicitamente per farlo.

Passaggio 5: verifica con la console AWS

Dopo aver configurato le NodeClass distribuzioni e le distribuzioni, è necessario verificare che i nodi vengano forniti nella zona locale come previsto e che i carichi di lavoro vengano eseguiti su di essi. NodePool È possibile utilizzare la console di AWS gestione per verificare che le EC2 istanze vengano avviate nella sottorete della zona locale corretta.

Inoltre, puoi controllare l'elenco dei nodi Kubernetes utilizzando kubectl get nodes -o wide per confermare che i nodi si uniscano al cluster con le etichette e le sfumature corrette:

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

Puoi anche verificare che i pod del carico di lavoro siano pianificati sui nodi della zona locale:

kubectl get pods -o wide

Questo approccio garantisce che su questi nodi vengano pianificati solo i carichi di lavoro che tollerano specificamente la contaminazione della zona locale, aiutandoti a controllare i costi e a utilizzare nel modo più efficiente le risorse della zona locale.