View a markdown version of this page

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

Für den Betrieb hochverfügbarer und robuster Anwendungen benötigen Sie eine hochverfügbare und robuste Datenebene. Eine elastische Datenebene stellt sicher, dass Kubernetes Ihre Anwendungen automatisch skalieren und reparieren kann. Eine robuste Datenebene besteht aus zwei oder mehr Worker-Nodes, kann mit der Arbeitslast wachsen und schrumpfen und wird nach Ausfällen automatisch wiederhergestellt.

Mit EKS haben Sie mehrere Auswahlmöglichkeiten für Worker-Knoten: verwaltete EKS-Nodes im Auto-Modus, EC2-Instances und Fargate.

EKS Auto Mode bietet den einfachsten Weg zu einer belastbaren 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, wenn Kubernetes die Pods skaliert, und sorgt kontinuierlich dafür, dass die Knoten in Ihrem Cluster für die aktuell ausgeführten Workloads angemessen und kostengünstig dimensioniert sind.

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

Fargate betreibt jeden Pod in einer isolierten Rechenumgebung. Jeder Pod, der auf Fargate läuft, erhält seinen eigenen Worker-Knoten. Fargate skaliert die Datenebene automatisch, wenn 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 (wenn Sie nicht den EKS-Auto-Modus verwenden, wo dies automatisch von AWS durchgeführt wird), ist die Verwendung von Karpenter-, Kubernetes Cluster Autoscaler- oder EC2 Auto Scaling-Gruppen. https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

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 AZs ausführen. 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 AZs besteht darin, Topology Spread Constraints für Pods zu verwenden. Auto-scaling Funktionen wie EKS Auto Mode und Karpenter berücksichtigen die Einschränkungen der Topologieverteilung und starten automatisch Knoten in den richtigen AZs, damit Ihre Einschränkungen erfüllt werden können.

Bei der folgenden Bereitstellung werden Pods nach Möglichkeit auf mehrere AZs verteilt, sodass diese Pods trotzdem laufen, 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 Labels existieren. Wenn die oben beschriebene Bereitstellung in einem Cluster mit Knoten nur in einer einzigen Zone bereitgestellt wird, planen alle Pods auf diesen Knoten, da die anderen Zonen kube-scheduler nicht berücksichtigt werden. Damit diese Topologieverteilung mit dem Scheduler erwartungsgemäß funktioniert, müssen in allen Zonen bereits Knoten vorhanden sein. Die minDomains Eigenschaft einer Topologie-Spreizungsbegrenzung wird verwendet, um den Scheduler über die Anzahl der infrage kommenden Domänen zu informieren, auch wenn dort ein Node läuft, um dieses Problem zu vermeiden.

Warnung

DoNotScheduleWird diese Einstellung whenUnsatisfiable auf gesetzt, können Pods nicht planbar sein, wenn die Topologiestreuungsbeschränkung nicht erfüllt werden kann. Es sollte nur gesetzt werden, wenn es besser ist, dass Pods nicht laufen, anstatt die Topologie-Spreiz-Beschränkung zu verletzen.

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

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 für verschiedene AZs geplant werden. Andernfalls wird die Anzahl der Pods in einer Bereitstellung niemals die Anzahl der AZs überschreiten.

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

Wenn Sie Amazon EBS verwenden, um persistente Volumes bereitzustellen, müssen Sie sicherstellen, dass sich die Pods und das zugehörige EBS-Volume in derselben AZ befinden. Ein Pod kann nicht auf EBS-backed persistente Volumes zugreifen, die sich in einer anderen AZ befinden. Der Kubernetes-Scheduler erkennt anhand der Labels auf dem Knoten, in welcher AZ sich ein Worker-Knoten befindet, und plant immer einen Pod, der ein EBS-Volume in derselben AZ wie das Volume benötigt. Wenn jedoch in der AZ, in der sich das Volume befindet, keine Worker Nodes 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 eine Knotengruppe haben.

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

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

Der EKS-Automatikmodus optimiert die EKS-Verwaltung, 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 Aktualisierungen gemäß den konfigurierten NodePool Unterbrechungseinstellungen und den Budgets für Pod-Unterbrechungen durchgeführt werden.

Führen Sie den Node Monitoring Agent aus

