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.

Ausführung hochverfügbarer Anwendungen

Ihre Kunden erwarten, dass Ihre Anwendung immer verfügbar ist, auch wenn Sie Änderungen vornehmen und insbesondere bei Datenverkehrsspitzen. Eine skalierbare und robuste Architektur sorgt dafür, dass Ihre Anwendungen und Dienste ohne Unterbrechungen laufen, was Ihre Benutzer zufrieden stellt. 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ähig zu machen.

Mit Kubernetes können Sie Ihre Anwendungen betreiben und sie hochverfügbar und belastbar ausführen. Das deklarative Management stellt sicher, dass Kubernetes, sobald Sie die Anwendung eingerichtet haben, kontinuierlich versucht, den aktuellen Status mit dem gewünschten Status abzugleichen.

Empfehlungen

Konfigurieren Sie Budgets für Pod-Unterbrechungen

Budgets für Pod-Unterbrechungen werden verwendet, um das Ausmaß der gleichzeitigen Unterbrechungen zu begrenzen, die bei einer Anwendung auftreten können. Sie sollten für Workloads konfiguriert werden, wenn es wichtig ist, immer einen Teil dieser Arbeitslast verfügbar zu haben. EKS Auto Mode, Karpenter und Cluster Autoscaler kennen die konfigurierten Pod-Disruption-Budgets und halten sich beim Herunterskalieren daran. EKS Auto Mode, Karpenter und Managed Node Groups halten sich bei der Aktualisierung von Knoten auch an die Budgets für Pod-Unterbrechungen

Vermeiden Sie den Betrieb von Singleton-Pods

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. Wenn ein Pod, der durch ein Deployment erstellt wurde, ausfällt oder beendet wird, startet der Deployment Controller einen neuen Pod, um sicherzustellen, dass die angegebene Anzahl von Replikat-Pods immer läuft.

Führen Sie mehrere Replikate aus

Das Ausführen mehrerer Replikat-Pods einer App mithilfe einer Bereitstellung trägt dazu bei, dass diese hochverfügbar ausgeführt wird. 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 je nach Workload-Bedarf 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, Pod-Anti-Affinität oder Pod-Topologie-Spread-Beschränkungen zu verwenden, um die 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 AZs ausführen.

Verwenden von Pod-Anti-Affinitätsregeln

Das folgende Manifest weist den Kubernetes-Scheduler an, Pods lieber auf separaten Knoten und AZs zu platzieren. Es sind keine unterschiedlichen Nodes oder AZ erforderlich, da Kubernetes in diesem Fall keine Pods planen kann, sobald in jeder AZ ein Pod läuft. Wenn Ihre Anwendung nur drei Replikate benötigt, können Sie requiredDuringSchedulingIgnoredDuringExecution dafür verwendentopologyKey: 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

Verwendung von Streubeschränkungen der Pod-Topologie

Ähnlich wie bei den Pod-Anti-Affinitätsregeln ermöglichen es Ihnen die Einschränkungen der Verteilung der Pod-Topologie, Ihre Anwendung für verschiedene Ausfall- (oder Topologie-) Domänen wie Hosts oder AZs verfügbar zu machen. Dieser Ansatz eignet sich sehr gut, wenn Sie versuchen, Fehlertoleranz und Verfügbarkeit sicherzustellen, indem Sie mehrere Replikate in jeder der verschiedenen Topologiedomänen verwenden. Pod-Anti-Affinitätsregeln können dagegen leicht zu einem Ergebnis führen, wenn Sie ein einzelnes Replikat in einer Topologiedomäne haben, da die Pods mit einer Antiaffinität zueinander eine abstoßende Wirkung haben. In solchen Fällen ist ein einzelnes Replikat auf einem dedizierten Knoten weder ideal für Fehlertoleranz noch für eine sinnvolle Nutzung der Ressourcen. Durch Einschränkungen der Topologieverteilung haben Sie mehr Kontrolle über die Streuung oder Verteilung, die der Scheduler auf die Topologiedomänen anwenden sollte. Hier sind einige wichtige Eigenschaften, die Sie bei diesem Ansatz verwenden sollten:

Zusätzlich zu den oben genannten Feldern gibt es weitere Felder, über die Sie in der Kubernetes-Dokumentation mehr erfahren können.

