EKS-Datenebene - Amazon EKS
Empfehlungen

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.

EKS-Datenebene

Um hochverfügbare und ausfallsichere Anwendungen zu betreiben, benötigen Sie eine hochverfügbare und belastbare Datenebene. Eine elastische Datenebene stellt sicher, dass Kubernetes Ihre Anwendungen automatisch skalieren und reparieren kann. Eine robuste Datenebene besteht aus zwei oder mehr Worker-Knoten, kann mit der Arbeitslast wachsen und schrumpfen und wird nach Ausfällen automatisch wiederhergestellt.

Bei EKS stehen Ihnen mehrere Optionen für Worker-Knoten zur Verfügung: verwaltete EKS Auto Mode Nodes, EC2 Instances und Fargate.

Der automatische Modus von EKS bietet den einfachsten Weg zu einer ausfallsicheren Datenebene. Der automatische Modus erweitert das AWS-Management von Kubernetes-Clustern über den Cluster selbst hinaus, sodass AWS auch die Infrastruktur einrichten und verwalten kann, die den reibungslosen Betrieb Ihrer Workloads ermöglicht. Der automatische Modus skaliert die Datenebene automatisch nach oben oder unten, während Kubernetes die Pods skaliert, und stellt kontinuierlich sicher, dass die Nodes in Ihrem Cluster für die aktuell ausgeführten Workloads angemessen und kostengünstig dimensioniert sind.

Wenn Sie sich für EC2 Instanzen entscheiden, können Sie die Worker-Knoten selbst verwalten oder von EKS verwaltete Knotengruppen verwenden. Sie können einen Cluster mit einer Mischung aus Auto Mode, verwalteten, selbstverwalteten Worker-Knoten und Fargate haben.

Fargate führt jeden Pod in einer isolierten Rechenumgebung aus. Jeder Pod, der auf Fargate läuft, erhält seinen eigenen Worker-Knoten. Fargate skaliert die Datenebene automatisch, während Kubernetes Pods skaliert. Sie können sowohl die Datenebene als auch Ihre Arbeitslast skalieren, indem Sie den horizontalen Pod-Autoscaler verwenden.

Die bevorzugte Methode zur Skalierung von EC2 Worker-Knoten (sofern nicht der EKS-Auto-Modus verwendet wird, in dem dies automatisch von AWS durchgeführt wird), ist die Verwendung von Karpenter -, Kubernetes Cluster Autoscaler- oder Auto Scaling Scaling-Gruppen. EC2

Empfehlungen

Verteilen Sie Worker-Knoten und Workloads auf mehrere AZs

Sie können Ihre Workloads vor Ausfällen in einer einzelnen AZ schützen, indem Sie Worker-Knoten und Pods in mehreren ausführen. AZs Sie können die AZ, in der die Worker-Knoten erstellt werden, mithilfe der Subnetze steuern, in denen Sie die Knoten erstellen.

Die empfohlene Methode zur Verteilung von Pods auf mehrere Pods AZs ist die Verwendung von Topology Spread Constraints für Pods. Funktionen zur automatischen Skalierung wie EKS Auto Mode und Karpenter sind sich der Einschränkungen der Topologieverteilung bewusst und starten Knoten automatisch in der richtigen Reihenfolge, AZs damit Ihre Einschränkungen eingehalten werden können.

Bei der folgenden Bereitstellung werden Pods nach Möglichkeit verteilt, sodass diese Pods trotzdem ausgeführt werden können, AZs wenn nicht:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1
Anmerkung

kube-schedulerkennt Topologiedomänen nur über Knoten, die mit diesen Bezeichnungen existieren. Wenn die oben genannte Bereitstellung in einem Cluster mit Knoten nur in einer einzigen Zone bereitgestellt wird, planen alle Pods auf diesen Knoten, da sie die anderen Zonen kube-scheduler nicht kennt. Damit diese Topologieverteilung mit dem Scheduler erwartungsgemäß funktioniert, müssen in allen Zonen bereits Knoten vorhanden sein. Die minDomains Eigenschaft einer Topologie-Spread-Beschränkung wird verwendet, um den Scheduler über die Anzahl der geeigneten Domänen zu informieren, auch wenn dort ein Knoten läuft, um dieses Problem zu vermeiden.

Warnung

Die Einstellung whenUnsatisfiable auf DoNotSchedule führt dazu, dass Pods nicht geplant werden können, wenn die Topologie-Spread-Beschränkung nicht erfüllt werden kann. Sie sollte nur gesetzt werden, wenn es besser ist, dass Pods nicht ausgeführt werden, anstatt gegen die Topologie-Spread-Beschränkung zu verstoßen.

In älteren Versionen von Kubernetes können Sie Pod-Anti-Affinitätsregeln verwenden, um Pods für mehrere Pods zu planen. AZs Das folgende Manifest informiert den Kubernetes-Scheduler darüber, Pods lieber einzeln zu planen. AZs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx
Warnung

