View a markdown version of this page

Bereiten Sie lokale Amazon EKS-Cluster vor auf AWS Outposts, die mit EC2-Instance-Speicher für Netzwerkunterbrechungen konfiguriert sind - Amazon EKS
Authentifizierung bei Netzwerkunterbrechungenetcd: Verhalten bei VerbindungsabbrüchenProtokollierung auf der Steuerungsebene bei VerbindungsabbrüchenLokale BeobachtbarkeitLokales Bild-RepositoryOptimieren Sie das Kubernetes-Pod-Failover-VerhaltenSimulieren Sie eine 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 unter, 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 vor auf AWS Outposts, die mit EC2-Instance-Speicher für Netzwerkunterbrechungen konfiguriert sind

Wenn der AWS Outposts-Servicelink, der Ihr lokales Netzwerk mit der AWS Cloud verbindet, die Konnektivität verloren hat, können Sie Ihren lokalen Amazon EKS-Cluster weiterhin auf einem Outpost verwenden. In diesem Thema werden die Vorbereitung Ihres lokalen Clusters auf Netzwerkunterbrechungen und die damit verbundenen Überlegungen behandelt.

  • 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 findest du in der Checkliste zur Fehlerbehebung AWS im Outposts-Rack-Netzwerk im AWS Outposts-Benutzerhandbuch.

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

Authentifizierung bei Netzwerkunterbrechungen

Lokale Cluster unterstützen mehrere Authentifizierungsmechanismen. Ihre Verfügbarkeit bei Netzwerkunterbrechungen ist unterschiedlich:

Authentifizierungsmechanismus Verfügbar bei Verbindungsabbrüchen?

AWS IAM (auf Einträge zugreifen), aws-auth ConfigMap

Nein. IAM erfordert Konnektivität mit der AWS Region.

OIDC (vom Kunden bereitgestellter Anbieter)

Hängt vom Standort des Anbieters ab. Wenn der OIDC-Anbieter vom lokalen Netzwerk des Outposts aus erreichbar ist, funktioniert die Authentifizierung weiterhin.

x.509-Client-Zertifikate

Ja. Zertifikate werden lokal vom Kubernetes-API-Server validiert.

IRSA (IAM-Rollen für Dienstkonten)

Nein. Siehst duIRSA und Pod Identity bei Verbindungsabbrüchen.

EKS Pod Identity

Nein. Siehst duIRSA und Pod Identity bei Verbindungsabbrüchen.

x.509-Client-Zertifikate

Um den kubectl Zugriff auch bei Netzwerkunterbrechungen aufrechtzuerhalten, erstellen Sie ein x.509-Client-Zertifikat, bevor die Verbindung getrennt wird.

Um ein Admin-Zertifikat zu erstellen:

  1. Generieren Sie einen privaten Schlüssel und eine Zertifikatsignieranforderung (CSR):

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

  2. Erstellen Sie eine CertificateSigningRequest Kubernetes-Ressource und genehmigen Sie sie:

    cat admin.csr | base64 | tr -d '\n' > admin.csr.b64
    apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: admin-csr
spec:
  request: <base64-encoded-csr>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
    - client auth
    kubectl apply -f admin-csr.yaml
kubectl certificate approve admin-csr

  3. Rufen Sie das signierte Zertifikat ab:

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

  4. Erstellen Sie eineClusterRoleBinding, um Administratorzugriff zu gewähren:

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

  5. Erstellen Sie einekubeconfig, die das Zertifikat verwendet:

    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

DNS-Auflösung des Cluster-Endpunkts bei Verbindungsabbrüchen

Der Kubernetes-API-Serverendpunkt für einen lokalen Cluster wird in Amazon Route 53 gehostet und in die privaten IP-Adressen der kontoübergreifenden Elastic Network Interfaces (ENIs) aufgelöst, die Amazon EKS in Ihren Subnetzen erstellt. Diese ENIs haben statische private IP-Adressen, die sich während des normalen Clusterbetriebs nicht ändern.

