Aidez à améliorer cette page

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Pour contribuer à ce guide de l'utilisateur, cliquez sur le GitHub lien Modifier cette page sur qui se trouve dans le volet droit de chaque page.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déployer des nœuds EKS Auto Mode sur des Zones Locales

Le mode automatique EKS simplifie la gestion des clusters grâce au provisionnement automatique des nœuds. AWS Les zones locales étendent AWS l'infrastructure à des emplacements géographiques plus proches de vos utilisateurs finaux, réduisant ainsi le temps de latence pour les applications sensibles à la latence. Ce guide explique le processus de déploiement des nœuds EKS Auto Mode sur les Zones AWS Locales, ce qui vous permet d'exécuter des applications conteneurisées avec une latence plus faible pour les utilisateurs de zones géographiques spécifiques.

Ce guide explique également comment utiliser les contraintes et les tolérances de Kubernetes pour garantir que seules des charges de travail spécifiques s'exécutent sur les nœuds de votre zone locale, ce qui vous aide à contrôler les coûts et à optimiser l'utilisation des ressources.

Conditions préalables

Avant de commencer à déployer des nœuds EKS Auto Mode sur des Zones Locales, assurez-vous que les conditions préalables suivantes sont réunies :

Étape 1 : créer un sous-réseau de zone locale

La première étape du déploiement des nœuds du mode automatique EKS dans une zone locale consiste à créer un sous-réseau dans cette zone locale. Ce sous-réseau fournit l'infrastructure réseau pour vos nœuds et leur permet de communiquer avec le reste de votre VPC. Suivez les instructions de création d'un sous-réseau de zone locale (dans le guide de l'utilisateur des zones AWS locales) pour créer un sous-réseau dans la zone locale de votre choix.

Étape 2 : Création NodeClass pour le sous-réseau de zone locale

Après avoir créé votre sous-réseau de zone locale, vous devez définir un NodeClass qui fait référence à ce sous-réseau. NodeClass Il s'agit d'une ressource personnalisée Kubernetes qui spécifie les attributs d'infrastructure de vos nœuds, notamment les sous-réseaux, les groupes de sécurité et les configurations de stockage à utiliser. Dans l'exemple ci-dessous, nous créons une « zone locale » qui cible un sous-réseau de zone locale en fonction de son NodeClass nom. Vous pouvez également utiliser l'ID de sous-réseau. Vous devrez adapter cette configuration pour cibler votre sous-réseau de zone locale.

Pour de plus amples informations, veuillez consulter Création d’une classe de nœuds pour Amazon EKS.

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

Étape 3 : créer NodePool avec NodeClass et teindre

Une fois que vous êtes NodeClass configuré, vous devez maintenant créer un NodePool qui l'utilise NodeClass. A NodePool définit les caractéristiques de calcul de vos nœuds, y compris les types d'instances. Il NodePool utilise le NodeClass comme référence pour déterminer où lancer les instances.

Dans l'exemple ci-dessous, nous créons un NodePool qui fait référence à notre « zone locale ». NodeClass Nous ajoutons également une touche aux nœuds afin de garantir que seuls les pods présentant une tolérance correspondante puissent être planifiés sur ces nœuds de zone locale. Cela est particulièrement important pour les nœuds de zone locale, qui ont généralement des coûts plus élevés et ne doivent être utilisés que par des charges de travail bénéficiant spécifiquement de la réduction de la latence.

Pour de plus amples informations, veuillez consulter Create a Node Pool for 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"]

L'odeur associée à la touche aws.amazon.com/local-zone et à l'effet NoSchedule garantit que les pods sans tolérance correspondante ne seront pas planifiés sur ces nœuds. Cela permet d'éviter que des charges de travail régulières ne s'exécutent accidentellement dans la zone locale, ce qui pourrait entraîner des coûts imprévus.

Étape 4 : Déployer les charges de travail avec tolérance et affinité des nœuds

Pour un contrôle optimal du placement de la charge de travail sur les nœuds de zone locale, utilisez à la fois l'affinité taints/tolerations des nœuds et l'affinité des nœuds. Cette approche combinée offre les avantages suivants :

Voici un exemple de déploiement configuré pour s'exécuter spécifiquement sur les nœuds de zone 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"

Ce déploiement comporte deux configurations de planification clés :

Ensemble, ils garantissent que votre application sensible à la latence ne s'exécute que sur les nœuds de zone locale, et que les applications ordinaires ne consomment pas les ressources de la zone locale, sauf si elles sont explicitement configurées pour le faire.

Étape 5 : vérification à l'aide de AWS la console

Après avoir configuré vos déploiements NodeClass NodePool, et,,,,,,,,,,, vous devez vérifier que les nœuds sont approvisionnés dans votre zone locale comme prévu et que vos charges de travail s'exécutent sur eux. Vous pouvez utiliser la console AWS de gestion pour vérifier que les EC2 instances sont lancées dans le sous-réseau de zone locale approprié.

En outre, vous pouvez consulter la liste des nœuds Kubernetes en utilisant kubectl get nodes -o wide pour vérifier que les nœuds rejoignent votre cluster avec les étiquettes et les caractéristiques appropriées :

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

Vous pouvez également vérifier que vos pods de charge de travail sont planifiés sur les nœuds de la zone locale :

kubectl get pods -o wide

Cette approche garantit que seules les charges de travail qui tolèrent spécifiquement l'empreinte de zone locale seront planifiées sur ces nœuds, ce qui vous permet de contrôler les coûts et d'utiliser au mieux les ressources de votre zone locale.