Erfordern Sie nicht, dass Pods unterschiedlich geplant werden, AZs andernfalls wird die Anzahl der Pods in einer Bereitstellung niemals die Anzahl von überschreiten. AZs

Stellen Sie sicher, dass Knoten in jeder AZ gestartet werden können, wenn Sie EBS-Volumes verwenden

Wenn Sie Amazon EBS zur Bereitstellung persistenter Volumes verwenden, müssen Sie sicherstellen, dass sich die Pods und das zugehörige EBS-Volume in derselben AZ befinden. Ein Pod kann nicht auf EBS-gestützte persistente Volumes zugreifen, die sich in einer anderen AZ befinden. Der Kubernetes-Scheduler weiß anhand der Labels auf dem Knoten, in welcher AZ sich ein Worker-Knoten befindet, und plant immer einen Pod, für den ein EBS-Volume in derselben AZ wie das Volume erforderlich ist. Wenn jedoch in der AZ, in der sich das Volume befindet, keine Worker-Knoten verfügbar sind, kann der Pod nicht geplant werden.

Wenn Sie EKS Auto Mode oder Karpenter verwenden, müssen Sie sicherstellen, dass Sie Subnetze in jeder AZ NodeClass auswählen. Wenn Sie verwaltete Knotengruppen verwenden, müssen Sie sicherstellen, dass Sie in jeder AZ über eine Knotengruppe verfügen.

In den automatischen Modus von EKS ist eine EBS-Speicherfunktion integriert. Wenn Sie jedoch Karpenter oder Managed Node Groups verwenden, muss die EBS CSI ebenfalls installiert werden.

Verwenden Sie den EKS-Automatikmodus, um Worker-Knoten zu verwalten

Der automatische Modus von EKS optimiert das EKS-Management, indem er produktionsbereite Cluster mit minimalem Betriebsaufwand bereitstellt. Der automatische Modus ist dafür verantwortlich, die Anzahl der Knoten je nach den Pods, die im Cluster ausgeführt werden, nach oben oder unten zu skalieren. Die Knoten werden automatisch mit Software-Patches und Fixes auf dem neuesten Stand gehalten, wobei die Updates gemäß den konfigurierten NodePoolUnterbrechungseinstellungen und Pod-Disruption-Budgets durchgeführt werden.

Führen Sie den Node Monitoring Agent aus

Der Node Monitoring Agent überwacht Node-Integritätsprobleme und reagiert darauf, indem er Kubernetes-Ereignisse veröffentlicht und den Statuszustand auf Nodes aktualisiert. Der Node Monitoring Agent ist in EKS Auto Mode Nodes enthalten und kann als EKS-Addon für Knoten installiert werden, die nicht im Auto Mode verwaltet werden.

EKS Auto Mode, Managed Node Groups und Karpenter sind alle in der Lage, vom Node Monitoring Agent gemeldete schwerwiegende Knotenprobleme zu erkennen und diese Knoten automatisch zu reparieren, wenn diese Bedingungen eintreten.

Implementieren Sie QoS

Für kritische Anwendungen sollten Sie erwägen, requests = limits für den Container im Pod zu definieren. Dadurch wird sichergestellt, dass der Container nicht beendet wird, wenn ein anderer Pod Ressourcen anfordert.

Es hat sich bewährt, CPU- und Speicherbegrenzungen für alle Container zu implementieren, um zu verhindern, dass ein Container versehentlich Systemressourcen verbraucht und dadurch die Verfügbarkeit anderer Prozesse am selben Standort beeinträchtigt.

Konfigurieren und dimensionieren Sie die Ressourcen für alle Workloads Requests/Limits

Bei der Dimensionierung von Ressourcenanforderungen und der Grenzwerte für Workloads können einige allgemeine Richtlinien angewendet werden:

  • Geben Sie keine Ressourcenlimits für die CPU an. In Ermangelung von Grenzwerten bestimmt die Anfrage, wie viel relative CPU-Zeit Container erhalten. Auf diese Weise können Ihre Workloads die gesamte CPU nutzen, ohne dass es zu einer künstlichen Begrenzung oder zu einem Verlust kommt.

  • Bei Ressourcen, die nicht zur CPU gehören, limits bietet die Konfiguration von requests = das vorhersehbarste Verhalten. Wenn! requests =limits, außerdem wurde die QOS des Containers von Guaranteed auf Burstable herabgesetzt, wodurch die Wahrscheinlichkeit, dass er entfernt wird, wenn der Knoten überlastet wird, größer ist.

  • Geben Sie für Ressourcen, die nicht zur CPU gehören, kein Limit an, das viel größer ist als die Anforderung. Je größer limits die Konfiguration im Verhältnis zu istrequests, desto wahrscheinlicher ist es, dass Knoten überlastet werden, was zu einer hohen Wahrscheinlichkeit einer Unterbrechung der Arbeitslast führt.

  • Anfragen mit der richtigen Größe sind besonders wichtig, wenn Sie eine Node-Auto-Scaling-Lösung wie Karpenter oder Cluster verwenden. AutoScaler Diese Tools untersuchen Ihre Workload-Anfragen, um die Anzahl und Größe der bereitzustellenden Knoten zu ermitteln. Wenn Ihre Anfragen zu klein sind und höhere Grenzwerte aufweisen, kann es sein, dass Ihre Workloads entfernt oder OOM beendet werden, wenn sie auf einem Knoten eng zusammengepackt wurden.

