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](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), [EC2-Instances](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) und [Fargate](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html). 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-Instances entscheiden, können Sie die Worker-Knoten selbst verwalten oder von EKS verwaltete Knotengruppen verwenden.](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) 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](https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html) 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 ausgeführt wird), ist die Verwendung von [Karpenter](https://karpenter.sh/) -, [Kubernetes Cluster Autoscaler- oder EC2 Auto Scaling Scaling-Gruppen](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md).](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 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](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/#spread-constraints-for-pods) 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-scheduler`kennt 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](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) 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](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) 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 [NodePool](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption)Unterbrechungseinstellungen und Pod-Disruption-Budgets durchgeführt werden. ### Führen Sie den Node Monitoring Agent aus Der [Node Monitoring Agent](https://docs.aws.amazon.com/eks/latest/userguide/node-health.html) ü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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#how-pods-with-resource-limits-are-run). 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\$1 `requests` [=`limits`, außerdem wurde die [QOS](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes) des Containers von Guaranteed auf Burstable herabgesetzt, wodurch die Wahrscheinlichkeit, dass er entfernt wird, wenn der Knoten überlastet wird, größer ist.](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) + 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 ist`requests`, 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](https://aws.github.io/aws-eks-best-practices/karpenter/) oder Cluster verwenden. AutoScaler](https://aws.github.io/aws-eks-best-practices/cluster-autoscaling/) 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](https://github.com/kubernetes/autoscaler/tree/master/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: + [Goldlöckchen](https://github.com/FairwindsOps/goldilocks) + [Parca](https://www.parca.dev/) + [Profiler](https://prodfiler.com/) + [rsg](https://mhausenblas.info/right-size-guide/) ### 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 [https://kubernetes.io/docs/concepts/policy/resource-quotas/](https://kubernetes.io/docs/concepts/policy/resource-quotas/)Objekt 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`, diese Option zu verwenden, um automatisch vorkonfigurierte Grenzwerte 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](https://kubernetes.io/docs/concepts/policy/limit-range/) 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 mit`ResourceQuota`, 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 [NodeLocalDNSCache](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)ausfü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 verwenden`kube-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](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html) 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.