Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

EKS-Steuerflugzeug

Amazon Elastic Kubernetes Service (EKS) ist ein verwalteter Kubernetes-Service, der es Ihnen leicht macht, Kubernetes auf AWS auszuführen, ohne Ihre eigene Kubernetes-Steuerungsebene oder Worker Nodes installieren, betreiben und warten zu müssen. Es läuft 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-Steuerungsebenenknoten und ersetzt automatisch fehlerhafte Knoten der Steuerungsebene.

EKS-Architektur

Die EKS-Architektur wurde entwickelt, um alle einzelnen Fehlerquellen zu eliminieren, die die Verfügbarkeit und Haltbarkeit der Kubernetes-Steuerungsebene beeinträchtigen könnten.

Die von EKS verwaltete Kubernetes-Steuerungsebene läuft in einer von EKS verwalteten VPC. Die EKS-Steuerungsebene umfasst die Kubernetes-API-Serverknoten usw., den Cluster. Kubernetes-API-Serverknoten, auf denen Komponenten wie der API-Server und der Scheduler ausgeführt werden und kube-controller-manager die in einer Gruppe mit automatischer Skalierung ausgeführt werden. EKS betreibt mindestens zwei API-Serverknoten in unterschiedlichen Availability Zones (AZs) innerhalb einer AWS-Region. Aus Gründen der Haltbarkeit werden die etcd-Serverknoten ebenfalls in einer Gruppe mit automatischer Skalierung ausgeführt, die sich über drei AZs erstreckt. 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 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html ENI-s in verschiedenen AZs bereit, um die Kommunikation mit Ihren Worker-Knoten zu erleichtern.

Netzwerkkonnektivität auf EKS-Datenebene

Sie können konfigurieren, ob der API-Server Ihres Kubernetes-Clusters über das öffentliche Internet (über den öffentlichen Endpunkt) oder über Ihre VPC (über die EKS-managed ENIs) oder beides erreichbar ist.

Unabhängig davon, ob Benutzer und Worker-Knoten über den öffentlichen Endpunkt oder die EKS-managed ENI eine Verbindung zum API-Server herstellen, gibt es redundante Verbindungswege.

Empfehlungen

Lesen Sie die folgenden Empfehlungen.

Überwachen Sie die Kennzahlen der Steuerungse

Durch die Überwachung der Kubernetes-API-Metriken können Sie Einblicke in die Leistung der Steuerungsebene erhalten und Probleme identifizieren. Eine fehlerhafte Steuerungsebene kann die Verfügbarkeit der im Cluster ausgeführten Workloads beeinträchtigen. Beispielsweise können schlecht geschriebene Controller die API-Server überlasten und die Verfügbarkeit Ihrer Anwendung beeinträchtigen.

Kubernetes macht Metriken der Steuerungsebene am Endpunkt verfügbar. /metrics

Sie können die bereitgestellten Metriken mithilfe von: kubectl

kubectl get --raw /metrics

Diese Metriken werden in einem Prometheus-Textformat dargestellt.

Sie können Prometheus verwenden, um diese Metriken zu sammeln und zu speichern. Im Mai 2020 wurde die Unterstützung für die Überwachung von Prometheus-Metriken in Container Insights CloudWatch hinzugefügt. CloudWatch Sie können Amazon also auch CloudWatch zur Überwachung der EKS-Steuerebene verwenden. Sie können das Tutorial zum Hinzufügen eines neuen Prometheus Scrape Targets: Prometheus KPI Server Metrics verwenden, um Metriken zu sammeln und ein CloudWatch Dashboard zur Überwachung der Steuerungsebene Ihres Clusters zu erstellen.

Die Kubernetes-API-Servermetriken finden Sie hier. https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go apiserver_request_duration_secondsKann beispielsweise angeben, wie lange die Ausführung von API-Anfragen dauert.

Erwägen Sie, diese Metriken der Steuerungsebene zu überwachen:

API-Server

usw

Erwägen Sie, das Kubernetes Monitoring Overview Dashboard zu verwenden, um Kubernetes-API-Serveranfragen sowie Latenz- und etcd-Latenzmetriken zu visualisieren und zu überwachen.

Cluster-Authentifizierung

EKS unterstützt derzeit zwei Arten der Authentifizierung: bearer/service Konto-Tokens und IAM-Authentifizierung, bei der die Webhook-Token-Authentifizierung verwendet wird. Wenn Benutzer die Kubernetes-API aufrufen, übergibt ein Webhook ein in der Anfrage enthaltenes Authentifizierungstoken an IAM. Das Token, eine signierte Basis-64-URL, wird von der AWS-Befehlszeilenschnittstelle (AWS 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-Konfigurationskarte bearbeiten.

Wenn Sie die aws-auth Configmap falsch konfigurieren und den Zugriff auf den Cluster verlieren, können Sie weiterhin den Benutzer oder die Rolle des Cluster-Erstellers 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-Dienstkontos 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 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}'`

