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

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 EKS Amazon-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 EKS Amazon-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 EKS Amazon-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 den AWS Identity and Access Management-Authentifikator für Kubernetes. IAMist 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. Das Tool Kubernetes Instanzen der Kontrollebene verwenden statische IP-Adressen. Als Alternative zur Verwendung lokaler DNS Server können Sie die Hosts, die Sie für die Verbindung mit Ihrem Cluster verwenden, mit dem Hostnamen und den IP-Adressen des Endpunkts konfigurieren. Weitere Informationen finden Sie DNSim 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. EC2Amazon-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 das Symbol Pods wurden zuvor auf diesen Knoten ausgeführt, Container-Images werden auf den Knoten zwischengespeichert. Wenn Sie die Container-Images Ihrer Anwendung normalerweise von Amazon ECR in der Cloud abrufen, sollten Sie erwägen, einen lokalen Cache oder eine lokale Registrierung 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 EBS CSI Amazon-Treiber zur Verwaltung des Lebenszyklus EBS persistenter Amazon-Volumes. Bei Netzwerkunterbrechungen Pods die von Amazon unterstützt werden, EBS können nicht erstellt, aktualisiert oder skaliert werden. Dies liegt daran, dass für diese Operationen Aufrufe an Amazon EBS API in der Cloud erforderlich sind. Wenn Sie statusbehaftete Workloads auf lokalen Clustern bereitstellen und bei Netzwerkunterbrechungen Vorgänge zum Erstellen, Aktualisieren oder Skalieren benötigen, sollten Sie die Verwendung eines alternativen Speichermechanismus in Betracht ziehen.

  • EBSAmazon-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 Kündigung gilt auch für den Fall, dass die Verbindung zur Region getrennt wird. AWS Mutationsvorgänge in diesem Kontext schlagen fehl (z. B. neue Eingangsdefinitionen, neue ACM basierte API Zertifikatsoperationen, ALB Rechenskalierung oder Zertifikatsrotation). Weitere Informationen finden Sie unter Problembehandlung bei der verwalteten Zertifikatserneuerung im AWS Certificate Manager Manager-Benutzerhandbuch.

  • Die Protokolle der EKS Amazon-Kontrollebene werden lokal auf dem zwischengespeichert Kubernetes Instanzen der Kontrollebene bei Netzwerkunterbrechungen. Nach der Wiederverbindung werden die Protokolle an die CloudWatch Protokolle in der übergeordneten AWS Region gesendet. Sie können Prometheus -, Grafana - oder EKS Amazon-Partnerlösungen verwenden, um den Cluster lokal zu überwachen, indem Sie Kubernetes APIEndpunkt der Server-Metriken oder mithilfe Fluent Bit für Protokolle.

  • Wenn du das verwendest AWS Load Balancer Controller auf Outposts für Anwendungsdatenverkehr, vorhanden Pods vorangestellt von AWS Load Balancer Controller empfängt auch bei Netzwerkunterbrechungen weiterhin Datenverkehr. Neu Pods Daten, die während Netzwerkunterbrechungen erstellt wurden, 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 Tool Amazon VPC CNI plugin for Kubernetes ist standardmäßig auf den sekundären IP-Modus eingestellt. 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 das von jedem Instance-Typ unterstützt wird, 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, während 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 Zertifikatsignieranforderung 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 Zertifikatsignieranforderung 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 my-cluster and 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 der einzige Dienst EKS ist, der auf Ihrem Outpost läuft und der Outpost derzeit nicht in Produktion 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. Ersetzen my-cluster mit dem 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.