Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Präferenzen
Kontakt
Feedback
AWS Documentation
AWS-Konto erstellen

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

PDF
RSS
Fokusmodus
Bereiten Sie lokale Amazon EKS-Cluster auf AWS Outposts für Netzwerkunterbrechungen vor - Amazon EKS
Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung

Hilf mit, diese Seite zu verbessern

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.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.

Hilf mit, diese Seite zu verbessern

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.

Wenn Sie zu diesem Benutzerhandbuch beitragen möchten, 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.

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 Standardauthentifizierungsmechanismus mithilfe des AWS Identity and Access Management-Authentifikators für Kubernetes. IAM ist bei 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 die Verwendung lokaler DNS-Server in Ihrer lokalen Umgebung in Betracht ziehen. Die Instanzen der Kubernetes-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. EC2 Amazon-Instances sind im Preis von AWS Outposts enthalten. Das Ausführen von Ersatz-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. Bei Netzwerkunterbrechungen können Pods, die von Amazon EBS unterstützt 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 Netzwerkunterbrechungen Erstellungs-, Aktualisierungs- oder Skalierungsvorgänge 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 entsprechende AWS Region zugreifen können APIs (z. B. 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-Kontrollebene werden bei Netzwerkunterbrechungen lokal auf den Kubernetes-Steuerebenen-Instances zwischengespeichert. Bei der erneuten Verbindung werden die Protokolle an Logs in der übergeordneten Region CloudWatch gesendet. AWS Sie können die Partnerlösungen von Prometheus, Grafana oder Amazon EKS verwenden, um den Cluster lokal mithilfe des Metriken-Endpunkts des Kubernetes-API-Servers oder 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 verwendet standardmäßig den sekundären IP-Modus. Es ist mit WARM_ENI_TARGET = konfiguriert1, was es dem Plugin ermöglicht, „eine vollständige elastic network interface“ mit verfügbaren IP-Adressen verfügbar zu halten. 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 Instanztypen unterstützt werden, finden Sie in der eni-max-pods.txt-Datei unter. GitHub

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 mit IAM-Anmeldeinformationen bei Ihrem lokalen Cluster authentifizieren, wenn die Verbindung unterbrochen ist. 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 getrennt ist.

  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 Anforderung zum Signieren eines Zertifikats 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 Anforderung zum Signieren des Zertifikats 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 Dienst ist, der auf Ihrem Outpost läuft und der Outpost derzeit nicht in Betrieb ist, können Sie eine Netzwerkunterbrechung simulieren. Bevor Sie mit Ihrem lokalen Cluster in die Produktion gehen, simulieren Sie eine Unterbrechung, um sicherzustellen, dass Sie auf Ihren Cluster zugreifen können, wenn er unterbrochen ist.

    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 Instanzen erstellen. Derzeit ausgeführte 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 getrennt sind, empfehlen wir, ein Support-Ticket zu eröffnen.

Auf dieser Seite

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.