View a markdown version of this page

Bereiten Sie lokale Amazon EKS-Cluster auf AWS Outposts für Netzwerkunterbrechungen vor - Amazon EKS
Optimieren Sie das Failover-Verhalten von Kubernetes-PodsAuthentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung

Unterstützung für die Verbesserung dieser Seite beitragen

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.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

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.

Bereiten Sie lokale Amazon EKS-Cluster auf AWS Outposts für Netzwerkunterbrechungen vor

Wenn Ihr lokales Netzwerk die Konnektivität mit der AWS Cloud verloren hat, können Sie Ihren lokalen Amazon EKS-Cluster weiterhin auf einem Outpost verwenden. In diesem Thema wird beschrieben, wie Sie Ihren lokalen Cluster auf Netzwerkunterbrechungen vorbereiten können, und verwandte Überlegungen.

  • Lokale Cluster sorgen für Stabilität und unterbrechungsfreien Betrieb bei vorübergehenden, ungeplanten Netzwerkunterbrechungen. AWS Outposts bleibt ein vollständig vernetztes Angebot, das als Erweiterung der AWS Cloud in Ihrem Rechenzentrum fungiert. Im Falle von Netzwerkunterbrechungen zwischen Ihrem Outpost und der AWS Cloud empfehlen wir, zu versuchen, Ihre Verbindung wiederherzustellen. Eine Anleitung finden Sie in der Checkliste zur Fehlerbehebung im AWS Outposts-Rack-Netzwerk im AWS Outposts-Benutzerhandbuch. Weitere Informationen zum Beheben von Problemen mit lokalen Clustern finden Sie unter Fehlerbehebung bei lokalen Amazon EKS-Clustern auf AWS Outposts.

  • Outposts geben eine ConnectedStatus-Metrik aus, mit der Sie den Konnektivitätsstatus Ihres Outposts überwachen können. Weitere Informationen finden Sie unter Outposts-Metriken im AWS Outposts-Benutzerhandbuch.

  • Lokale Cluster verwenden IAM als standardmäßigen Authentifizierungsmechanismus mit dem AWS Authenticator Identity and Access Management für Kubernetes. IAM ist während Netzwerkunterbrechungen nicht verfügbar. Daher unterstützen lokale Cluster einen alternativen Authentifizierungsmechanismus mithilfe von x.509-Zertifikaten, die Sie verwenden können, um eine Verbindung zu Ihrem Cluster herzustellen, wenn die Netzwerkverbindung unterbrochen ist. Informationen zum Abrufen und Verwenden eines x.509-Zertifikats für Ihren Cluster finden Sie unter Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung.

  • Wenn Sie bei Netzwerkunterbrechungen nicht auf Route 53 zugreifen können, sollten Sie lokale DNS-Server in Ihrer On-Premises-Umgebung verwenden. Die Kubernetes-Instances der Steuerebene verwenden statische IP-Adressen. Sie können die Hosts, die Sie für die Verbindung mit Ihrem Cluster verwenden, mit dem Hostnamen und den IP-Adressen des Endpunkts als Alternative zur Verwendung lokaler DNS-Server konfigurieren. Weitere Informationen finden Sie unter DNS im AWS Outposts-Benutzerhandbuch.

  • Wenn Sie bei Netzwerkunterbrechungen mit einem Anstieg des Anwendungsdatenverkehrs rechnen, können Sie in Ihrem Cluster bei Verbindung mit der Cloud freie Rechenkapazität bereitstellen. Amazon EC2 EC2-Instances sind im Preis von AWS Outposts enthalten. Das Ausführen von Spare-Instances wirkt sich also nicht auf Ihre AWS Nutzungskosten aus.

  • Während Netzwerkunterbrechungen, die das Erstellen, Aktualisieren und Skalieren von Workloads ermöglichen, müssen die Container-Images Ihrer Anwendung über das lokale Netzwerk zugänglich sein und Ihr Cluster muss über genügend Kapazität verfügen. Lokale Cluster hosten keine Container-Registry für Sie. Wenn die Pods zuvor auf diesen Knoten ausgeführt wurden, werden Container-Images auf den Knoten zwischengespeichert. Wenn Sie die Container-Images Ihrer Anwendung in der Regel aus Amazon ECR in der Cloud beziehen, sollten Sie erwägen, einen lokalen Cache oder eine lokale Registry auszuführen. Ein lokaler Cache oder eine lokale Registry ist hilfreich, wenn Sie während einer Netzwerkunterbrechung Workload-Ressourcen erstellen, aktualisieren und skalieren müssen.

  • Lokale Cluster verwenden Amazon EBS als Standardspeicherklasse für persistente Volumes und den Amazon-EBS-CSI-Treiber, um den Lebenszyklus persistenter Amazon-EBS-Volumes zu verwalten. Während Netzwerkunterbrechungen können Pods, die von Amazon EBS gesichert werden, nicht erstellt, aktualisiert oder skaliert werden. Dies liegt daran, dass diese Vorgänge Aufrufe an die Amazon-EBS-API in der Cloud erfordern. Wenn Sie statusbehaftete Workloads auf lokalen Clustern bereitstellen und während Netzwerktrennungen Vorgänge zum Erstellen, Aktualisieren oder Skalieren benötigen, sollten Sie die Verwendung eines alternativen Speichermechanismus in Betracht ziehen.

  • Amazon EBS-Snapshots können nicht erstellt oder gelöscht werden, wenn AWS Outposts nicht auf die entsprechenden APIs in der AWS Region zugreifen können (z. B. die APIs für Amazon EBS oder Amazon S3).

  • Bei der Integration von ALB (Ingress) mit AWS Certificate Manager (ACM) werden Zertifikate übertragen und im Speicher der AWS Outposts ALB Compute-Instanz gespeichert. Die aktuelle TLS-Terminierung funktioniert weiterhin, falls die Verbindung zur Region getrennt wird. AWS Mutationsvorgänge in diesem Kontext schlagen fehl (z. B. neue Eingangsdefinitionen, neue API-Vorgänge für ACM-basierte Zertifikate, ALB-Rechenskalierung oder Zertifikatsrotation). Weitere Informationen finden Sie unter Problembehandlung bei der verwalteten Zertifikatserneuerung im AWS Certificate Manager Manager-Benutzerhandbuch.

  • Die Protokolle der Amazon-EKS-Steuerebene werden während Netzwerkunterbrechungen lokal auf Kubernetes-Instances der Steuerebene zwischengespeichert. Nach dem erneuten Herstellen der Verbindung werden die Protokolle an die CloudWatch Protokolle in der übergeordneten AWS Region gesendet. Sie können Prometheus-, Grafana- oder Amazon-EKS-Partnerlösungen verwenden, um den Cluster lokal mithilfe des Metrik-Endpunkts des Kubernetes-API-Servers oder mithilfe von Fluent Bit für Protokolle zu überwachen.

  • Wenn Sie den Load AWS Balancer Controller auf Outposts für Anwendungsdatenverkehr verwenden, empfangen bestehende Pods, denen der Load AWS Balancer Controller vorangestellt ist, auch während Netzwerkunterbrechungen weiterhin Datenverkehr. Neue Pods, die bei Netzwerkunterbrechungen erstellt werden, empfangen erst dann Traffic, wenn der Outpost wieder mit der Cloud verbunden ist. AWS Erwägen Sie, die Anzahl der Replikate für Ihre Anwendungen festzulegen, während Sie mit der AWS Cloud verbunden sind, um Ihren Skalierungsanforderungen bei Netzwerkunterbrechungen gerecht zu werden.

  • Das Amazon-VPC-CNI-Plugin für Kubernetes ist standardmäßig auf den sekundären IP-Modus eingestellt. Es ist mit WARM_ENI_TARGET = 1 konfiguriert, wodurch das Plugin „eine vollständige elastische Netzwerkschnittstelle“ mit verfügbaren IP-Adressen bereithalten kann. Erwägen Sie, WARM_ENI_TARGET-, WARM_IP_TARGET- und MINIMUM_IP_TARGET-Werte entsprechend Ihren Skalierungsanforderungen während eines getrennten Zustands zu ändern. Weitere Informationen finden Sie in der Readme-Datei für das Plugin unter. GitHub Eine Liste der maximalen Anzahl von Pods, die von den einzelnen Instance-Typen unterstützt werden, finden Sie in der Datei eni-max-pods.txt unter GitHub.

Optimieren Sie das Failover-Verhalten von Kubernetes-Pods

Bei Netzwerkunterbrechungen markiert der Kubernetes Node Lifecycle Controller unerreichbare Knoten mit dem Makel mit Wirkung. node.kubernetes.io/unreachable NoExecute Standardmäßig werden Pods ohne eine entsprechende Toleranz nach 300 Sekunden (5 Minuten) entfernt. Sie können dieses Verhalten anpassen DaemonSets, indem Sie Anwendungs-Pods konfigurieren tolerationSeconds oder einen benutzerdefinierten Controller implementieren, sodass Pods auch bei vorübergehenden Verbindungsabbrüchen auf ihren Knoten verbleiben können, ohne dass sie unnötig entfernt werden. Ausführliche Anleitungen und Beispiele finden Sie unter https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html # tune_kubernetes_pod_failover_behavior [Tune Kubernetes Pod Failover Behavior] im _Amazon EKS Best Practices Guide.

Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung

AWS Identity and Access Management (IAM) ist bei Netzwerkunterbrechungen nicht verfügbar. Sie können sich nicht bei Ihrem lokalen Cluster mit IAM-Anmeldeinformationen authentifizieren, während keine Verbindung besteht. Sie können jedoch über Ihr lokales Netzwerk mithilfe von x509-Zertifikaten eine Verbindung zu Ihrem Cluster herstellen, wenn die Verbindung getrennt ist. Sie müssen ein Client X509-Zertifikat herunterladen und speichern, das Sie während der Verbindungstrennung verwenden können. In diesem Thema erfahren Sie, wie Sie das Zertifikat erstellen und verwenden, um sich bei Ihrem Cluster zu authentifizieren, wenn dieser sich in einem nicht verbundenen Status befindet.

  1. Erstellen einer Zertifikatssignierungsanforderung

    1. Generieren einer Zertifikatssignierungsanforderung.

      openssl req -new -newkey rsa:4096 -nodes -days 365 \
    -keyout admin.key -out admin.csr -subj "/CN=admin"

    2. Erstellen Sie eine Anfrage zur Zertifikatssignierung in Kubernetes.

      BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: admin-csr