Während einer Netzwerkunterbrechung kann der Outpost Route 53 nicht erreichen, sodass der Hostname des Cluster-Endpunkts nur aufgelöst wird, wenn Sie einen lokalen Auflösungspfad vorbereitet haben. Drei Kategorien von Clients müssen den API-Server erreichen:

  • Cluster-Administratoren laufenkubectl.

  • Worker Nodes (kubelet) senden Node-Heartbeats und rufen Spezifikationen ab.

  • kube-proxyauf jedem Knoten, wodurch Cluster-Dienst-IPs eingerichtet werden.

Option 1: lokale DNS-Lösung (empfohlen)

AWS empfiehlt die Bereitstellung einer lokalen DNS-Lösung, die die Cluster-Endpunktdatensätze zwischenspeichert und sie bereitstellt, während der Outpost getrennt ist. Sie können Ihren eigenen DNS-Server in Ihrer lokalen Umgebung ausführen, der die Cluster-Endpunkteinträge zwischenspeichert.

Wenn Sie eine lokale DNS-Lösung verwenden, empfehlen wir, Ihre AMIs kubeconfig und Ihre Worker-Node-AMIs auf den Hostnamen des Cluster-Endpunkts zu richten (nicht auf ENI-IP-Adressen), damit die Auflösung mit der lokalen DNS-Lösung übereinstimmt.

Option 2: statischer Zugriff IP-based

Wenn Sie keine lokale DNS-Lösung ausführen möchten, können Sie den statischen IP-based Zugriff verwenden.

  • Administratoren: Konfigurieren Sie Ihre sokubeconfig, dass sie direkt auf eine kontoübergreifende private ENI-IP-Adresse verweist. Finden Sie die ENIs, indem Sie Amazon EKS cluster-name in Ihrem AWS Konto nach Netzwerkschnittstellen mit der Beschreibung suchen. Die IP-Adresse jedes ENI ist während der gesamten Lebensdauer des Clusters bei normalem Betrieb stabil.

  • Worker-Nodes (Amazon EKS-optimierte AMIs): Wenn Sie Worker-Knoten von einem Amazon EKS-optimierten AMI aus starten, fügt das Bootstrap-Skript den Cluster-Endpunkt /etc/hosts mit den ENI-IP-Adressen hinzu. Es ist keine zusätzliche Konfiguration erforderlich.

  • Worker Nodes (benutzerdefinierte AMIs): Fügen Sie den Hostnamen und die ENI-IP-Adressen des Cluster-Endpunkts zu /etc/hosts Ihrem benutzerdefinierten Bootstrap hinzu. Andernfalls kubelet und kube-proxy kann den API-Server während einer Verbindungsunterbrechung nicht erreichen.

Wichtig

Wenn eine kontoübergreifende ENI gelöscht wird oder sich ihre IP-Adresse ändert — zum Beispiel, wenn Sie sie löschen oder so ändern, dass Amazon EKS sie nicht erneut anhängen kann — müssen jeder Knoten und jeder Administrator, der statischen IP-based Zugriff verwendet, manuell aktualisiert werden. Bei einer lokalen DNS-Lösung ist kein manuelles Eingreifen erforderlich.

Pod-DNS-Auflösung bei Verbindungsabbrüchen

Um DNS-Fehler bei unterbrochenem Betrieb zu vermeiden, konfigurieren Sie die Startvorlage für den Worker-Knoten so, dass die Einstellung außer Kraft gesetzt kubelet’s `resolvConf wird. Erstellen Sie in Ihren Benutzerdaten eine benutzerdefinierte resolv.conf Datei (z. B./etc/kubernetes/resolv.conf), die nur nameserver 10.0.0.2 (ohne die VPC-Suchdomain) enthält, und geben Sie spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf dann Ihre ein. NodeConfig Dadurch wird die region-code.compute.internal Suchdomain aus der Pod-DNS-Konfiguration entfernt und verhindert, dass Anfragen an den nicht erreichbaren VPC-DNS-Resolver weitergeleitet werden, während die Verbindung getrennt ist.

Das folgende Beispiel zeigt die Benutzerdaten des Worker-Knotens:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"

--BOUNDARY
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
mkdir -p /etc/kubernetes
echo "nameserver 10.0.0.2" > /etc/kubernetes/resolv.conf

--BOUNDARY
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    name: my-cluster
    ...
  kubelet:
    config:
      resolvConf: /etc/kubernetes/resolv.conf

--BOUNDARY--

IRSA und Pod Identity bei Verbindungsabbrüchen

Wichtig

IRSA und EKS Pod Identity hängen von AWS STS ab, das in der Region läuft. AWS Während einer Netzwerktrennung können Workloads, die IRSA oder Pod Identity verwenden, keine neuen Anmeldeinformationen abrufen. Bestehende Anmeldeinformationen laufen nach einer gewissen Zeit ab.

Es wird nicht empfohlen, funktionale oder betriebliche Abhängigkeiten von Region-based AWS Diensten für Workloads einzugehen, die auch bei Netzwerkunterbrechungen verfügbar bleiben müssen.

etcd: Verhalten bei Verbindungsabbrüchen

Bei Netzwerkunterbrechungen können etcd Snapshots nicht gesichert werden. Wenn während einer Trennung mehr als eine etcd Instanz nicht verfügbar ist, etcd verliert das Quorum und die Kubernetes-API-Operationen sind erst verfügbar, wenn Ihr Outpost erneut eine Verbindung herstellt und das Quorum wiederhergestellt wurde. etcd Workloads, die bereits ausgeführt werden, werden weiterhin ausgeführt.

Protokollierung auf der Steuerungsebene bei Verbindungsabbrüchen

Bei Netzwerkunterbrechungen werden die Protokolle der Steuerungsebene lokal auf den Instanzen der Kontrollebene zwischengespeichert. Wenn die Konnektivität wiederhergestellt ist, werden die Protokolle an Amazon CloudWatch Logs in der übergeordneten AWS Region gesendet. Sie müssen keinen Logging-Agenten auf der Steuerungsebene installieren oder warten.

Lokale Beobachtbarkeit

Sie können Ihren Cluster bei Verbindungsabbrüchen lokal überwachen, indem Sie Prometheus, Grafana oder andere Drittanbieterlösungen verwenden, um den Messendpunkt des Kubernetes-API-Servers zu durchsuchen.

Lokales Bild-Repository

Um Bereitstellungen mit zusätzlichen Replikaten zu skalieren oder nach Pod-Ausfällen bei Verbindungsunterbrechungen eine Wiederherstellung durchzuführen, benötigen Sie ein lokales Container-Image-Repository (z. B. eine Docker-Registry), oder die Images müssen vor dem Trennen auf dem Knoten zwischengespeichert werden. Amazon ECR ist bei Netzwerkunterbrechungen nicht verfügbar.

Optimieren Sie das Kubernetes-Pod-Failover-Verhalten

Während einer Netzwerkunterbrechung kann die Kubernetes-Steuerungsebene nicht mit der Region kommunizieren. AWS Wenn ein Knoten nicht mehr erreichbar ist, besteht das Standardverhalten von Kubernetes darin, Pods nach einer Timeout-Periode zu löschen. Sie können dieses Verhalten mithilfe von Toleranzen und tolerationSeconds anhand Ihrer Pod-Spezifikationen anpassen, um zu steuern, wie schnell Pods während der Partitionen neu geplant werden. Eine ausführliche Anleitung 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 [Das Kubernetes-Pod-Failover-Verhalten optimieren] im _Amazon EKS-Handbuch mit den Best Practices.

Simulieren Sie eine Netzwerkunterbrechung

Bevor Sie mit Ihrem lokalen Cluster in die Produktion gehen, simulieren Sie eine Trennung, um sicherzustellen, dass Sie auf Ihren Cluster zugreifen können, wenn er getrennt ist.

  1. Wenden Sie Firewallregeln auf die Netzwerkgeräte an, die Ihren Outpost mit der AWS Region verbinden. Dadurch wird der Service-Link des Outposts getrennt.

  2. Testen Sie die Verbindung zu Ihrem lokalen Cluster mit dem von Ihnen erstellten x.509-Zertifikat:

    kubectl --kubeconfig admin.kubeconfig get nodes
Anmerkung

Wenn Sie Dienste auf Ihrem Outpost bereits in der Produktion haben, simulieren Sie keine Unterbrechung. Das Trennen der Serviceverbindung wirkt sich auf alle Dienste aus, die auf dem Outpost laufen.