Die Einschränkungen der Pod-Topologie verteilen sich auf 3 AZs

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 Kubernetes Metrics Server aus

Installieren Sie den Kubernetes-Metrikserver, um Ihre Anwendungen zu skalieren. Kubernetes-Autoscaler-Add-Ons wie HPA und VPA müssen die Messwerte von Anwendungen verfolgen, um sie skalieren zu können. Der Metrics-Server sammelt Ressourcenmetriken, anhand derer Skalierungsentscheidungen getroffen werden können. Die Metriken werden aus Kubelets gesammelt und im Metrics-API-Format bereitgestellt. https://github.com/kubernetes/metrics

Der Metrikserver speichert keine Daten und ist keine Überwachungslösung. Sein Zweck besteht darin, Messwerte zur CPU- und Speichernutzung anderen Systemen zur Verfügung zu stellen. 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, um den Metrics-Server in Ihrem EKS-Cluster zu installieren.

Horizontaler Pod Autoscaler (HPA)

HPA kann Ihre Anwendung automatisch an die Nachfrage anpassen und Sie so vermeiden, dass Ihre Kunden in Spitzenzeiten beeinträchtigt werden. Es ist als Regelkreis in Kubernetes implementiert, der regelmäßig Metriken von APIs abfragt, die Ressourcenmetriken bereitstellen.

HPA kann Metriken von den folgenden APIs abrufen: 1. metrics.k8s.ioauch 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 enthalten. 3. external.metrics.k8s.io — Stellt Metriken bereit, die sich außerhalb Ihres Kubernetes-Clusters befinden (E.g., SQS-Warteschlangentiefe, ELB-Latenz).

Sie müssen eine dieser drei APIs verwenden, 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 Messwerte verwenden, um Ihre Anwendung anhand anderer Metriken als der CPU- oder Speicherauslastung zu skalieren. https://github.com/kubernetes-sigs/custom-metrics-apiserverAPI-Server für benutzerdefinierte Messwerte stellen die custom-metrics.k8s.io API bereit, die HPA zur automatischen Skalierung von Anwendungen verwenden kann.

Sie können die Prometheus Adapter for Kubernetes Metrics APIs verwenden, um Metriken von Prometheus zu sammeln und mit der HPA zu verwenden. In diesem Fall stellt der Prometheus-Adapter Prometheus-Metriken im Metrics-API-Format bereit. 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 dem Horizontal Pod Autoscaler, wie der Name schon sagt, die Möglichkeit, Bereitstellungen mithilfe von Metriken zu skalieren, die sich außerhalb des Kubernetes-Clusters befinden. Beispielsweise ist es bei Workloads zur Stapelverarbeitung ü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 Containerskalierung auf der Grundlage einer Reihe von benutzerdefinierten Ereignissen steuern kann. In diesem AWS-Blog wird beschrieben, wie Amazon Managed Service for Prometheus für die automatische Skalierung von Kubernetes-Workloads verwendet wird.

Vertical 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 verwenden, um Pod-Replikate automatisch zu skalieren oder Skalierungsempfehlungen abzugeben.

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 neu erstellt, der skaliert werden muss.

Die EKS-Dokumentation enthält eine exemplarische Vorgehensweise für die Einrichtung von VPA.

Das Fairwinds Goldilocks-Projekt bietet ein Dashboard zur Visualisierung von VPA-Empfehlungen für CPU- und Speicheranforderungen und -limits. Im VPA-Aktualisierungsmodus können Sie Pods basierend auf den 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, um Ihre Anwendungen kontinuierlich zu aktualisieren, ohne Ihre Kunden zu stören.

Schauen wir uns einige der Best Practices an, die es ermöglichen, Änderungen schnell bereitzustellen, ohne die Verfügbarkeit zu beeinträchtigen.

Haben Sie einen Mechanismus, um Rollbacks durchzuführen

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 Aktualisieren des Container-Images. Sie können es verwendenkubectl, 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 deploymentzeigt Ihnen die aufgezeichneten Änderungen an Deployments in Ihrem Cluster. Sie können eine Änderung rückgängig machen, indem Sie. kubectl rollout undo deployment <DEPLOYMENT_NAME>