Holen Sie sich das dem Geheimnis zugeordnete Token:

TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode`

Fügen Sie das Dienstkonto und das Token hinzu zukubeconfig:

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:<REDACTED>
    server: https://<CLUSTER>.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
    user: super-admin
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
current-context: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
#  user:
#    exec:
#      apiVersion: client.authentication.k8s.io/v1beta1
#      args:
#      - --region
#      - us-west-2
#      - eks
#      - get-token
#      - --cluster-name
#      - <<cluster name>>
#      command: aws
#      env: null
- name: super-admin
  user:
    token: <<super-admin sa's secret>>

Webhooks zur Zulassung

In Kubernetes gibt es zwei Arten von Zulassungswebhooks: Webhooks für die Validierung von Zulassungen und mutierende Webhooks für Zulassungen. Diese ermöglichen es einem Benutzer, die Kubernetes-API zu erweitern und Objekte zu validieren oder zu ändern, bevor sie von der API akzeptiert werden. Schlechte Konfigurationen dieser Webhooks können die EKS-Steuerungsebene destabilisieren, indem sie clusterkritische Operationen blockieren.

Um Cluster-kritische Operationen nicht zu beeinträchtigen, vermeiden Sie entweder das Setzen von „Catch-All-Webhooks“ wie den folgenden:

- name: "pod-policy.example.com"
  rules:
  - apiGroups:   ["*"]
    apiVersions: ["*"]
    operations:  ["*"]
    resources:   ["*"]
    scope: "*"

Oder stellen Sie sicher, dass für den Webhook eine Fail-Open-Richtlinie mit einem Timeout von weniger als 30 Sekunden gilt, um sicherzustellen, dass Cluster-kritische Workloads nicht beeinträchtigt werden, wenn Ihr Webhook nicht verfügbar ist.

Blockieren Sie Pods mit unsicheren Sysctls

Sysctlist ein Linux-Hilfsprogramm, das es Benutzern ermöglicht, Kernelparameter während der Laufzeit zu ändern. Diese Kernelparameter steuern verschiedene Aspekte des Verhaltens des Betriebssystems, wie Netzwerk, Dateisystem, virtueller Speicher und Prozessmanagement.

Kubernetes ermöglicht das Zuweisen von sysctl Profilen für Pods. Kubernetes wird als sicher und unsicher eingestuftsystcls. Safe sysctls haben einen Namespace im Container oder Pod, 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 unsafe standardmäßig deaktiviert sysctls sind, erstellt das Kubelet keinen Pod mit einem unsicheren Profil. sysctl Wenn Sie einen solchen Pod erstellen, weist der Scheduler diese Pods wiederholt Knoten zu, während der Knoten ihn nicht starten kann. Diese Endlosschleife belastet letztendlich die Cluster-Steuerungsebene und macht den Cluster instabil.

Erwägen Sie, OPA Gatekeeper oder Kyverno zu verwenden, um Pods mit unsicher abzulehnen. 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 veröffentlicht. Ab Kubernetes 1.19 wird jede Nebenversion nach ihrer ersten Veröffentlichung etwa zwölf Monate lang unterstützt. Mit der Einführung 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-Endpunkt-Konnektivität

Bei der Arbeit mit Amazon EKS (Elastic Kubernetes Service) kann es bei Ereignissen wie der Skalierung oder dem Patchen der Kubernetes-Kontrollebene zu Verbindungszeitüberschreitungen oder Fehlern kommen. Diese Ereignisse können dazu führen, dass die Kube-Apiserver-Instances 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 beschrieben, um eine zuverlässige Konnektivität aufrechtzuerhalten.

Das Hauptproblem ist das clientseitige DNS-Caching und das Potenzial für veraltete IP-Adressen des EKS-Endpunkts — öffentliche NLB für öffentliche Endpunkte oder für private Endpunkte. X-ENI Wenn die Kube-Apiserver-Instanzen ersetzt werden, kann der Fully Qualified Domain Name (FQDN) in neue IP-Adressen aufgelöst werden. Aufgrund der TTL-Einstellungen (DNS Time to Live), die in der von AWS verwalteten Route 53-Zone auf 60 Sekunden festgelegt sind, können Kunden 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 Best Practices implementieren:

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 Fehlerbedingungen, um sicherzustellen, dass sie sich bei tatsächlichen Skalierungs- oder Patching-Ereignissen wie erwartet verhalten.

Ausführung großer Cluster

EKS überwacht aktiv die Belastung der Instanzen der Steuerungsebene und skaliert sie automatisch, um eine hohe Leistung sicherzustellen. Sie sollten jedoch potenzielle Leistungsprobleme und Beschränkungen innerhalb von Kubernetes sowie Kontingente in AWS-Services berücksichtigen, wenn Sie große Cluster ausführen.

Zusätzliche Ressourcen: