Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen - Amazon EKS
Authentifizierung bei Ihrem lokalen Cluster während einer Netzwerkunterbrechung

Unterstützung für die Verbesserung dieser Seite beitragen

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

Vorbereitung lokaler Amazon-EKS-Cluster in AWS Outposts für Netzwerkunterbrechungen

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

  • Lokale Cluster gewährleisten Stabilität und einen unterbrechungsfreien Betrieb bei vorübergehenden, ungeplanten Netzwerkausfällen. AWS Outposts bleibt ein vollständig verbundenes Angebot, das als Erweiterung der AWS Cloud in Ihrem Rechenzentrum fungiert. Im Falle einer Netzwerkunterbrechung zwischen Ihrem Outpost und der AWS Cloud empfehlen wir, die Verbindung wiederherzustellen. Eine Anleitung dazu finden Sie in der Checkliste zur Fehlerbehebung im AWS-Rack-Netzwerk im AWS-Outposts-Benutzerhandbuch. Weitere Informationen zum Beheben von Problemen mit lokalen Clustern finden Sie unter Fehlerbehebung bei lokalen Amazon-EKS-Clustern in 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-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-Instances sind im Preis von AWS Outposts enthalten. Der Betrieb von Ersatz-Instances hat also keinen Einfluss auf Ihre AWS-Nutzungskosten.

  • 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 kein Zugriff auf die relevanten AWS-APIs in der Region (z. B. die APIs für Amazon EBS oder Amazon S3) möglich ist.

  • Bei der Integration von ALB (Ingress) mit AWS Certificate Manager (ACM) werden Zertifikate übertragen und im Speicher der ALB-Rechen-Instance von AWS Outposts gespeichert. Die aktuelle TLS-Terminierung wird im Falle einer Trennung von der AWS-Region weiter betrieben. 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 Erneuerung verwalteter Zertifikate im Benutzerhandbuch zum AWS-Zertifikatsmanager.

  • Die Protokolle der Amazon-EKS-Steuerebene werden während Netzwerkunterbrechungen lokal auf Kubernetes-Instances der Steuerebene zwischengespeichert. Nach der erneuten Verbindung werden die Protokolle an CloudWatch Logs 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 AWS Load Balancer Controller in Outposts für den Anwendungsdatenverkehr verwenden, erhalten vorhandene Pods, denen das AWS Load Balancer Controller vorangestellt ist, während der Netzwerkunterbrechung weiterhin Datenverkehr. Neue Pods, die bei Netzwerkunterbrechungen erstellt wurden, empfangen keinen Datenverkehr, bis der Outpost wieder mit der AWS Cloud verbunden ist. Erwägen Sie, die Replikatanzahl für Ihre Anwendungen festzulegen, während Sie mit der AWS Cloud verbunden sind, um Ihre Skalierungsanforderungen während Netzwerktrennungen zu erfüllen.

  • 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 Datei readme für das Plugin auf GitHub. Eine Liste der maximalen Anzahl von Pods, die von jedem Instance-Typ unterstützt werden, finden Sie in der Datei eni-max-pods.txt auf 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 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. Aktuell 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 Sie my-cluster 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.