Wenn Sie eine Bereitstellung aktualisieren, für die eine Neuerstellung der Pods erforderlich ist, führt Deployment standardmäßig ein fortlaufendes Update durch. Mit anderen Worten, Kubernetes aktualisiert nur einen Teil der laufenden Pods in einer Bereitstellung und nicht alle Pods gleichzeitig. Sie können mithilfe von Property steuern, wie Kubernetes fortlaufende Aktualisierungen durchführt. RollingUpdateStrategy

Wenn Sie ein Rolling Update eines Deployments durchführen, können Sie die Max Unavailable Eigenschaft verwenden, um die maximale Anzahl von Pods anzugeben, die während des Updates nicht verfügbar sein dürfen. 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 standardmäßig einen Wert max unavailable von 25% fest. Wenn Sie also 100 Pods haben, sind während eines Rollouts möglicherweise nur 75 Pods aktiv. Wenn Ihre Anwendung mindestens 80 Pods benötigt, kann dieser Rollout störend sein. Stattdessen können Sie einen Wert von 20% festlegenmax 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, die es Ihnen ermöglichen, die Zeit durch ein Rollback effektiv zurückzudrehen, machen Verbesserungen und Experimente sicherer. Blue/green Bereitstellungen bieten Ihnen eine Methode, mit der Sie die Änderungen schnell rückgängig machen können, 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 überprüft haben, dass die Pods im neuen Deployment fehlerfrei laufen, können Sie damit beginnen, Traffic an das neue Deployment zu senden, indem Sie die selector Spezifikation im Service ändern, die den Datenverkehr an die Pods Ihrer Anwendung weiterleitet.

Mit vielen Tools für die kontinuierliche Integration wie Flux, Jenkins und Spinnaker können Sie Bereitstellungen automatisieren. blue/green Der AWS-Container-Blog enthält eine exemplarische Vorgehensweise zur Verwendung von AWS Load Balancer Controller: Verwendung von AWS Load Balancer Controller für die Bereitstellung, Bereitstellung und Tests blue/green A/B

Verwenden Sie Canary-Bereitstellungen

Bei Canary-Bereitstellungen handelt es sich um eine Variante von blue/green Bereitstellungen, mit der das Risiko von Änderungen erheblich verringert werden kann. Bei dieser Bereitstellungsstrategie erstellen Sie neben Ihrem alten Deployment ein neues Deployment mit weniger Pods und leiten einen kleinen Prozentsatz des Traffics auf das neue Deployment um. Wenn Kennzahlen darauf hindeuten, dass die neue Version genauso gut oder besser als die vorhandene Version abschneidet, erhöhen Sie schrittweise den Traffic zur neuen Bereitstellung und skalieren ihn, bis der gesamte Datenverkehr auf die neue Bereitstellung umgeleitet wird. Wenn ein Problem auftritt, können Sie den gesamten Datenverkehr an die alte Bereitstellung weiterleiten und das Senden des Datenverkehrs an die neue Bereitstellung beenden.

Obwohl Kubernetes keine native Methode zur Durchführung von Canary-Deployments bietet, können Sie Tools wie https://github.com/weaveworks/flagger 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 die Anwendung manuell neu gestartet wurde. Kubernetes bietet Ihnen die Möglichkeit, Softwarefehler in Ihren Pods zu erkennen und diese 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/

Kubelet, der Kubernetes-Agent, ist für die Durchfü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 eine exec basierte Probe wählen, 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 verfügt Ihr Knoten über <defunct> Prozesse, die zum Ausfall des Knotens führen.

Empfehlungen

Verwenden Sie Liveness Probe, um ungesunde Pods zu entfernen

Die Liveness Probe kann Deadlock-Bedingungen erkennen, bei denen der Prozess zwar weiterläuft, die Anwendung jedoch nicht mehr reagiert. Wenn Sie beispielsweise einen Webservice ausführen, der auf Port 80 lauscht, können Sie einen Livenes-Test so konfigurieren, dass er eine HTTP GET-Anfrage an 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 gesund ist; andernfalls wird der Pod als fehlerhaft markiert. Wenn ein Pod die Zustandsprüfungen kontinuierlich nicht besteht, wird er vom Kubelet beendet.

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 gerendert wird. Darüber hinaus wird Kubernetes weiterhin neue Pods erstellen, bei denen auch die Liveness Probes ausfallen, was die Steuerungsebene 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 externe Datenbank, die nicht auf deinen Pod reagiert, sollte nicht dazu führen, dass deine Pods ihre Liveness Probes ausfallen lassen.