spec:
  signerName: kubernetes.io/kube-apiserver-client
  request: ${BASE64_CSR}
  usages:
  - client auth
EOF

  2. Erstellen einer Zertifikatssignierungsanforderung mit kubectl.

    kubectl create -f admin-csr.yaml

  3. Überprüfen Sie den Status der Zertifikatssignierungsanforderung.

    kubectl get csr admin-csr

    Eine Beispielausgabe sieht wie folgt aus.

    NAME       AGE   REQUESTOR                       CONDITION
admin-csr  11m   kubernetes-admin                Pending

    Kubernetes hat die Anfrage zur Zertifikatsignierung erstellt.

  4. Genehmigen Sie die Zertifikatssignieranforderung.

    kubectl certificate approve admin-csr

  5. Überprüfen Sie erneut den Status der Anfrage zum Signieren des Zertifikats auf Genehmigung.

    kubectl get csr admin-csr

    Eine Beispielausgabe sieht wie folgt aus.

    NAME       AGE   REQUESTOR                     CONDITION
admin-csr  11m   kubernetes-admin              Approved

  6. Rufen Sie das Zertifikat ab und überprüfen Sie es.

    1. Rufen Sie das Zertifikat ab.

      kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt

    2. Überprüfen Sie das Zertifikat.

      cat admin.crt

  7. Erstellen Sie eine Cluster-Rollenbindung für einen admin-Benutzer.

    kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
    --user=admin --group=system:masters

  8. Generieren Sie eine kubeconfig mit Benutzerbereich für einen getrennten Status.

    Sie können eine kubeconfig-Datei mit den heruntergeladenen admin-Zertifikaten generieren. Ersetzen Sie my-cluster und apiserver-endpoint in den folgenden Befehlen.

    aws eks describe-cluster --name my-cluster \
    --query "cluster.certificateAuthority" \
    --output text | base64 --decode > ca.crt
    kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
    --certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
    kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
    --client-certificate=admin.crt --client-key=admin.key --embed-certs
    kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
    --cluster my-cluster --user admin
    kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster

  9. Ziegen Sie Ihre kubeconfig-Datei an.

    kubectl get nodes --kubeconfig admin.kubeconfig

  10. Wenn Sie bereits über Services in Produktion auf Ihrem Outpost verfügen, überspringen Sie diesen Schritt. Wenn Amazon EKS der einzige Service ist, der in Ihrem Outpost ausgeführt wird, und der Outpost sich nicht in der Produktion befindet, können Sie eine Netzwerkunterbrechung simulieren. Bevor Sie mit Ihrem lokalen Cluster in Produktion gehen, simulieren Sie einen Verbindungsabbruch, um sicherzustellen, dass Sie auf Ihren Cluster zugreifen können, wenn er sich in einem getrennten Status befindet.

    1. Wenden Sie Firewall-Regeln auf die Netzwerkgeräte an, die Ihren Outpost mit der AWS Region verbinden. Dadurch wird der Service-Link des Outposts getrennt. Sie können keine neuen Instances erstellen. Derzeit laufende Instances verlieren die Konnektivität zur AWS Region und zum Internet.

    2. Sie können die Verbindung zu Ihrem lokalen Cluster testen, während die Verbindung getrennt ist, indem Sie das x509-Zertifikat verwenden. Stellen Sie sicher, dass Sie Ihr kubeconfig in das admin.kubeconfig ändern, das Sie in einem vorherigen Schritt erstellt haben. my-clusterErsetzen Sie es durch den Namen Ihres lokalen Clusters.

      kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig

    Wenn Sie Probleme mit Ihren lokalen Clustern feststellen, während diese sich im getrennten Status befinden, empfehlen wir Ihnen, ein Support-Ticket zu erstellen.