Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Stellen Sie EKS-Automodus-Knoten in Local Zones bereit

Der automatische Modus von EKS bietet eine vereinfachte Clusterverwaltung mit automatischer Knotenbereitstellung. AWS Local Zones erweitern die AWS Infrastruktur auf geografische Standorte, die näher an Ihren Endbenutzern liegen, und reduzieren so die Latenz für latenzempfindliche Anwendungen. Dieses Handbuch führt Sie durch den Prozess der Bereitstellung von EKS-Automodus-Knoten in AWS Local Zones, sodass Sie containerisierte Anwendungen mit geringerer Latenz für Benutzer in bestimmten geografischen Gebieten ausführen können.

In diesem Leitfaden wird auch gezeigt, wie Sie mithilfe von Kubernetes-Taints and Tolerations sicherstellen können, dass nur bestimmte Workloads auf Ihren Local-Zone-Knoten ausgeführt werden. So können Sie die Kosten kontrollieren und die Ressourcennutzung optimieren.

Voraussetzungen

Bevor Sie mit der Bereitstellung von EKS-Automodus-Knoten in Local Zones beginnen, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind:

Schritt 1: Subnetz für die lokale Zone erstellen

Der erste Schritt bei der Bereitstellung von EKS-Automodus-Knoten in einer lokalen Zone besteht darin, ein Subnetz in dieser lokalen Zone zu erstellen. Dieses Subnetz stellt die Netzwerkinfrastruktur für Ihre Knoten bereit und ermöglicht ihnen, mit dem Rest Ihrer VPC zu kommunizieren. Folgen Sie den Anweisungen zum Erstellen eines Subnetzes für eine lokale Zone (im Benutzerhandbuch für AWS Local Zones), um ein Subnetz in der von Ihnen ausgewählten lokalen Zone zu erstellen.

Schritt 2: Erstellen Sie das NodeClass Subnetz für die lokale Zone

Nachdem Sie Ihr Subnetz für die lokale Zone erstellt haben, müssen Sie ein Subnetz definieren, NodeClass das auf dieses Subnetz verweist. Das NodeClass ist eine benutzerdefinierte Kubernetes-Ressource, die die Infrastrukturattribute für Ihre Knoten spezifiziert, einschließlich der zu verwendenden Subnetze, Sicherheitsgruppen und Speicherkonfigurationen. Im folgenden Beispiel erstellen wir eine NodeClass sogenannte „lokale Zone“, die anhand ihres Namens auf ein Subnetz der lokalen Zone abzielt. Sie können auch die Subnetz-ID verwenden. Sie müssen diese Konfiguration an Ihr lokales Zonen-Subnetz anpassen.

Weitere Informationen finden Sie unter Knotenklasse für Amazon EKS erstellen.

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

Schritt 3: Create NodePool with NodeClass und Taint

Nachdem Sie es NodeClass konfiguriert haben, müssen Sie jetzt eine erstellen NodePool , die dies NodeClass verwendet. A NodePool definiert die Recheneigenschaften Ihrer Knoten, einschließlich der Instanztypen. Der NodePool verwendet das NodeClass als Referenz, um zu bestimmen, wo Instances gestartet werden sollen.

Im folgenden Beispiel erstellen wir eine, NodePool die auf unsere „lokale Zone“ verweist. NodeClass Außerdem fügen wir den Knoten einen Tain hinzu, um sicherzustellen, dass nur Pods mit einer entsprechenden Toleranz auf diesen Local-Zone-Knoten geplant werden können. Dies ist besonders wichtig für Knoten in der lokalen Zone, die in der Regel höhere Kosten verursachen und nur von Workloads verwendet werden sollten, die speziell von der reduzierten Latenz profitieren.

Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.

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"]

Der Nachteil von Schlüssel aws.amazon.com/local-zone und Effekt NoSchedule stellt sicher, dass Pods ohne entsprechende Toleranzen nicht auf diesen Knoten eingeplant werden. Dadurch wird verhindert, dass reguläre Workloads versehentlich in der lokalen Zone ausgeführt werden, was zu unerwarteten Kosten führen könnte.

Schritt 4: Stellen Sie Workloads mit Toleranz und Knotenaffinität bereit

Für eine optimale Kontrolle der Workload-Platzierung auf Knoten in der lokalen Zone sollten Sie beide taints/tolerations und die Knotenaffinität zusammen verwenden. Dieser kombinierte Ansatz bietet die folgenden Vorteile:

Hier ist ein Beispiel für eine Bereitstellung, die speziell für die Ausführung auf Knoten der lokalen Zone konfiguriert wurde:

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"

Diese Bereitstellung hat zwei wichtige Planungskonfigurationen:

Zusammen stellen sie sicher, dass Ihre latenzempfindliche Anwendung nur auf Knoten der lokalen Zone ausgeführt wird und reguläre Anwendungen die Ressourcen der lokalen Zone nicht verbrauchen, sofern sie nicht ausdrücklich dafür konfiguriert wurden.

Schritt 5: Überprüfen Sie mit der Konsole AWS

Nachdem Sie Ihre NodeClass NodePool, und Bereitstellungen eingerichtet haben, sollten Sie überprüfen, ob die Knoten wie erwartet in Ihrer lokalen Zone bereitgestellt werden und ob Ihre Workloads auf ihnen ausgeführt werden. Sie können die AWS Managementkonsole verwenden, um zu überprüfen, ob EC2 Instances im richtigen Subnetz der lokalen Zone gestartet werden.

Darüber hinaus können Sie anhand kubectl get nodes -o wide der Kubernetes-Knotenliste überprüfen, ob die Knoten Ihrem Cluster mit den richtigen Labels und Taints beitreten:

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

Sie können auch überprüfen, ob Ihre Workload-Pods auf den Knoten der lokalen Zone geplant sind:

kubectl get pods -o wide

Durch diesen Ansatz wird sichergestellt, dass auf diesen Knoten nur Workloads geplant werden, die den Taint Local Zone speziell tolerieren. Auf diese Weise können Sie die Kosten kontrollieren und die Ressourcen Ihrer lokalen Zone so effizient wie möglich nutzen.