Sandor Szücs beschreibt in seinem Beitrag LIVENESS PROBES ARE DANGEROUS Probleme, die durch falsch konfigurierte Sonden verursacht werden 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 die Liveness and Readiness Probe zu verzögern. Beispielsweise kann es bei einer Java-App, die den Cache aus einer Datenbank hydratisieren muss, bis zu zwei Minuten dauern, bis sie voll funktionsfähig ist. Jeder Liveness- oder Readiness-Test kann fehlschlagen, bis er 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 die maximale Zeit definieren, die Kubernetes auf den Start der Anwendung warten soll. Wenn der Pod nach der maximal konfigurierten Zeit die Startup Probes immer noch nicht besteht, wird er beendet und ein neuer Pod wird erstellt.

Die Startup Probe ähnelt der Liveness Probe — wenn sie ausfallen, wird der Pod neu erstellt. Wie Ricardo A. in seinem Beitrag Fantastic Probes And How To Configure Them 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 zu erkennen

Während die Liveness Probe Fehler in einer App erkennt, die durch das Beenden des Pods (d. h. durch einen Neustart der App) behoben werden, erkennt Readiness Probe Bedingungen, unter 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 erwartet, dass sie nach Abschluss dieses Vorgangs wieder einwandfrei funktioniert.

Beispielsweise sind Anwendungen bei intensiven I/O Festplattenoperationen möglicherweise vorübergehend nicht verfügbar, um Anfragen zu bearbeiten. In diesem Fall ist das Beenden des Pods der Anwendung keine Abhilfe; 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 Pod zu beenden, bis dieser wieder funktionsfähig ist. Im Gegensatz zu Liveness Probe, bei der ein Ausfall zu einer Neuerstellung des Pods führen würde, würde eine fehlgeschlagene 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 genau wie beim Liveness Probe die Konfiguration von Readiness Probes, die von einer Ressource abhängen, die sich außerhalb des Pods befindet (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 ausfällt und die Datenbank der App nicht erreichbar ist, schlagen auch andere Pod-Replikate gleichzeitig fehl, da sie dieselben Integritätsprüfungskriterien verwenden. Wenn Sie den Test auf diese Weise einrichten, wird sichergestellt, dass die Readiness-Probes des Pods immer dann ausfallen, wenn die Datenbank nicht verfügbar ist, und Kubernetes den Datenverkehr nicht mehr an alle Pods sendet.

Ein Nebeneffekt der Verwendung von Readiness Probes ist, dass sie die Zeit verlängern können, die für die Aktualisierung von Deployments benötigt wird. Neue Replikate erhalten keinen Datenverkehr, es sei denn, die Readiness Probes sind erfolgreich. Bis dahin empfangen alte Repliken weiterhin Traffic.

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. Eine angemessene Terminierungsbehandlung und Budgets für Pod-Unterbrechungen können Ihnen helfen, Serviceunterbrechungen zu vermeiden, da Pods von ä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 geleert wird, werden alle seine Pods sicher entfernt. Sicher ist hier ein Schlüsselwort. Wenn Pods auf einem Worker entfernt 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 eine gewisse Zeit (Nachfrist), bevor ein SIGKILL Signal gesendet wird. Diese Nachfrist beträgt standardmäßig 30 Sekunden. Sie können die Standardeinstellung überschreiben, indem Sie das grace-period Flag in kubectl verwenden oder in Ihrem Podspec deklarierenterminationGracePeriodSeconds.

kubectl delete pod <pod name> —grace-period=<seconds>

Es ist üblich, Container zu haben, in denen der Hauptprozess keine PID 1 hat. Betrachten Sie diesen Python-based Probenbehälter:

$ 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 SIGTERM das Shell-Skript den Hauptprozess, der in diesem Beispiel zufällig eine Python-Anwendung ist, kein SIGTERM Signal. Wenn der Pod beendet wird, wird die Python-Anwendung abrupt beendet. Dies kann behoben werden, indem der Container geändert wird, um ENTRYPOINT die Python-Anwendung zu starten. Alternativ können Sie ein Tool wie dumb-init verwenden, um sicherzustellen, dass Ihre Anwendung Signale verarbeiten kann.

Sie können Container-Hooks auch verwenden, um ein Skript oder eine HTTP-Anfrage beim Start oder Stopp des 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 Beginn der Ausführung der PreStop Hook-Aktion, nicht ab dem Senden des SIGTERM Signals.

Empfehlungen

Schützen Sie kritische Workloads mit Pod Disruption Budgets

Pod Disruption Budget oder PDB können den Löschvorgang vorübergehend stoppen, wenn die Anzahl der Replikate einer Anwendung unter den angegebenen Schwellenwert fällt. Der Löschvorgang wird fortgesetzt, sobald die Anzahl der verfügbaren Replikate den Schwellenwert überschritten hat. Sie können PDB verwenden, um die Anzahl der Replikate zu minAvailable deklarierenmaxUnavailable. 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 Löschvorgang anzuhalten, bis drei oder mehr Replikate verfügbar sind. PodDisruptionBudgetsDie Belastung der Knoten wird respektiert. Bei einem Upgrade einer EKS-verwalteten Knotengruppe werden die Knoten mit einem Timeout von fünfzehn Minuten geleert. Wenn das Update nach fünfzehn Minuten nicht erzwungen wird (die Option heißt in der EKS-Konsole Rolling Update), 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 verwenden, der sicherstellt, dass die Kubernetes-Steuerungsebene angemessen auf Ereignisse reagiert, die dazu führen können, dass Ihre EC2-Instance nicht verfügbar ist, wie https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html EC2-Wartungsereignisse und EC2-Spot-Unterbrechungen. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html Es verwendet die Kubernetes-API, um den Knoten abzusperren, um sicherzustellen, dass keine neuen Pods geplant sind. Anschließend wird der Knoten geleert 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 Node-Upgrades zu vermeiden.

Üben Sie sich im 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 eine Darstellung des gewünschten Zustands des Systems zur Verfügung stellt. Das System berücksichtigt dann den aktuellen Zustand und den gewünschten Zustand, um die Reihenfolge der Befehle für den Übergang vom aktuellen Zustand zum gewünschten Zustand zu bestimmen. “ Das bedeutet, dass Kubernetes immer den gewünschten Status speichert. Wenn das System davon abweicht, ergreift Kubernetes Maßnahmen, um den Status wiederherzustellen. Wenn beispielsweise ein Worker-Knoten nicht mehr verfügbar ist, verschiebt Kubernetes die Pods auf einen anderen Worker-Knoten. Ebenso erstellt der Deployment Controller bei einem replica Absturz einen neuen. replica Auf diese Weise beheben Kubernetes-Controller Fehler automatisch.

Chaos-Engineering-Tools wie Gremlin helfen Ihnen dabei, die Widerstandsfähigkeit 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 und bieten die Möglichkeit, Engpässe und Fehlkonfigurationen zu identifizieren und Probleme in einer kontrollierten Umgebung zu beheben. Die Philosophie von Chaos Engineering spricht sich dafür aus, Dinge absichtlich kaputt zu machen 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 Kommunikation zwischen Diensten und verbessern 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 ihn Netzwerkstatistiken generieren lassen, 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 Wiederholungsversuchen, Timeouts, Leitungsunterbrechungen und Ratenbegrenzungen widerstandsfähiger zu machen.

Wenn Sie mehrere Cluster betreiben, können Sie ein Service Mesh verwenden, um die clusterübergreifende Kommunikation von Service zu Service zu ermöglichen.

Service Meshes

Beobachtbarkeit

Beobachtbarkeit ist ein Überbegriff, der Überwachung, Protokollierung und Rückverfolgung umfasst. Anwendungen, die auf Microservices basieren, werden von Natur aus verteilt. Im Gegensatz zu monolithischen Anwendungen, bei denen die Überwachung eines einzelnen Systems ausreicht, müssen Sie in einer verteilten Anwendungsarchitektur die Leistung jeder Komponente überwachen. Sie können Überwachungs-, Protokollierungs- und verteilte Verfolgungssysteme 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 jedoch nicht. Sie können die Logs eines Pods mit kubectl einsehen, aber Kubernetes speichert Logs nicht automatisch. Und die Implementierung von verteiltem Tracing erfolgt entweder auf der Ebene des Anwendungscodes oder mithilfe von Services-Meshes.

Hier kommt die Erweiterbarkeit von Kubernetes zum Vorschein. Mit Kubernetes können Sie Ihre bevorzugte zentrale Überwachungs-, Protokollierungs- und Tracing-Lösung verwenden.

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 über eine automatisierte Methode zur Nachverfolgung Ihrer Anwendungen verfügen, damit Sie sich auf die Lösung der Herausforderungen Ihrer Kunden konzentrieren können. Cluster-wide Überwachungstools wie Prometheus oder CloudWatch Container Insights können Ihren Cluster und Ihre Arbeitslast überwachen und Ihnen Signale geben, wenn oder am besten noch bevor etwas schief geht.

Mithilfe von Überwachungstools können Sie Warnmeldungen erstellen, die Ihr Betriebsteam abonnieren kann. Beachten Sie Regeln, um Alarme für Ereignisse zu aktivieren, 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:

Sysdigs Beitrag Bewährte Methoden für Warnmeldungen auf Kubernetes 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 verfügbar zu machen

Neben der Überwachung des Status der Anwendung und der Aggregation von Standardmetriken können Sie die Prometheus-Clientbibliothek auch verwenden, um anwendungsspezifische benutzerdefinierte Metriken bereitzustellen und so 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 Kontrollebene und Anwendungsprotokolle. Mit der EKS-Protokollierung auf der Kontrollebene werden Prüf- und Diagnoseprotokolle direkt von der Steuerungsebene in die CloudWatch Protokolle in Ihrem Konto übertragen. 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 von Protokollen auf Steuerungsebene:

Die Protokolle des Controller-Managers und des Schedulers können helfen, Probleme auf der Steuerungsebene wie Engpässe und Fehler zu diagnostizieren. Standardmäßig werden EKS-Protokolle der Steuerungsebene nicht an Logs gesendet. CloudWatch Sie können die Protokollierung der Kontrollebene aktivieren und die Arten von EKS-Protokollen der Kontrollebene auswählen, die Sie für jeden Cluster in Ihrem Konto erfassen möchten

Für das Sammeln von Anwendungsprotokollen muss ein Log-Aggregator-Tool wie Fluent Bit, Fluentd oder CloudWatch Container Insights in Ihrem Cluster installiert werden.

Die Kubernetes-Log-Aggregator-Tools werden als DaemonSets ausgeführt und entfernen Container-Logs von Knoten. Die 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 die Log-Konfiguration von Fluent Bit oder Fluentd ändern.

Verwenden Sie ein verteiltes Tracing-System, um Engpässe zu identifizieren

Eine typische moderne Anwendung hat Komponenten, die über das Netzwerk verteilt sind, und ihre Zuverlässigkeit hängt von der ordnungsgemäßen Funktion der einzelnen Komponenten ab, aus denen die Anwendung besteht. Sie können eine verteilte Ablaufverfolgungslösung verwenden, um zu verstehen, wie Anfragen ablaufen und wie Systeme kommunizieren. Mithilfe von Traces können Sie feststellen, wo Engpässe in Ihrem Anwendungsnetzwerk bestehen, und Probleme vermeiden, die zu kaskadierenden Ausfällen führen können.

Sie haben zwei Möglichkeiten, Tracing in Ihren Anwendungen zu implementieren: Sie können entweder verteiltes Tracing 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 Pflege einer weiteren Bibliothek innerhalb Ihrer Dienste verantwortlich.

Service Meshes wie LinkerD und Istio 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 und Jaeger unterstützen sowohl X-Ray Implementierungen gemeinsam genutzter Bibliotheken als auch Service Mesh-Implementierungen.

Erwägen Sie, ein Tracing-Tool wie AWS X-Ray oder Jaeger zu verwenden, das beide Implementierungen (gemeinsam genutzte Bibliothek und Service Mesh) unterstützt, sodass Sie die Tools nicht wechseln müssen, wenn Sie später Service Mesh einführen.