Der Node Monitoring Agent überwacht und reagiert auf Node-Integritätsprobleme, indem er Kubernetes-Ereignisse veröffentlicht und den Status der Nodes aktualisiert. Der Node Monitoring Agent ist in EKS Auto Mode Nodes enthalten und kann als EKS-Addon für Nodes 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 Node-Zustände 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 Speicherlimits für alle Container zu implementieren, da so verhindert wird, dass ein Container versehentlich Systemressourcen verbraucht und die Verfügbarkeit anderer Prozesse am selben Standort beeinträchtigt.

Ressourcen für alle Workloads konfigurieren und dimensionieren Requests/Limits

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

  • Geben Sie keine Ressourcenbeschränkungen für die CPU an. In Ermangelung von Grenzwerten dient die Anforderung als Gewichtung dafür, wie viel relative CPU-Zeit Container erhalten. Auf diese Weise können Ihre Workloads die gesamte CPU nutzen, ohne dass ein künstliches Limit oder ein Ausfall entsteht.

  • Bei Ressourcen, die keine CPU sind, limits bietet die Konfiguration von requests = das vorhersehbarste Verhalten. Wenn! requests =limits, außerdem wurde die QOS des Containers von Guaranteed auf Burstable reduziert, sodass es wahrscheinlicher ist, dass er bei Überlastung des Knotens weggeworfen wird. https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

  • Geben Sie für Ressourcen, die keine CPU sind, kein Limit an, das viel größer ist als die Anforderung. Je größer die Konfiguration im Verhältnis zu istrequests, desto wahrscheinlicher ist es, dass die Knoten überlastet limits sind, was zu einer hohen Wahrscheinlichkeit einer Arbeitsunterbrechung führt.

  • Anfragen mit der richtigen Größe sind besonders wichtig, wenn Sie eine Lösung für die automatische Skalierung von Knoten wie https://aws.github.io/aws-eks-best-practices/karpenter/ 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 und zu groß sind, werden Sie möglicherweise feststellen, dass Ihre Workloads entfernt oder OOM beendet wird, wenn sie auf einem Knoten dicht gepackt waren.

Die Bestimmung von Ressourcenanforderungen kann schwierig sein, aber Tools wie der Vertical Pod Autoscaler können Ihnen dabei helfen, die Anforderungen „richtig zu dimensionieren“, indem sie die Nutzung der Container-Ressourcen zur Laufzeit beobachten. Andere Tools, die für die Bestimmung der Anforderungsgröße nützlich sein können, sind unter anderem:

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 gewissen Spielraum für Namen und bieten eine Möglichkeit, Cluster-Ressourcen auf mehrere Teams, Projekte und Arbeitslasten aufzuteilen. Sie können den aggregierten Ressourcenverbrauch in einem Namespace einschränken. Das ResourceQuota Objekt kann die Anzahl der Objekte, die in einem Namespace erstellt werden können, nach Typ sowie die Gesamtmenge der Rechenressourcen, die von Ressourcen in diesem Projekt verbraucht werden können, einschränken. Sie können die Gesamtsumme der and/or Speicherrechenressourcen (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 Verwendung, um vorkonfigurierte Grenzwerte automatisch auf Container innerhalb eines Namespaces anzuwenden.

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 LimitRange Objekt kann Ihnen helfen, die minimalen und maximalen Ressourcen zu implementieren, die ein Container anfordern kann. Mithilfe können LimitRange Sie eine Standardanforderung und Grenzwerte für Container festlegen. Dies ist hilfreich, wenn das Festlegen von Grenzwerten für Rechenressourcen in Ihrer Organisation nicht üblich ist. LimitRangeKann, wie der Name schon sagt, die Mindest- und Höchstnutzung der Rechenressourcen pro Pod oder Container in einem Namespace erzwingen. Außerdem können Mindest- und Höchstspeicheranforderungen pro PersistentVolumeClaim Namespace erzwungen werden.

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

Verwenden Sie DNSCache NodeLocal

Sie können die Cluster-DNS-Leistung verbessern, indem Sie DNSCache ausführen NodeLocal. Mit dieser Funktion wird ein DNS-Caching-Agent auf Clusterknoten als ausgeführt. DaemonSet Alle Pods verwenden den DNS-Caching-Agenten, der auf dem Knoten ausgeführt wird, zur Namensauflösung, anstatt Service zu verwendenkube-dns. Diese Funktion ist automatisch im EKS-Automatikmodus enthalten.

Konfigurieren Sie die automatische Skalierung von CoreDNS

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

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