Das Ermitteln von Ressourcenanforderungen kann schwierig sein, aber Tools wie der Vertical Pod Autoscaler können Ihnen helfen, die richtige Größe der Anfragen zu finden, indem Sie die Nutzung der Container-Ressourcen zur Laufzeit beobachten. Zu den weiteren Tools, die für die Bestimmung der Anforderungsgrößen nützlich sein können, gehören:

Konfigurieren Sie Ressourcenkontingente für Namespaces

Namespaces sind für die Verwendung in Umgebungen mit vielen Benutzern vorgesehen, die auf mehrere Teams oder Projekte aufgeteilt sind. Sie bieten einen Gültigkeitsbereich für Namen und bieten eine Möglichkeit, Clusterressourcen auf mehrere Teams, Projekte und Workloads aufzuteilen. Sie können den aggregierten Ressourcenverbrauch in einem Namespace einschränken. Das ResourceQuotaObjekt kann die Anzahl der Objekte, die in einem Namespace erstellt werden können, nach Typ sowie die Gesamtmenge der Rechenressourcen einschränken, die von Ressourcen in diesem Projekt verbraucht werden können. Sie können die Gesamtsumme der and/or Speicher-Rechenressourcen (CPU und Arbeitsspeicher) begrenzen, die in einem bestimmten Namespace angefordert werden können.

Wenn das Ressourcenkontingent für einen Namespace für Rechenressourcen wie CPU und Arbeitsspeicher aktiviert ist, müssen Benutzer Anforderungen oder Grenzwerte für jeden Container in diesem Namespace angeben.

Erwägen Sie, Kontingente für jeden Namespace zu konfigurieren. Erwägen Sie LimitRanges die automatische Anwendung vorkonfigurierter Grenzwerte auf Container innerhalb eines Namespaces.

Beschränken Sie die Nutzung von Container-Ressourcen innerhalb eines Namespace

Ressourcenkontingente helfen dabei, die Menge an Ressourcen zu begrenzen, die ein Namespace verwenden kann. Das LimitRangeObjekt kann Ihnen dabei helfen, die minimalen und maximalen Ressourcen zu implementieren, die ein Container anfordern kann. Mithilfe von LimitRange Ihnen können Sie eine Standardanforderung und Grenzwerte für Container festlegen. Dies ist hilfreich, wenn die Festlegung von Limits für Rechenressourcen in Ihrer Organisation nicht üblich ist. Wie der Name schon sagt, LimitRange kann die minimale und maximale Nutzung von Rechenressourcen pro Pod oder Container in einem Namespace durchgesetzt werden. Außerdem können Sie die minimale und maximale Speicheranforderung pro PersistentVolumeClaim Namespace durchsetzen.

Erwägen Sie die Verwendung LimitRange in Verbindung mitResourceQuota, um Grenzwerte sowohl auf Container- als auch auf Namespace-Ebene durchzusetzen. Durch die Festlegung dieser Grenzwerte wird sichergestellt, dass sich ein Container oder ein Namespace nicht auf Ressourcen auswirkt, die von anderen Mandanten im Cluster verwendet werden.

Verwenden NodeLocal DNSCache

Sie können die Cluster-DNS-Leistung verbessern, indem Sie Folgendes NodeLocalDNSCacheausführen: Diese Funktion führt einen DNS-Caching-Agenten auf Clusterknoten als DaemonSet aus. Alle Pods verwenden den DNS-Caching-Agenten, der auf dem Knoten ausgeführt wird, für die Namensauflösung, anstatt Service zu verwendenkube-dns. Diese Funktion ist automatisch im automatischen Modus von EKS enthalten.

Konfigurieren Sie die auto-scaling von CoreDNS

Eine weitere Methode zur Verbesserung der Cluster-DNS-Leistung besteht darin, die integrierte auto-scaling von CoreDNS-Pods zu aktivieren.

Diese Funktion überwacht kontinuierlich den Clusterstatus, einschließlich der Anzahl der Knoten und CPU-Kerne. Basierend auf diesen Informationen passt der Controller die Anzahl der Replikate der CoreDNS-Bereitstellung in einem EKS-Cluster dynamisch an.