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.
# Bewährte Methoden für Zuverlässigkeit
Dieser Abschnitt enthält Anleitungen dazu, wie Sie Workloads, die auf EKS ausgeführt werden, robust und hochverfügbar machen
## Verwendung dieses Leitfadens
Dieser Leitfaden richtet sich an Entwickler und Architekten, die hochverfügbare und fehlertolerante Dienste in EKS entwickeln und betreiben möchten. Der Leitfaden ist zur leichteren Nutzung in verschiedene Themenbereiche unterteilt. Jedes Thema beginnt mit einem kurzen Überblick, gefolgt von einer Liste mit Empfehlungen und bewährten Methoden für die Zuverlässigkeit Ihrer EKS-Cluster.
## Einführung
Die bewährten Methoden zur Zuverlässigkeit von EKS wurden unter den folgenden Themen zusammengefasst:
+ Anwendungen
+ Steuerebene
+ Datenebene
Was macht ein System zuverlässig? Wenn ein System trotz Veränderungen in seiner Umgebung im Laufe der Zeit konsistent funktioniert und die Anforderungen erfüllt, kann es als zuverlässig bezeichnet werden. Um dies zu erreichen, muss das System Fehler erkennen, sich automatisch selbst reparieren und in der Lage sein, je nach Bedarf zu skalieren.
Kunden können Kubernetes als Grundlage für den zuverlässigen Betrieb unternehmenskritischer Anwendungen und Dienste nutzen. Aber abgesehen von den Prinzipien des containerbasierten Anwendungsdesigns erfordert die zuverlässige Ausführung von Workloads auch eine zuverlässige Infrastruktur. In Kubernetes umfasst die Infrastruktur die Steuerungsebene und die Datenebene.
EKS bietet eine Kubernetes-Steuerebene in Produktionsqualität, die so konzipiert ist, dass sie hochverfügbar und fehlertolerant ist.
In EKS ist AWS für die Zuverlässigkeit der Kubernetes-Steuerebene verantwortlich. EKS führt die Kubernetes-Steuerebene in drei Availability Zones in einer AWS-Region aus. Es verwaltet automatisch die Verfügbarkeit und Skalierbarkeit der Kubernetes-API-Server und des etcd-Clusters.
Sie, der Kunde und AWS tragen gemeinsam die Verantwortung für die Zuverlässigkeit der Datenebene. EKS bietet vier Worker-Node-Optionen für die Bereitstellung der Kubernetes-Datenebene.
Der [automatische Modus von EKS](https://docs.aws.amazon.com/eks/latest/userguide/automode.html), die am häufigsten verwaltete Option, übernimmt die Bereitstellung, Skalierung und Aktualisierung der Datenebene sowie die Bereitstellung verwalteter Rechen-, Netzwerk- und Speicherfunktionen. Der Auto-Modus AMIs wird häufig veröffentlicht und Cluster werden automatisch auf das neueste AMI aktualisiert, um CVE-Fixes und Sicherheitspatches bereitzustellen. Sie haben die Möglichkeit, zu kontrollieren, wann dies geschieht, indem Sie in Ihrem Automodus NodePools die [Störungskontrolle](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption) konfigurieren.
Fargate kümmert sich um die Bereitstellung und Skalierung der Datenebene, indem es einen Pod pro Knoten ausführt. Die dritte Option, verwaltete Knotengruppen, kümmert sich um die Bereitstellung und Aktualisierung der Datenebene. Und schließlich sind selbstverwaltete Knoten die am wenigsten verwaltete Option für die Datenebene. Je mehr AWS-verwaltete Datenebene Sie verwenden, desto weniger Verantwortung haben Sie.
[Verwaltete Knotengruppen](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) automatisieren die Bereitstellung und das Lebenszyklusmanagement von EC2-Knoten. Sie können die EKS-API (mithilfe der EKS-Konsole, AWS-API, AWS-CLICloudFormation, Terraform oder`eksctl`) verwenden, um verwaltete Knoten zu erstellen, zu skalieren und zu aktualisieren. Auf verwalteten Knoten werden EKS-optimierte Amazon Linux 2 EC2-Instances in Ihrem Konto ausgeführt, und Sie können benutzerdefinierte Softwarepakete installieren, indem Sie den SSH-Zugriff aktivieren. Wenn Sie verwaltete Knoten bereitstellen, werden sie als Teil einer von EKS verwalteten Auto Scaling-Gruppe ausgeführt, die sich über mehrere Availability Zones erstrecken kann. Sie steuern dies über die Subnetze, die Sie bei der Erstellung verwalteter Knoten angeben. EKS kennzeichnet verwaltete Knoten außerdem automatisch, sodass sie mit Cluster Autoscaler verwendet werden können.
Amazon EKS folgt dem Modell der gemeinsamen Verantwortung für CVEs und Sicherheitspatches auf verwalteten Knotengruppen. Da auf verwalteten Knoten die für Amazon EKS optimierte Version ausgeführt wird AMIs, ist Amazon EKS dafür verantwortlich, gepatchte Versionen davon zu erstellen, AMIs wenn Fehler behoben werden. Sie sind jedoch dafür verantwortlich, diese gepatchten AMI-Versionen für Ihre verwalteten Knotengruppen bereitzustellen.
EKS [verwaltet auch die Aktualisierung der Knoten](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html), obwohl Sie den Aktualisierungsvorgang einleiten müssen. Der Prozess der [Aktualisierung des verwalteten Knotens](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) wird in der EKS-Dokumentation erklärt.
Wenn Sie selbstverwaltete Knoten ausführen, können Sie das [Amazon EKS-optimierte Linux-AMI](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html) verwenden, um Worker-Knoten zu erstellen. Sie sind für das Patchen und Aktualisieren des AMI und der Knoten verantwortlich. Es hat sich bewährt `eksctl` CloudFormation, Infrastruktur als Codetools für die Bereitstellung von selbstverwalteten Knoten zu verwenden, da Sie auf diese Weise das [Upgrade von selbstverwalteten](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html) Knoten problemlos durchführen können. ****Erwägen Sie [bei der Aktualisierung von Worker-Knoten die Migration auf neue](https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html) Knoten, da der Migrationsprozess die alte Knotengruppe unverändert lässt `NoSchedule` und die Knoten überlastet, sobald ein neuer Stack bereit ist, die bestehende Pod-Arbeitslast zu akzeptieren.**** Sie können jedoch auch ein direktes [Upgrade von selbstverwalteten Knoten durchführen](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html).
**Modell der geteilten Verantwortung - Fargate**
![\[Modell der geteilten Verantwortung - Fargate\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/reliability/SRM-Fargate.jpeg)
**Modell der geteilten Verantwortung — MNG**
![\[Modell der geteilten Verantwortung — MNG\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/reliability/SRM-MNG.jpeg)
Dieser Leitfaden enthält eine Reihe von Empfehlungen, mit denen Sie die Zuverlässigkeit Ihrer EKS-Datenebene, der Kubernetes-Kernkomponenten und Ihrer Anwendungen verbessern können.
## Feedback
Dieser Leitfaden wird am veröffentlicht, GitHub um direktes Feedback und Vorschläge von der breiteren EKS/Kubernetes Community zu sammeln. Wenn Sie eine bewährte Methode haben, die wir Ihrer Meinung nach in den Leitfaden aufnehmen sollten, reichen Sie bitte ein Problem ein oder reichen Sie eine PR im GitHub Repository ein. Wir beabsichtigen, den Leitfaden regelmäßig zu aktualisieren, sobald der Service um neue Funktionen erweitert wird oder wenn sich eine neue bewährte Methode herausstellt.
# Ausführung hochverfügbarer Anwendungen
Ihre Kunden erwarten, dass Ihre Anwendung immer verfügbar ist, auch wenn Sie Änderungen vornehmen, und insbesondere bei Verkehrsspitzen. Eine skalierbare und belastbare Architektur sorgt dafür, dass Ihre Anwendungen und Dienste unterbrechungsfrei laufen, sodass Ihre Benutzer zufrieden sind. Eine skalierbare Infrastruktur wächst und schrumpft je nach den Anforderungen des Unternehmens. Die Eliminierung einzelner Fehlerquellen ist ein entscheidender Schritt, um die Verfügbarkeit einer Anwendung zu verbessern und sie widerstandsfähiger zu machen.
Mit Kubernetes können Sie Ihre Anwendungen betreiben und sie hochverfügbar und belastbar ausführen. Die deklarative Verwaltung stellt sicher, dass Kubernetes, sobald Sie die Anwendung eingerichtet haben, kontinuierlich versucht, den aktuellen Status [mit dem gewünschten Status abzugleichen](https://kubernetes.io/docs/concepts/architecture/controller/#desired-vs-current).
## Empfehlungen
### Konfigurieren Sie Pod-Disruption-Budgets
[Budgets für Pod-Unterbrechungen](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) werden verwendet, um die Anzahl der gleichzeitigen Unterbrechungen zu begrenzen, denen eine Anwendung ausgesetzt sein wird. Sie sollten für Workloads konfiguriert werden, wenn es wichtig ist, dass immer ein Teil dieser Workloads verfügbar ist. EKS Auto Mode, Karpenter und Cluster Autoscaler kennen die konfigurierten Pod-Disruption-Budgets und halten sich bei der Herunterskalierung daran. EKS Auto Mode, Karpenter und Managed Node Groups halten sich bei der Aktualisierung von Nodes auch an die Pod-Disruption-Budgets
### Vermeiden Sie es, Singleton-Pods auszuführen
Wenn Ihre gesamte Anwendung in einem einzigen Pod ausgeführt wird, ist Ihre Anwendung nicht verfügbar, wenn dieser Pod beendet wird. Anstatt Anwendungen mithilfe einzelner Pods bereitzustellen, erstellen Sie [Bereitstellungen.](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) Wenn ein durch eine Bereitstellung erstellter Pod ausfällt oder beendet wird, startet der Deployment [Controller](https://kubernetes.io/docs/concepts/architecture/controller/) einen neuen Pod, um sicherzustellen, dass die angegebene Anzahl von Replikat-Pods immer ausgeführt wird.
### Führen Sie mehrere Replikate aus
Wenn Sie mehrere Replikate ausführen (Pods) einer App mithilfe eines Deployment, kann diese auf hochverfügbare Weise ausgeführt werden. Wenn ein Replikat ausfällt, funktionieren die verbleibenden Replikate weiterhin, wenn auch mit reduzierter Kapazität, bis Kubernetes einen weiteren Pod erstellt, um den Verlust auszugleichen. Darüber hinaus können Sie den [Horizontal Pod Autoscaler verwenden, um Replikate automatisch auf der Grundlage der Workload-Nachfrage](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) zu skalieren.
### Planen Sie Replikate knotenübergreifend
Das Ausführen mehrerer Replikate ist nicht sehr nützlich, wenn alle Replikate auf demselben Knoten ausgeführt werden und der Knoten nicht mehr verfügbar ist. Erwägen Sie die Verwendung von Pod-Anti-Affinitäts- oder Pod-Topologie-Verbreitungsbeschränkungen, um Replikate einer Bereitstellung auf mehrere Worker-Knoten zu verteilen.
Sie können die Zuverlässigkeit einer typischen Anwendung weiter verbessern, indem Sie sie auf mehreren ausführen. AZs
#### Verwendung von Pod-Anti-Affinitätsregeln
Das folgende Manifest weist den Kubernetes-Scheduler an, Pods *lieber auf separaten* Knoten und zu platzieren. AZs Es sind keine eigenen Knoten oder AZ erforderlich, denn wenn dies der Fall wäre, kann Kubernetes keine Pods planen, sobald in jeder AZ ein Pod läuft. Wenn Ihre Anwendung nur drei Replikate benötigt, können Sie `requiredDuringSchedulingIgnoredDuringExecution` for verwenden`topologyKey: topology.kubernetes.io/zone`, und der Kubernetes-Scheduler plant nicht zwei Pods in derselben AZ.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: spread-host-az
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: topology.kubernetes.io/zone
weight: 100
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web-server
topologyKey: kubernetes.io/hostname
weight: 99
containers:
- name: web-app
image: nginx:1.16-alpine
```
#### Verbreitungsbeschränkungen mithilfe der Pod-Topologie
Ähnlich wie bei Pod-Anti-Affinitätsregeln können Sie mit Einschränkungen für die Verteilung der Pod-Topologie Ihre Anwendung für verschiedene Fehler- (oder Topologie-) Domänen wie Hosts oder verfügbar machen. AZs Dieser Ansatz funktioniert sehr gut, wenn Sie versuchen, sowohl Fehlertoleranz als auch Verfügbarkeit sicherzustellen, indem Sie mehrere Replikate in jeder der verschiedenen Topologiedomänen verwenden. Pod-Anti-Affinitätsregeln können dagegen leicht zu Ergebnissen führen, wenn Sie ein einzelnes Replikat in einer Topologiedomäne haben, da die Pods mit einer Anti-Affinität zueinander eine abstoßende Wirkung haben. In solchen Fällen ist ein einzelnes Replikat auf einem dedizierten Knoten weder ideal für die Fehlertoleranz noch für eine sinnvolle Nutzung von Ressourcen. Mit Einschränkungen der Topologieverteilung haben Sie mehr Kontrolle über die Verteilung oder Verteilung, die der Scheduler auf die Topologiedomänen anwenden sollte. Hier sind einige wichtige Eigenschaften, die bei diesem Ansatz verwendet werden sollten:
1. Der `maxSkew` wird verwendet, um den maximalen Punkt zu steuern oder zu bestimmen, bis zu dem die Dinge in den Topologiedomänen ungleichmäßig sein können. Wenn eine Anwendung beispielsweise über 10 Replikate verfügt und auf 3 verteilt ist AZs, können Sie zwar keine gleichmäßige Verteilung erzielen, aber Sie können beeinflussen, wie ungleichmäßig die Verteilung sein wird. In diesem Fall `maxSkew` kann es sich um einen Wert zwischen 1 und 10 handeln. Ein Wert von 1 bedeutet, dass Sie am Ende möglicherweise eine Streuung wie `4,3,3` `3,4,3` oder `3,3,4` über die 3 erhalten können AZs. Im Gegensatz dazu bedeutet ein Wert von 10, dass Sie möglicherweise eine Streuung von etwa `10,0,0` `0,10,0` oder `0,0,10` über 3 erhalten können AZs.
1. Das `topologyKey` ist ein Schlüssel für eine der Knotenbezeichnungen und definiert den Typ der Topologiedomäne, die für die Pod-Verteilung verwendet werden soll. Ein zonaler Spread hätte beispielsweise das folgende Schlüssel-Wert-Paar:
```
topologyKey: "topology.kubernetes.io/zone"
```
1. Die `whenUnsatisfiable` Eigenschaft wird verwendet, um zu bestimmen, wie der Scheduler reagieren soll, wenn die gewünschten Einschränkungen nicht erfüllt werden können.
1. Die `labelSelector` wird verwendet, um passende Pods zu finden, sodass der Scheduler sie erkennen kann, wenn er entscheidet, wo Pods gemäß den von Ihnen angegebenen Einschränkungen platziert werden sollen.
Zusätzlich zu den oben genannten gibt es weitere Felder, über die Sie in der [Kubernetes-Dokumentation](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) weiter lesen können.
**Die Pod-Topologie verteilt sich auf 3 Einschränkungen AZs**
![\[Pod topology spread constraints across 3 AZs\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/reliability/pod-topology-spread-constraints.jpg)
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: spread-host-az
labels:
app: web-server
spec:
replicas: 10
selector:
matchLabels:
app: web-server
template:
metadata:
labels:
app: web-server
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: express-test
containers:
- name: web-app
image: nginx:1.16-alpine
```
### Führen Sie den Kubernetes Metrics Server aus
Installieren Sie den Kubernetes [Metrics Server, um Ihre Anwendungen](https://github.com/kubernetes-sigs/metrics-server) zu skalieren. Kubernetes-Autoscaler-Add-ons wie [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) und [VPA müssen die Metriken von Anwendungen verfolgen, um sie skalieren](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) zu können. Der Metrics-Server sammelt Ressourcenmetriken, die verwendet werden können, um Skalierungsentscheidungen zu treffen. [Die Metriken werden von Kubelets gesammelt und im Metrics-API-Format bereitgestellt.](https://github.com/kubernetes/metrics)
Der Metrik-Server speichert keine Daten und ist keine Überwachungslösung. Sein Zweck besteht darin, Metriken zur CPU- und Speichernutzung anderen Systemen zugänglich zu machen. Wenn Sie den Status Ihrer Anwendung im Laufe der Zeit verfolgen möchten, benötigen Sie ein Überwachungstool wie Prometheus oder Amazon. CloudWatch
Folgen Sie der [EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/metrics-server.html), um den Metrics-Server in Ihrem EKS-Cluster zu installieren.
## Horizontaler Pod-Autoscaler (HPA)
HPA kann Ihre Anwendung je nach Bedarf automatisch skalieren und Ihnen helfen, zu vermeiden, dass Ihre Kunden zu Spitzenzeiten beeinträchtigt werden. Es ist als Regelkreis in Kubernetes implementiert, der in regelmäßigen Abständen Metriken abfragt, die Ressourcenmetriken APIs bereitstellen.
HPA kann Metriken aus folgenden APIs Quellen abrufen: 1. `metrics.k8s.io`auch bekannt als Resource Metrics API — Stellt die CPU- und Speicherauslastung für Pods 2 bereit. `custom.metrics.k8s.io` — Stellt Metriken von anderen Metriksammlern wie Prometheus bereit. Diese Metriken sind **intern** in Ihrem Kubernetes-Cluster. 3. `external.metrics.k8s.io` — Stellt Metriken bereit, die sich **außerhalb** Ihres Kubernetes-Clusters befinden (z. B. SQS Queue Depth, ELB-Latenz).
Sie müssen eine dieser drei Optionen verwenden, APIs um die Metrik für die Skalierung Ihrer Anwendung bereitzustellen.
### Skalierung von Anwendungen auf der Grundlage benutzerdefinierter oder externer Metriken
Sie können benutzerdefinierte oder externe Metriken verwenden, um Ihre Anwendung anhand anderer Messwerte als der CPU- oder Speicherauslastung zu skalieren. API-Server für [benutzerdefinierte Metriken](https://github.com/kubernetes-sigs/custom-metrics-apiserver) stellen die `custom-metrics.k8s.io` API bereit, mit der HPA Anwendungen automatisch skalieren kann.
Sie können den [Prometheus-Adapter für Kubernetes-Metriken verwenden, APIs um Metriken](https://github.com/directxman12/k8s-prometheus-adapter) von Prometheus zu sammeln und mit der HPA zu verwenden. [In diesem Fall stellt der Prometheus-Adapter Prometheus-Metriken im Metrics-API-Format zur Verfügung.](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/types.go)
Sobald Sie den Prometheus-Adapter bereitgestellt haben, können Sie benutzerdefinierte Metriken mit kubectl abfragen. `kubectl get —raw /apis/custom.metrics.k8s.io/v1beta1/`
Externe Metriken bieten, wie der Name schon sagt, dem Horizontal Pod Autoscaler die Möglichkeit, Bereitstellungen mithilfe von Metriken zu skalieren, die sich außerhalb des Kubernetes-Clusters befinden. Bei Workloads zur Stapelverarbeitung ist es beispielsweise üblich, die Anzahl der Replikate auf der Grundlage der Anzahl der laufenden Jobs in einer SQS-Warteschlange zu skalieren.
Um Kubernetes-Workloads automatisch zu skalieren, können Sie KEDA (Kubernetes Event-Driven Autoscaling) verwenden, ein Open-Source-Projekt, das die Container-Skalierung auf der Grundlage einer Reihe von benutzerdefinierten Ereignissen vorantreiben kann. In diesem [AWS-Blog](https://aws.amazon.com/blogs/mt/autoscaling-kubernetes-workloads-with-keda-using-amazon-managed-service-for-prometheus-metrics/) wird beschrieben, wie Amazon Managed Service for Prometheus für die auto-scaling von Kubernetes-Workloads verwendet wird.
## Vertikaler Pod-Autoscaler (VPA)
VPA passt die CPU- und Speicherreservierung für Ihre Pods automatisch an, damit Sie Ihre Anwendungen „richtig dimensionieren“ können. Für Anwendungen, die vertikal skaliert werden müssen — was durch Erhöhung der Ressourcenzuweisung erreicht wird — können Sie [VPA](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) verwenden, um Pod-Replikate automatisch zu skalieren oder Skalierungsempfehlungen zu geben.
Ihre Anwendung ist möglicherweise vorübergehend nicht verfügbar, wenn VPA sie skalieren muss, da die aktuelle Implementierung von VPA keine direkten Anpassungen an Pods vornimmt. Stattdessen wird der Pod, der skaliert werden muss, neu erstellt.
Die [EKS-Dokumentation](https://docs.aws.amazon.com/eks/latest/userguide/vertical-pod-autoscaler.html) enthält eine Anleitung zur Einrichtung von VPA.
Das [Fairwinds Goldilocks-Projekt](https://github.com/FairwindsOps/goldilocks/) bietet ein Dashboard zur Visualisierung von VPA-Empfehlungen für CPU- und Speicheranforderungen und Grenzwerte. Im VPA-Aktualisierungsmodus können Sie Pods auf der Grundlage von VPA-Empfehlungen automatisch skalieren.
## Anwendungen werden aktualisiert
Moderne Anwendungen erfordern schnelle Innovationen mit einem hohen Maß an Stabilität und Verfügbarkeit. Kubernetes bietet Ihnen die Tools, mit denen Sie Ihre Anwendungen kontinuierlich aktualisieren können, ohne Ihre Kunden zu stören.
Schauen wir uns einige der Best Practices an, die es ermöglichen, Änderungen schnell umzusetzen, ohne die Verfügbarkeit zu beeinträchtigen.
### Haben Sie einen Mechanismus zur Durchführung von Rollbacks
Mit einer Schaltfläche zum Rückgängigmachen können Katastrophen vermieden werden. Es hat sich bewährt, Bereitstellungen in einer separaten unteren Umgebung (Test- oder Entwicklungsumgebung) zu testen, bevor der Produktionscluster aktualisiert wird. Mithilfe einer CI/CD-Pipeline können Sie Bereitstellungen automatisieren und testen. Mit einer kontinuierlichen Bereitstellungspipeline können Sie schnell zur älteren Version zurückkehren, falls das Upgrade defekt sein sollte.
Sie können Deployments verwenden, um eine laufende Anwendung zu aktualisieren. Dies erfolgt in der Regel durch die Aktualisierung des Container-Images. Sie können es verwenden`kubectl`, um ein Deployment wie folgt zu aktualisieren:
```
kubectl --record deployment.apps/nginx-deployment set image nginx-deployment nginx=nginx:1.16.1
```
Das `--record` Argument zeichnet die Änderungen am Deployment auf und hilft Ihnen, wenn Sie ein Rollback durchführen müssen. `kubectl rollout history deployment`zeigt Ihnen die aufgezeichneten Änderungen an den Bereitstellungen in Ihrem Cluster. Sie können eine Änderung rückgängig machen mit. `kubectl rollout undo deployment `
Wenn Sie ein Deployment aktualisieren, das eine Neuerstellung der Pods erfordert, führt Deployment standardmäßig ein [fortlaufendes Update](https://kubernetes.io/docs/tutorials/kubernetes-basics/update/update-intro/) durch. Mit anderen Worten, Kubernetes aktualisiert nur einen Teil der laufenden Pods in einem Deployment und nicht alle Pods gleichzeitig. Sie können mithilfe von Property steuern, wie Kubernetes fortlaufende Updates durchführt. `RollingUpdateStrategy`
Wenn Sie ein *fortlaufendes Update* eines Deployments durchführen, können Sie die [https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-unavailable)Eigenschaft verwenden, um die maximale Anzahl von Pods anzugeben, die während des Updates nicht verfügbar sein können. Mit der `Max Surge` Eigenschaft Deployment können Sie die maximale Anzahl von Pods festlegen, die über die gewünschte Anzahl von Pods hinweg erstellt werden können.
Erwägen Sie Anpassungen, `max unavailable` um sicherzustellen, dass ein Rollout Ihre Kunden nicht stört. Kubernetes legt beispielsweise `max unavailable` standardmäßig 25% fest, was bedeutet, dass bei 100 Pods möglicherweise nur 75 Pods während eines Rollouts aktiv sind. Wenn Ihre Anwendung mindestens 80 Pods benötigt, kann dieser Rollout störend sein. Stattdessen können Sie einen Wert von 20% festlegen`max unavailable`, um sicherzustellen, dass während des gesamten Rollouts mindestens 80 funktionsfähige Pods vorhanden sind.
### Verwenden Sie Bereitstellungen blue/green
Änderungen sind von Natur aus riskant, aber Änderungen, die nicht rückgängig gemacht werden können, können potenziell katastrophal sein. Änderungsverfahren, mit denen Sie die Zeit durch ein *Rollback* effektiv zurückdrehen können, machen Verbesserungen und Experimente sicherer. Blue/green Bereitstellungen bieten Ihnen eine Methode, um die Änderungen schnell rückgängig zu machen, falls etwas schief geht. In dieser Bereitstellungsstrategie erstellen Sie eine Umgebung für die neue Version. Diese Umgebung ist identisch mit der aktuellen Version der Anwendung, die aktualisiert wird. Sobald die neue Umgebung bereitgestellt ist, wird der Datenverkehr an die neue Umgebung weitergeleitet. Wenn die neue Version die gewünschten Ergebnisse liefert, ohne Fehler zu generieren, wird die alte Umgebung beendet. Andernfalls wird der Verkehr auf die alte Version zurückgesetzt.
Sie können blue/green Bereitstellungen in Kubernetes durchführen, indem Sie ein neues Deployment erstellen, das mit dem Deployment der vorhandenen Version identisch ist. Sobald Sie sichergestellt haben, dass die Pods im neuen Deployment fehlerfrei ausgeführt werden, können Sie damit beginnen, Traffic an das neue Deployment zu senden, indem Sie die `selector` Spezifikation im Service ändern, der den Datenverkehr an die Pods Ihrer Anwendung weiterleitet.
Mit vielen Tools für die kontinuierliche Integration wie [Flux](https://fluxcd.io), [Jenkins](https://www.jenkins.io) und [Spinnaker](https://spinnaker.io) können Sie Bereitstellungen automatisieren. blue/green Der AWS-Container-Blog enthält eine Anleitung zur Verwendung von AWS Load Balancer Controller: [Verwenden von AWS Load Balancer Controller für blue/green Bereitstellung, Bereitstellung und Testen auf Canary A/B ](https://aws.amazon.com/blogs/containers/using-aws-load-balancer-controller-for-blue-green-deployment-canary-deployment-and-a-b-testing/)
### Verwenden Sie kanarische Bereitstellungen
Bei Bereitstellungen auf Kanaren handelt es sich um eine Variante von blue/green Bereitstellungen, mit denen das Risiko von Änderungen erheblich verringert werden kann. Bei dieser Bereitstellungsstrategie erstellen Sie ein neues Deployment mit weniger Pods neben Ihrem alten Deployment und leiten einen kleinen Teil des Traffics auf das neue Deployment um. Wenn die Messwerte darauf hindeuten, dass die neue Version genauso gut oder besser funktioniert als die bestehende Version, erhöhen Sie den Datenverkehr zur neuen Bereitstellung schrittweise und skalieren sie gleichzeitig, bis der gesamte Datenverkehr auf die neue Bereitstellung umgeleitet wird. Wenn ein Problem auftritt, können Sie den gesamten Datenverkehr an das alte Deployment weiterleiten und das Senden von Traffic an das neue Deployment beenden.
[Kubernetes bietet zwar keine native Möglichkeit, kanarische Bereitstellungen durchzuführen, aber Sie können Tools wie [Flagger](https://github.com/weaveworks/flagger) mit Istio verwenden.](https://docs.flagger.app/tutorials/istio-progressive-delivery)
## Gesundheitschecks und Selbstheilung
Keine Software ist fehlerfrei, aber Kubernetes kann Ihnen helfen, die Auswirkungen von Softwareausfällen zu minimieren. In der Vergangenheit musste jemand, wenn eine Anwendung abstürzte, die Situation beheben, indem er die Anwendung manuell neu startete. Kubernetes bietet Ihnen die Möglichkeit, Softwarefehler in Ihren Pods zu erkennen und sie automatisch durch neue Replikate zu ersetzen. Mit Kubernetes können Sie den Zustand Ihrer Anwendungen überwachen und fehlerhafte Instanzen automatisch ersetzen.
[Kubernetes unterstützt drei Arten von Zustandsprüfungen:](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)
1. Lebendigkeitstest
1. Startprobe (unterstützt in Kubernetes Version 1.16\$1)
1. Bereitschaftstest
[Kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), der Kubernetes-Agent, ist für die Ausführung aller oben genannten Prüfungen verantwortlich. Kubelet kann den Zustand eines Pods auf drei Arten überprüfen: Kubelet kann entweder einen Shell-Befehl im Container eines Pods ausführen, eine HTTP-GET-Anfrage an seinen Container senden oder einen TCP-Socket an einem bestimmten Port öffnen.
*Wenn Sie sich für eine `exec` basierte Probe entscheiden, die ein Shell-Skript in einem Container ausführt, stellen Sie sicher, dass der Shell-Befehl beendet wird, bevor der Wert abläuft.* `timeoutSeconds` Andernfalls wird Ihr Knoten über `` Prozesse verfügen, was zu einem Ausfall des Knotens führt.
## Empfehlungen
### Verwenden Sie Liveness Probe, um ungesunde Pods zu entfernen
Der Liveness Test kann *Deadlock-Bedingungen* erkennen, bei denen der Prozess zwar weiter ausgeführt wird, die Anwendung aber nicht mehr reagiert. Wenn Sie beispielsweise einen Webdienst ausführen, der Port 80 überwacht, können Sie einen Liveness-Test so konfigurieren, dass er eine HTTP-GET-Anforderung an den Port 80 des Pods sendet. Kubelet sendet regelmäßig eine GET-Anfrage an den Pod und erwartet eine Antwort. Wenn der Pod zwischen 200 und 399 antwortet, geht das Kubelet davon aus, dass der Pod fehlerfrei ist. Andernfalls wird der Pod als fehlerhaft markiert. Wenn ein Pod die Integritätsprüfungen kontinuierlich nicht besteht, beendet ihn das Kubelet.
Sie können es verwenden, `initialDelaySeconds` um die erste Sonde zu verzögern.
Wenn Sie die Liveness Probe verwenden, stellen Sie sicher, dass Ihre Anwendung nicht in eine Situation gerät, in der alle Pods gleichzeitig die Liveness Probe nicht bestehen, da Kubernetes versucht, alle Ihre Pods zu ersetzen, wodurch Ihre Anwendung offline geschaltet wird. Darüber hinaus wird Kubernetes weiterhin neue Pods erstellen, bei denen auch Liveness Probes nicht funktionieren, was die Kontrollebene unnötig belastet. Vermeiden Sie es, die Liveness Probe so zu konfigurieren, dass sie von einem Faktor abhängt, der außerhalb Ihres Pods liegt, z. B. einer externen Datenbank. Mit anderen Worten: Eine external-to-your-Pod Datenbank, die nicht reagiert, sollte nicht dazu führen, dass Ihre Pods ihre Liveness Probes nicht bestehen.
Der Beitrag [LIVENESS PROBES ARE DANGEROUS von Sandor Szücs beschreibt Probleme, die durch falsch konfigurierte Sonden verursacht werden](https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html) können.
### Verwenden Sie Startup Probe für Anwendungen, deren Start länger dauert
Wenn Ihre App zusätzliche Zeit zum Starten benötigt, können Sie die Startup Probe verwenden, um den Liveness and Readiness Test zu verzögern. Beispielsweise kann eine Java-App, die den Cache aus einer Datenbank hydratisieren muss, bis zu zwei Minuten dauern, bis sie voll funktionsfähig ist. Jede Liveness- oder Readiness Probe kann fehlschlagen, bis sie voll funktionsfähig ist. Durch die Konfiguration einer Startup Probe kann die Java-App wieder funktionsfähig sein, *bevor* Liveness oder Readiness Probe ausgeführt werden.
Bis die Startup Probe erfolgreich ist, sind alle anderen Probes deaktiviert. Sie können festlegen, wie lange Kubernetes maximal auf den Start der Anwendung warten soll. Wenn der Pod nach der konfigurierten Höchstzeit die Startup Probes immer noch nicht bestanden hat, wird er beendet und ein neuer Pod wird erstellt.
Die Startup Probe ähnelt der Liveness Probe — wenn sie fehlschlagen, wird der Pod neu erstellt. Wie Ricardo A. in seinem Beitrag [Fantastic Probes And How To Configure Them](https://medium.com/swlh/fantastic-probes-and-how-to-configure-them-fef7e030bd2f) erklärt, sollten Startup Probes verwendet werden, wenn die Startzeit einer Anwendung nicht vorhersehbar ist. Wenn Sie wissen, dass Ihre Anwendung zehn Sekunden benötigt, um zu starten, sollten Sie stattdessen Liveness/Readiness Probe with verwenden. `initialDelaySeconds`
### Verwenden Sie Readiness Probe, um eine teilweise Nichtverfügbarkeit festzustellen
*Während der Liveness Test Fehler in einer App erkennt, die durch das Beenden des Pods (also durch einen Neustart der App) behoben werden, erkennt Readiness Probe Situationen, in denen die App möglicherweise vorübergehend nicht verfügbar ist.* In diesen Situationen reagiert die App möglicherweise vorübergehend nicht mehr. Es wird jedoch davon ausgegangen, dass sie wieder fehlerfrei ist, sobald dieser Vorgang abgeschlossen ist.
Beispielsweise können Anwendungen während intensiver I/O Festplattenoperationen vorübergehend nicht zur Bearbeitung von Anfragen zur Verfügung stehen. In diesem Fall ist das Beenden des Pods der Anwendung keine Lösung. Gleichzeitig können zusätzliche Anfragen, die an den Pod gesendet werden, fehlschlagen.
Sie können die Readiness Probe verwenden, um eine vorübergehende Nichtverfügbarkeit in Ihrer App zu erkennen und das Senden von Anfragen an den zugehörigen Pod zu beenden, bis dieser wieder funktionsfähig ist. *Im Gegensatz zu Liveness Probe, bei der ein Ausfall zur Neuerstellung des Pods führen würde, würde ein fehlgeschlagener Readiness Probe bedeuten, dass der Pod keinen Traffic vom Kubernetes-Service empfängt*. Wenn die Readiness Probe erfolgreich ist, empfängt der Pod wieder Datenverkehr vom Service.
Vermeiden Sie es, genau wie bei der Liveness Probe, Readiness Probes zu konfigurieren, die von einer externen Ressource des Pods abhängen (z. B. einer Datenbank). Hier ist ein Szenario, in dem eine schlecht konfigurierte Readiness dazu führen kann, dass die Anwendung nicht mehr funktioniert. Wenn die Readiness Probe eines Pods fehlschlägt, obwohl die Datenbank der App nicht erreichbar ist, fallen auch andere Pod-Replikate gleichzeitig aus, da sie dieselben Integritätsprüfkriterien verwenden. *Wenn Sie den Test auf diese Weise einrichten, wird sichergestellt, dass die Readiness Probes des Pods immer dann fehlschlagen, wenn die Datenbank nicht verfügbar ist, und Kubernetes den Datenverkehr an alle Pods nicht mehr sendet.*
Ein Nebeneffekt der Verwendung von Readiness Probes besteht darin, dass sie die für die Aktualisierung von Bereitstellungen benötigte Zeit verlängern können. Neue Replikate empfangen keinen Datenverkehr, es sei denn, die Readiness Probes sind erfolgreich. Bis dahin empfangen alte Replikate weiterhin Datenverkehr.
## Umgang mit Störungen
Pods haben eine begrenzte Lebensdauer. Selbst wenn Sie Pods mit langer Laufzeit haben, sollten Sie sicherstellen, dass die Pods zu gegebener Zeit korrekt beendet werden. Abhängig von Ihrer Upgrade-Strategie müssen Sie bei Kubernetes-Cluster-Upgrades möglicherweise neue Worker-Knoten erstellen. Dazu müssen alle Pods auf neueren Knoten neu erstellt werden. Durch die richtige Bearbeitung von Terminierungen und Budgets für Pod-Unterbrechungen können Sie Serviceunterbrechungen vermeiden, da Pods aus älteren Knoten entfernt und auf neueren Knoten neu erstellt werden.
Die bevorzugte Methode zur Aktualisierung von Worker-Knoten besteht darin, neue Worker-Knoten zu erstellen und alte zu beenden. Bevor Sie Worker-Knoten beenden, sollten `drain` Sie dies tun. Wenn ein Worker-Knoten leer ist, werden alle seine Pods *sicher entfernt*. Sicher ist hier ein Schlüsselwort. Wenn Pods auf einem Worker geräumt werden, wird ihnen nicht einfach ein Signal gesendet. `SIGKILL` Stattdessen wird ein `SIGTERM` Signal an den Hauptprozess (PID 1) jedes Containers in den Pods gesendet, der geräumt wird. Nachdem das `SIGTERM` Signal gesendet wurde, gibt Kubernetes dem Prozess einige Zeit (Gnadenfrist), bevor ein `SIGKILL` Signal gesendet wird. Diese Übergangszeit beträgt standardmäßig 30 Sekunden. Sie können die Standardeinstellung überschreiben, indem Sie `grace-period` flag in kubectl verwenden oder in Ihrer Podspec deklarieren`terminationGracePeriodSeconds`.
`kubectl delete pod —grace-period=`
Es ist üblich, Container zu haben, in denen der Hauptprozess nicht die PID 1 hat. Stellen Sie sich diesen Python-basierten Probenbehälter vor:
```
$ kubectl exec python-app -it ps
PID USER TIME COMMAND
1 root 0:00 {script.sh} /bin/sh ./script.sh
5 root 0:00 python app.py
```
In diesem Beispiel empfängt das Shell-Skript`SIGTERM`, der Hauptprozess, der in diesem Beispiel zufällig eine Python-Anwendung ist, erhält kein `SIGTERM` Signal. Wenn der Pod beendet wird, wird die Python-Anwendung abrupt beendet. Dies kann behoben werden, indem der [https://docs.docker.com/engine/reference/builder/#entrypoint](https://docs.docker.com/engine/reference/builder/#entrypoint)Container geändert wird, um die Python-Anwendung zu starten. Alternativ können Sie ein Tool wie [dumb-init](https://github.com/Yelp/dumb-init) verwenden, um sicherzustellen, dass Ihre Anwendung Signale verarbeiten kann.
Sie können [Container-Hooks](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) auch verwenden, um ein Skript oder eine HTTP-Anfrage beim Start oder Stopp eines Containers auszuführen. Die `PreStop` Hook-Aktion wird ausgeführt, bevor der Container ein `SIGTERM` Signal empfängt, und muss abgeschlossen sein, bevor dieses Signal gesendet wird. Der `terminationGracePeriodSeconds` Wert gilt ab dem Zeitpunkt, zu dem die `PreStop` Hook-Aktion ausgeführt wird, nicht ab dem Zeitpunkt, zu dem das `SIGTERM` Signal gesendet wird.
## Empfehlungen
### Schützen Sie kritische Workloads mit Pod Disruption Budgets
Pod Disruption Budget oder PDB können den Räumungsprozess vorübergehend unterbrechen, wenn die Anzahl der Replikate einer Anwendung unter den angegebenen Schwellenwert fällt. Der Räumungsprozess wird fortgesetzt, sobald die Anzahl der verfügbaren Replikate den Schwellenwert überschreitet. Sie können PDB verwenden, um die Anzahl `minAvailable` und `maxUnavailable` Anzahl der Replikate zu deklarieren. Wenn Sie beispielsweise möchten, dass mindestens drei Kopien Ihrer App verfügbar sind, können Sie eine PDB erstellen.
```
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: my-svc-pdb
spec:
minAvailable: 3
selector:
matchLabels:
app: my-svc
```
Die obige PDB-Richtlinie weist Kubernetes an, den Räumungsprozess anzuhalten, bis drei oder mehr Replikate verfügbar sind. Das `PodDisruptionBudgets` Entleeren von Knoten wird respektiert. Während eines Upgrades einer verwalteten EKS-Knotengruppe [werden die Knoten mit einem Zeitlimit von fünfzehn Minuten](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html) entlastet. Wenn das Update nach fünfzehn Minuten nicht erzwungen wird (die Option wird in der EKS-Konsole als fortlaufendes Update bezeichnet), schlägt das Update fehl. Wenn das Update erzwungen wird, werden die Pods gelöscht.
[Für selbstverwaltete Knoten können Sie auch Tools wie [AWS Node Termination Handler](https://github.com/aws/aws-node-termination-handler) verwenden, der sicherstellt, dass die Kubernetes-Steuerebene angemessen auf Ereignisse reagiert, die dazu führen können, dass Ihre EC2-Instance nicht verfügbar ist, wie z. B. [EC2-Wartungsereignisse und EC2-Spot-Unterbrechungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html).](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) Es verwendet die Kubernetes-API, um den Knoten zu sperren, um sicherzustellen, dass keine neuen Pods geplant werden. Anschließend wird er entleert und alle laufenden Pods beendet.
Sie können Pod-Anti-Affinität verwenden, um die Pods eines Deployments auf verschiedenen Knoten zu planen und PDB-bedingte Verzögerungen bei Knoten-Upgrades zu vermeiden.
### Üben Sie sich in Chaos Engineering
Chaos Engineering ist die Disziplin des Experimentierens an einem verteilten System, um Vertrauen in die Fähigkeit des Systems aufzubauen, turbulenten Produktionsbedingungen standzuhalten.
In seinem Blog erklärt Dominik Tornow, dass [Kubernetes ein deklaratives System ist, bei dem "der Benutzer dem System](https://medium.com/@dominik.tornow/the-mechanics-of-kubernetes-ac8112eaa302) *eine Darstellung des gewünschten Systemzustands zur Verfügung stellt. Das System berücksichtigt dann den aktuellen Status und den gewünschten Zustand, um die Reihenfolge der Befehle für den Übergang vom aktuellen Zustand in den gewünschten Zustand zu bestimmen.* “ Das bedeutet, dass Kubernetes immer den *gewünschten Status* speichert und wenn das System davon abweicht, ergreift Kubernetes Maßnahmen, um den Status wiederherzustellen. Wenn beispielsweise ein Worker-Node nicht mehr verfügbar ist, verschiebt Kubernetes die Pods auf einen anderen Worker-Knoten. In ähnlicher Weise erstellt der [Deployment Controller bei einem `replica` Absturz eine neue](https://kubernetes.io/docs/concepts/architecture/controller/#design). `replica` Auf diese Weise beheben Kubernetes-Controller Fehler automatisch.
Chaos-Engineering-Tools wie [Gremlin](https://www.gremlin.com) helfen Ihnen dabei, die Resilienz Ihres Kubernetes-Clusters zu testen und einzelne Fehlerquellen zu identifizieren. Tools, die für künstliches Chaos in Ihrem Cluster (und darüber hinaus) sorgen, können systemische Schwächen aufdecken, bieten die Möglichkeit, Engpässe und Fehlkonfigurationen zu identifizieren und Probleme in einer kontrollierten Umgebung zu beheben. Die Philosophie von Chaos Engineering besteht darin, Dinge absichtlich zu beschädigen und die Infrastruktur einem Stresstest zu unterziehen, um unerwartete Ausfallzeiten zu minimieren.
### Verwenden Sie ein Service Mesh
Sie können ein Service Mesh verwenden, um die Ausfallsicherheit Ihrer Anwendung zu verbessern. Service Meshes ermöglichen die service-to-service Kommunikation und erhöhen die Beobachtbarkeit Ihres Microservices-Netzwerks. Die meisten Service Mesh-Produkte funktionieren so, dass neben jedem Dienst ein kleiner Netzwerk-Proxy läuft, der den Netzwerkverkehr der Anwendung abfängt und überprüft. Sie können Ihre Anwendung in einem Mesh platzieren, ohne Ihre Anwendung zu ändern. Mithilfe der integrierten Funktionen des Service-Proxys können Sie Netzwerkstatistiken generieren, Zugriffsprotokolle erstellen und ausgehenden Anfragen HTTP-Header für die verteilte Ablaufverfolgung hinzufügen.
Ein Service Mesh kann Ihnen dabei helfen, Ihre Microservices mit Funktionen wie automatischen Wiederholungen von Anfragen, Timeouts, Unterbrechungen und Ratenbegrenzung widerstandsfähiger zu machen.
Wenn Sie mehrere Cluster betreiben, können Sie ein Service Mesh verwenden, um die clusterübergreifende Kommunikation zu ermöglichen. service-to-service
### Service Meshes
+ [Istio](https://istio.io)
+ [Verlinkt D](http://linkerd.io)
+ [Konsul](https://www.consul.io)
## Beobachtbarkeit
Observability ist ein Überbegriff, der Überwachung, Protokollierung und Rückverfolgung umfasst. Anwendungen, die auf Microservices basieren, werden von Natur aus vertrieben. Im Gegensatz zu monolithischen Anwendungen, bei denen die Überwachung eines einzelnen Systems ausreicht, müssen Sie in einer verteilten Anwendungsarchitektur die Leistung der einzelnen Komponenten überwachen. Sie können Überwachungs-, Protokollierungs- und verteilte Ablaufverfolgungssysteme auf Clusterebene verwenden, um Probleme in Ihrem Cluster zu identifizieren, bevor sie Ihre Kunden stören.
Die in Kubernetes integrierten Tools zur Fehlerbehebung und Überwachung sind begrenzt. Der Metrics-Server sammelt Ressourcenmetriken und speichert sie im Speicher, speichert sie aber nicht dauerhaft. Sie können die Logs eines Pods mit kubectl einsehen, aber Kubernetes speichert Logs nicht automatisch. Und die Implementierung der verteilten Ablaufverfolgung erfolgt entweder auf der Ebene des Anwendungscodes oder mithilfe von Services-Meshes.
Die Erweiterbarkeit von Kubernetes kommt hier besonders gut zur Geltung. Mit Kubernetes können Sie Ihre bevorzugte zentralisierte Überwachungs-, Protokollierungs- und Tracing-Lösung einsetzen.
## Empfehlungen
### Überwachen Sie Ihre Anwendungen
Die Anzahl der Metriken, die Sie in modernen Anwendungen überwachen müssen, wächst kontinuierlich. Es ist hilfreich, wenn Sie Ihre Anwendungen automatisiert verfolgen können, sodass Sie sich darauf konzentrieren können, die Herausforderungen Ihrer Kunden zu lösen. Clusterweite Überwachungstools wie [Prometheus](https://prometheus.io) oder [CloudWatchContainer Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights.html) können Ihren Cluster und Ihre Arbeitslast überwachen und Ihnen Signale geben, wann oder am besten, bevor etwas schief geht.
Mit Überwachungstools können Sie Warnmeldungen erstellen, die Ihr Betriebsteam abonnieren kann. Ziehen Sie Regeln zur Aktivierung von Alarmen für Ereignisse in Betracht, die, wenn sie sich verschärfen, zu einem Ausfall führen oder die Anwendungsleistung beeinträchtigen können.
Wenn Sie sich nicht sicher sind, welche Kennzahlen Sie überwachen sollten, können Sie sich von diesen Methoden inspirieren lassen:
+ [RED-Methode](https://www.weave.works/blog/a-practical-guide-from-instrumenting-code-to-specifying-alerts-with-the-red-method). Steht für Anfragen, Fehler und Dauer.
+ [USE-Methode](http://www.brendangregg.com/usemethod.html). Steht für Auslastung, Sättigung und Fehler.
Der Beitrag [Best Practices for Alerting on Kubernetes](https://sysdig.com/blog/alerting-kubernetes/) von Sysdig enthält eine umfassende Liste von Komponenten, die sich auf die Verfügbarkeit Ihrer Anwendungen auswirken können.
### Verwenden Sie die Prometheus-Clientbibliothek, um Anwendungsmetriken bereitzustellen
Neben der Überwachung des Status der Anwendung und der Aggregation von Standardmetriken können Sie auch die [Prometheus-Clientbibliothek](https://prometheus.io/docs/instrumenting/clientlibs/) verwenden, um anwendungsspezifische benutzerdefinierte Metriken bereitzustellen, um die Beobachtbarkeit der Anwendung zu verbessern.
### Verwenden Sie zentralisierte Protokollierungstools, um Protokolle zu sammeln und zu speichern
Die Protokollierung in EKS lässt sich in zwei Kategorien einteilen: Protokolle der Steuerungsebene und Anwendungsprotokolle. Die Protokollierung auf der EKS-Kontrollebene stellt Prüf- und Diagnoseprotokolle direkt von der Steuerungsebene in die CloudWatch Protokolle in Ihrem Konto bereit. Anwendungsprotokolle sind Protokolle, die von Pods erstellt werden, die in Ihrem Cluster ausgeführt werden. Zu den Anwendungsprotokollen gehören Protokolle, die von Pods erstellt wurden, auf denen die Geschäftslogikanwendungen und Kubernetes-Systemkomponenten wie CoreDNS, Cluster Autoscaler, Prometheus usw. ausgeführt werden.
[EKS bietet fünf Arten](https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html) von Protokollen auf der Kontrollebene:
1. Protokolle der Kubernetes-API-Serverkomponenten
1. Audit
1. Authentifikator
1. Leiter des Controllers
1. Scheduler
Die Controller-Manager- und Scheduler-Protokolle können bei der Diagnose von Problemen mit der Steuerungsebene wie Engpässen und Fehlern helfen. Standardmäßig werden die Protokolle der EKS-Steuerungsebene nicht an Logs gesendet. CloudWatch Sie können die Protokollierung der Kontrollebene aktivieren und die Arten von Protokollen der EKS-Kontrollebene auswählen, die Sie für jeden Cluster in Ihrem Konto erfassen möchten
Das Sammeln von Anwendungsprotokollen erfordert die Installation eines Protokollaggregator-Tools wie [Fluent Bit](http://fluentbit.io), [Fluentd](https://www.fluentd.org) oder [CloudWatchContainer Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) in Ihrem Cluster.
Die Log-Aggregator-Tools von Kubernetes werden als DaemonSets Knoten ausgeführt und entfernen Container-Logs von Knoten. Anwendungsprotokolle werden dann zur Speicherung an ein zentrales Ziel gesendet. CloudWatch Container Insights kann beispielsweise entweder Fluent Bit oder Fluentd verwenden, um Protokolle zu sammeln und sie zur Speicherung an CloudWatch Logs zu senden. Fluent Bit und Fluentd unterstützen viele beliebte Protokollanalysesysteme wie Elasticsearch und InfluxDB, sodass Sie das Speicher-Backend für Ihre Logs ändern können, indem Sie Fluent Bit oder die Log-Konfiguration von Fluentd ändern.
### Verwenden Sie ein verteiltes Tracing-System, um Engpässe zu identifizieren
Eine typische moderne Anwendung besteht aus Komponenten, die über das Netzwerk verteilt sind, und ihre Zuverlässigkeit hängt vom ordnungsgemäßen Funktionieren der einzelnen Komponenten ab, aus denen die Anwendung besteht. Sie können eine verteilte Ablaufverfolgungslösung verwenden, um zu verstehen, wie Anfragen fließen und wie Systeme kommunizieren. Mithilfe von Ablaufverfolgungen können Sie erkennen, wo in Ihrem Anwendungsnetzwerk Engpässe bestehen, und Probleme verhindern, die zu kaskadierenden Ausfällen führen können.
Sie haben zwei Möglichkeiten, die Ablaufverfolgung in Ihren Anwendungen zu implementieren: Sie können entweder die verteilte Ablaufverfolgung auf Codeebene mithilfe gemeinsam genutzter Bibliotheken implementieren oder ein Service Mesh verwenden.
Die Implementierung von Tracing auf Codeebene kann nachteilig sein. Bei dieser Methode müssen Sie Änderungen an Ihrem Code vornehmen. Dies ist noch komplizierter, wenn Sie mehrsprachige Anwendungen haben. Sie sind auch für die Verwaltung einer weiteren Bibliothek in all Ihren Diensten verantwortlich.
Service Meshes wie [LinkerD](http://linkerd.io) und [Istio](http://istio.io) können verwendet werden, um verteiltes Tracing in Ihrer Anwendung mit minimalen Änderungen am Anwendungscode zu implementieren. Sie können Service Mesh verwenden, um die Generierung, Protokollierung und Ablaufverfolgung von Metriken zu standardisieren.
Tracing-Tools wie [AWS X-Ray](https://aws.amazon.com/xray/) und [Jaeger](https://www.jaegertracing.io) unterstützen sowohl Shared Library- als auch Service Mesh-Implementierungen.
Erwägen Sie, ein Tracing-Tool wie [AWS X-Ray](https://aws.amazon.com/xray/) oder [Jaeger](https://www.jaegertracing.io) zu verwenden, das beide Implementierungen (Shared Library und Service Mesh) unterstützt, damit Sie nicht zwischen Tools wechseln müssen, wenn Sie später Service Mesh einführen.
# EKS-Steuerebene
**Tipp**
[Informieren Sie](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) sich in Amazon EKS-Workshops über bewährte Verfahren.
Amazon Elastic Kubernetes Service (EKS) ist ein verwalteter Kubernetes-Service, mit dem Sie Kubernetes auf AWS ganz einfach ausführen können, ohne Ihre eigene Kubernetes-Steuerebene oder Ihre eigenen Worker-Knoten installieren, betreiben und warten zu müssen. Er läuft auf Upstream-Kubernetes und ist als Kubernetes-konform zertifiziert. Diese Konformität stellt sicher, dass EKS die Kubernetes-APIs unterstützt, genau wie die Open-Source-Community-Version, die Sie auf EC2 oder vor Ort installieren können. Bestehende Anwendungen, die auf Upstream-Kubernetes ausgeführt werden, sind mit Amazon EKS kompatibel.
EKS verwaltet automatisch die Verfügbarkeit und Skalierbarkeit der Kubernetes-Steuerebenenknoten und ersetzt automatisch fehlerhafte Knoten der Kontrollebene.
## EKS-Architektur
Die EKS-Architektur wurde entwickelt, um einzelne Fehlerquellen zu eliminieren, die die Verfügbarkeit und Beständigkeit der Kubernetes-Steuerebene beeinträchtigen könnten.
Die von EKS verwaltete Kubernetes-Steuerebene wird in einer von EKS verwalteten VPC ausgeführt. Die EKS-Steuerebene umfasst die Kubernetes-API-Serverknoten usw. Kubernetes-API-Serverknoten, die Komponenten wie den API-Server und den Scheduler `kube-controller-manager` ausführen und in einer Gruppe mit auto-scaling ausgeführt werden. EKS betreibt mindestens zwei API-Serverknoten in unterschiedlichen Availability Zones (AZs) innerhalb der AWS-Region. Aus Gründen der Haltbarkeit laufen die etcd-Serverknoten ebenfalls in einer Auto-Scaling-Gruppe, die sich über drei erstreckt. AZs EKS betreibt in jeder AZ ein NAT-Gateway, und API-Server und etcd-Server laufen in einem privaten Subnetz. Diese Architektur stellt sicher, dass ein Ereignis in einer einzelnen AZ die Verfügbarkeit des EKS-Clusters nicht beeinträchtigt.
Wenn Sie einen neuen Cluster erstellen, erstellt Amazon EKS einen hochverfügbaren Endpunkt für den verwalteten Kubernetes-API-Server, den Sie für die Kommunikation mit Ihrem Cluster verwenden (mithilfe von Tools wie). `kubectl` Der verwaltete Endpunkt verwendet NLB für den Lastenausgleich der Kubernetes-API-Server. EKS stellt außerdem zwei unterschiedliche [ENIs bereit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html), AZs um die Kommunikation mit Ihren Worker-Knoten zu erleichtern.
EKS-Netzwerkkonnektivität auf der Datenebene
![\[Konnektivität\]](http://docs.aws.amazon.com/de_de/eks/latest/best-practices/images/reliability/eks-data-plane-connectivity.jpeg)
Sie können [konfigurieren, ob der API-Server Ihres Kubernetes-Clusters](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html) vom öffentlichen Internet (über den öffentlichen Endpunkt) oder über Ihre VPC (mit dem ENIs EKS-verwalteten) oder von beiden aus erreichbar ist.
Unabhängig davon, ob Benutzer und Worker-Knoten über den öffentlichen Endpunkt oder das von EKS verwaltete ENI eine Verbindung zum API-Server herstellen, gibt es redundante Verbindungspfade.
## Empfehlungen
Lesen Sie sich die folgenden Empfehlungen durch.
## Überwachen Sie die Kennzahlen der Kontrollebene
Durch die Überwachung der Kubernetes-API-Metriken erhalten Sie Einblicke in die Leistung der Kontrollebene und können Probleme identifizieren. Eine fehlerhafte Kontrollebene kann die Verfügbarkeit der Workloads beeinträchtigen, die innerhalb des Clusters ausgeführt werden. Beispielsweise können schlecht geschriebene Controller die API-Server überlasten und die Verfügbarkeit Ihrer Anwendung beeinträchtigen.
Kubernetes stellt Metriken der Kontrollebene am Endpunkt zur Verfügung. `/metrics`
Sie können die bereitgestellten Metriken wie folgt anzeigen: `kubectl`
```
kubectl get --raw /metrics
```
Diese Metriken werden in einem [Prometheus-Textformat](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) dargestellt.
Sie können Prometheus verwenden, um diese Metriken zu sammeln und zu speichern. Im Mai 2020 CloudWatch wurde Unterstützung für die Überwachung von Prometheus-Metriken in CloudWatch Container Insights hinzugefügt. Sie können Amazon also auch CloudWatch zur Überwachung der EKS-Steuerebene verwenden. Sie können [Tutorial for Adding a New Prometheus Scrape Target: Prometheus KPI Server Metrics verwenden, um Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContainerInsights-Prometheus-Setup-configure.html#ContainerInsights-Prometheus-Setup-new-exporters) zu sammeln und ein CloudWatch Dashboard zur Überwachung der Kontrollebene Ihres Clusters zu erstellen.
[Kennzahlen zum Kubernetes-API-Server finden Sie hier.](https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go) `apiserver_request_duration_seconds`Kann beispielsweise angeben, wie lange die Ausführung von API-Anfragen dauert.
Erwägen Sie die Überwachung dieser Metriken auf der Kontrollebene:
### API-Server
| Metrik | Description |
| --- | --- |
| `apiserver_request_total` | Zähler der Apiserver-Anfragen, aufgeschlüsselt nach Verb, Probelaufwert, Gruppe, Version, Ressource, Bereich, Komponente und HTTP-Antwortcode. |
| `apiserver_request_duration_seconds*` | Histogramm der Antwortlatenz in Sekunden für jedes Verb, jeden Probelaufwert, jede Gruppe, Version, Ressource, Unterressource, jeden Bereich und jede Komponente. |
| `apiserver_admission_controller_admission_duration_seconds*` | Latenzhistogramm für den Zugangscontroller in Sekunden, identifiziert anhand des Namens und aufgeschlüsselt nach Vorgang, API-Ressource und Typ (validieren oder zulassen). |
| `apiserver_admission_webhook_rejection_count` | Anzahl der Webhook-Ablehnungen für die Zulassung. Identifiziert nach Name, Vorgang, Ablehnungscode, Typ (validieren oder zulassen), error\$1type (calling\$1webhook\$1error, apiserver\$1internal\$1error, no\$1error) |
| `rest_client_request_duration_seconds*` | Latenz-Histogramm in Sekunden anfordern. Aufgeschlüsselt nach Verb und URL. |
| `rest_client_requests_total` | Anzahl der HTTP-Anfragen, partitioniert nach Statuscode, Methode und Host. |
+ Zu den Histogramm-Metriken gehören die Suffixe \$1bucket, \$1sum und \$1count.
### usw
| Metrik | Description |
| --- | --- |
| `etcd_request_duration_seconds*` | Etcd-Anforderungslatenzhistogramm in Sekunden für jeden Vorgang und Objekttyp. |
| `apiserver_storage_db_total_size_in_bytes`oder `apiserver_storage_size_bytes` (ab EKS v1.28) | Größe der Etcd-Datenbank. |
+ Zu den Histogramm-Metriken gehören die Suffixe \$1bucket, \$1sum und \$1count.
Erwägen Sie, das [Kubernetes Monitoring Overview Dashboard zu verwenden, um Kubernetes-API-Serveranfragen](https://grafana.com/grafana/dashboards/14623) sowie Latenz- und Latenzmetriken usw. zu visualisieren und zu überwachen.
**Wichtig**
Wenn die Größenbeschränkung für die Datenbank überschritten wird, gibt etcd einen Alarm ohne Speicherplatz aus und nimmt keine weiteren Schreibanfragen mehr entgegen. Mit anderen Worten, der Cluster wird schreibgeschützt, und alle Anfragen zur Änderung von Objekten wie das Erstellen neuer Pods, das Skalieren von Bereitstellungen usw. werden vom API-Server des Clusters abgelehnt.
## Cluster-Authentifizierung
EKS unterstützt derzeit zwei Arten der Authentifizierung: [Inhaber-/Dienstkonto-Tokens](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) und IAM-Authentifizierung, bei der die [Webhook-Token-Authentifizierung](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) verwendet wird. Wenn Benutzer die Kubernetes-API aufrufen, übergibt ein Webhook ein in der Anfrage enthaltenes Authentifizierungstoken an IAM. Das Token, eine signierte Base-64-URL, wird von der AWS-Befehlszeilenschnittstelle ([AWS CLI](https://aws.amazon.com/cli/)) generiert.
Der IAM-Benutzer oder die IAM-Rolle, die den EKS-Cluster erstellt, erhält automatisch vollen Zugriff auf den Cluster. Sie können den Zugriff auf den EKS-Cluster verwalten, indem Sie die [aws-auth-Configmap](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) bearbeiten.
Wenn Sie die `aws-auth` Configmap falsch konfigurieren und den Zugriff auf den Cluster verlieren, können Sie trotzdem den Benutzer oder die Rolle des Clustererstellers verwenden, um auf Ihren EKS-Cluster zuzugreifen.
In dem unwahrscheinlichen Fall, dass Sie den IAM-Service in der AWS-Region nicht nutzen können, können Sie den Cluster auch mit dem Bearer-Token des Kubernetes-Servicekontos verwalten.
Erstellen Sie ein `super-admin` Konto, das alle Aktionen im Cluster ausführen darf:
```
kubectl -n kube-system create serviceaccount super-admin
```
Erstellen Sie eine Rollenbindung, die der Super-Admin-Cluster-Admin-Rolle zuweist:
```
kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin
```
Holen Sie sich das Geheimnis des Dienstkontos:
```
SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'`
```
Ruft das mit dem Secret verknüpfte Token ab:
```
TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode`
```
Dienstkonto und Token hinzufügen zu`kubeconfig`:
```
kubectl config set-credentials super-admin --token=$TOKEN
```
Stellen Sie den aktuellen Kontext ein, um das `kubeconfig` Super-Admin-Konto zu verwenden:
```
kubectl config set-context --current --user=super-admin
```
Final `kubeconfig` sollte so aussehen:
```
apiVersion: v1
clusters:
- cluster:
certificate-authority-data:
server: https://.gr7.us-west-2.eks.amazonaws.com
name: arn:aws:eks:us-west-2::cluster/
contexts:
- context:
cluster: arn:aws:eks:us-west-2::cluster/
user: super-admin
name: arn:aws:eks:us-west-2::cluster/
current-context: arn:aws:eks:us-west-2::cluster/
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2::cluster/
# user:
# exec:
# apiVersion: client.authentication.k8s.io/v1beta1
# args:
# - --region
# - us-west-2
# - eks
# - get-token
# - --cluster-name
# - <>
# command: aws
# env: null
- name: super-admin
user:
token: <>
```
## Zulassung: Webhooks
Kubernetes hat zwei Arten von Zulassungs-Webhooks: [Validierungs-Webhooks und mutierende Zulassungs-Webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers). Diese ermöglichen es einem Benutzer, die Kubernetes-API zu erweitern und Objekte zu validieren oder zu mutieren, bevor sie von der API akzeptiert werden. Schlechte Konfigurationen dieser Webhooks können die EKS-Steuerebene destabilisieren, indem sie kritische Clustervorgänge blockieren.
Um eine Beeinträchtigung kritischer Clusteroperationen zu vermeiden, sollten Sie entweder das Setzen von „Catch-All“ -Webhooks wie den folgenden vermeiden:
```
- name: "pod-policy.example.com"
rules:
- apiGroups: ["*"]
apiVersions: ["*"]
operations: ["*"]
resources: ["*"]
scope: "*"
```
Oder stellen Sie sicher, dass der Webhook über eine Fail-Open-Richtlinie mit einem Timeout von weniger als 30 Sekunden verfügt, um sicherzustellen, dass kritische Cluster-Workloads nicht beeinträchtigt werden, wenn Ihr Webhook nicht verfügbar ist.
### Blockieren Sie Pods mit unsicheren `sysctls`
`Sysctl`ist ein Linux-Hilfsprogramm, mit dem Benutzer Kernelparameter während der Laufzeit ändern können. Diese Kernelparameter steuern verschiedene Aspekte des Verhaltens des Betriebssystems, z. B. das Netzwerk, das Dateisystem, den virtuellen Speicher und die Prozessverwaltung.
Kubernetes ermöglicht das Zuweisen von `sysctl` Profilen für Pods. Kubernetes wird als sicher und unsicher eingestuft`systcls`. Sicher `sysctls` haben im Container oder Pod Namespaces, und ihre Einstellung hat keine Auswirkungen auf andere Pods auf dem Knoten oder den Knoten selbst. Im Gegensatz dazu sind unsichere Sysctls standardmäßig deaktiviert, da sie möglicherweise andere Pods stören oder den Knoten instabil machen können.
Da unsicher standardmäßig deaktiviert `sysctls` sind, erstellt das Kubelet keinen Pod mit einem unsicheren Profil. `sysctl` Wenn Sie einen solchen Pod erstellen, weist der Scheduler solche Pods wiederholt Knoten zu, während der Knoten ihn nicht starten kann. Diese Endlosschleife belastet letztendlich die Cluster-Steuerebene und macht den Cluster instabil.
Erwägen Sie, [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper-library/blob/377cb915dba2db10702c25ef1ee374b4aa8d347a/src/pod-security-policy/forbidden-sysctls/constraint.tmpl) oder [Kyverno](https://kyverno.io/policies/pod-security/baseline/restrict-sysctls/restrict-sysctls/) zu verwenden, um Pods mit unsicheren Daten zurückzuweisen. `sysctls`
## Umgang mit Cluster-Upgrades
Seit April 2021 wurde der Kubernetes-Veröffentlichungszyklus von vier Releases pro Jahr (einmal pro Quartal) auf drei Releases pro Jahr geändert. Eine neue Nebenversion (wie 1. **21** oder 1. **22**) wird ungefähr [alle fünfzehn Wochen](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/#what-s-changing-and-when) veröffentlicht. Ab Kubernetes 1.19 wird jede Nebenversion nach ihrer ersten Veröffentlichung etwa zwölf Monate lang unterstützt. Mit dem Aufkommen von Kubernetes v1.28 hat sich der Kompatibilitätsunterschied zwischen der Steuerungsebene und den Worker-Knoten von n-2 auf n-3 Nebenversionen ausgeweitet. [Weitere Informationen finden Sie unter Bewährte Methoden für Cluster-Upgrades.](cluster-upgrades.md)
## Konnektivität von Cluster-Endpunkten
Bei der Arbeit mit Amazon EKS (Elastic Kubernetes Service) können Verbindungstimeouts oder Fehler bei Ereignissen wie der Skalierung oder dem Patchen der Kubernetes-Steuerebene auftreten. Diese Ereignisse können dazu führen, dass die Kube-Apiserver-Instanzen ersetzt werden, was möglicherweise dazu führt, dass bei der Auflösung des FQDN unterschiedliche IP-Adressen zurückgegeben werden. In diesem Dokument werden bewährte Methoden für Kubernetes-API-Nutzer zur Aufrechterhaltung einer zuverlässigen Konnektivität beschrieben.
**Anmerkung**
Die Implementierung dieser bewährten Methoden erfordert möglicherweise Aktualisierungen der Client-Konfigurationen oder der Skripte, um neue Strategien zur erneuten DNS-Auflösung und zum erneuten Versuch effektiv handhaben zu können.
Das Hauptproblem ist das clientseitige DNS-Caching und das Potenzial für veraltete IP-Adressen von EKS-Endpunkten — *öffentliche NLB für öffentliche Endgeräte oder X-ENI für private* Endgeräte. Wenn die Kube-Apiserver-Instanzen ersetzt werden, wird der vollqualifizierte Domainname (FQDN) möglicherweise zu neuen IP-Adressen aufgelöst. Aufgrund der DNS Time to Live (TTL) -Einstellungen, die in der von AWS verwalteten Route 53 53-Zone auf 60 Sekunden festgelegt sind, können Clients jedoch für einen kurzen Zeitraum weiterhin veraltete IP-Adressen verwenden.
Um diese Probleme zu beheben, sollten Kubernetes-API-Nutzer (wie Kubectl, CI/CD Pipelines und benutzerdefinierte Anwendungen) die folgenden bewährten Methoden implementieren:
+ Implementieren Sie die DNS-Neuauflösung
+ Implementieren Sie Wiederholungen mit Backoff und Jitter. Lesen Sie zum Beispiel diesen Artikel mit dem Titel [Fehler passieren](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ Implementieren Sie Client-Timeouts. Legen Sie geeignete Timeouts fest, um zu verhindern, dass Anfragen mit langer Laufzeit Ihre Anwendung blockieren. Beachten Sie, dass einige Kubernetes-Clientbibliotheken, insbesondere solche, die von OpenAPI-Generatoren generiert werden, das Einstellen benutzerdefinierter Timeouts möglicherweise nicht einfach zulassen.
+ Beispiel 1 mit kubectl:
```
kubectl get pods --request-timeout 10s # default: no timeout
```
+ Beispiel 2 mit Python: Der [Kubernetes-Client stellt einen](https://github.com/kubernetes-client/python/blob/release-30.0/kubernetes/client/api_client.py#L120) \$1request\$1timeout-Parameter bereit
Durch die Implementierung dieser Best Practices können Sie die Zuverlässigkeit und Belastbarkeit Ihrer Anwendungen bei der Interaktion mit der Kubernetes-API erheblich verbessern. Denken Sie daran, diese Implementierungen gründlich zu testen, insbesondere unter simulierten Ausfallbedingungen, um sicherzustellen, dass sie sich bei tatsächlichen Skalierungs- oder Patching-Ereignissen erwartungsgemäß verhalten.
## Große Cluster ausführen
EKS überwacht aktiv die Auslastung der Instanzen auf der Kontrollebene und skaliert sie automatisch, um eine hohe Leistung zu gewährleisten. Sie sollten jedoch potenzielle Leistungsprobleme und -beschränkungen innerhalb von Kubernetes und Kontingente in AWS-Services berücksichtigen, wenn Sie große Cluster ausführen.
+ Bei Clustern mit mehr als 1000 Services kann es laut den [vom Team durchgeführten Tests](https://www.projectcalico.org/comparing-kube-proxy-modes-iptables-or-ipvs/) zu Netzwerklatenz kommen, wenn sie `kube-proxy` im `iptables` Modus verwendet werden. ProjectCalico Die Lösung besteht darin, in den [`ipvs`Modus „`kube-proxy`Im Betrieb](ipvs.md)“ zu wechseln.
+ Möglicherweise kommt es auch zu einer [Drosselung von EC2-API-Anfragen](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html), wenn das CNI IP-Adressen für Pods anfordern muss oder wenn Sie häufig neue EC2-Instances erstellen müssen. Sie können die Anzahl der EC2-API-Aufrufe reduzieren, indem Sie das CNI so konfigurieren, dass IP-Adressen zwischengespeichert werden. Sie können größere EC2-Instance-Typen verwenden, um EC2-Skalierungsereignisse zu reduzieren.
## Zusätzliche Ressourcen:
+ [Entmystifizierung von Cluster-Netzwerken für Amazon EKS-Worker-Knoten](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes/)
+ [Zugriffskontrolle für Amazon EKS-Cluster-Endpunkte](https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html)
+ [AWS re:Invent 2019: Amazon EKS unter der Haube (-R1) CON421](https://www.youtube.com/watch?v=7vxDWDD2YnM)
# 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.