Überlegungen zu Clustern im kombinierten Modus Cluster im kombinierten Modus konfigurieren

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.

Konfiguration von Webhooks für Hybridknoten

Auf dieser Seite finden Sie detaillierte Überlegungen zum Ausführen von Webhooks mit Hybridknoten. Webhooks werden in Kubernetes-Anwendungen und Open-Source-Projekten wie dem Load AWS Balancer Controller und dem CloudWatch Observability Agent verwendet, um zur Laufzeit Mutations- und Validierungsfunktionen auszuführen.

Routingfähige Pod-Netzwerke

Wenn Sie Ihr lokales Pod-CIDR in Ihrem On-Premises-Netzwerk routingfähig machen können, können Sie Webhooks in Hybridknoten ausführen Es gibt mehrere Techniken, mit denen Sie Ihren On-Premises-Pod CIDR in Ihrem On-Premises-Netzwerk routingfähig machen können, darunter Border Gateway Protocol (BGP), statische Routen oder andere benutzerdefinierte Routing-Lösungen. BGP ist die empfohlene Lösung, da sie skalierbarer und einfacher zu verwalten ist als alternative Lösungen, die eine benutzerdefinierte oder manuelle Routenkonfiguration erfordern. AWS unterstützt die BGP-Funktionen von Cilium und Calico zur Werbung für Pod-CIDRs. Weitere Informationen finden Sie unter CNI für Hybridknoten konfigurieren und. Routingfähige Fern-Pod-CIDRs

Nicht routingfähige Pod-Netzwerke

Wenn Sie Ihr On-Premises-Pod-CIDR in Ihrem On-Premises-Netzwerk nicht routingfähig machen können und Webhooks ausführen müssen, empfehlen wir Ihnen, alle Webhooks auf Cloud-Knoten im selben EKS-Cluster wie Ihre Hybridknoten auszuführen.

Überlegungen zu Clustern im kombinierten Modus

Cluster im gemischten Modus werden als EKS-Cluster definiert, bei denen sowohl Hybridknoten als auch Knoten in der Cloud ausgeführt werden. AWS Beachten Sie bei der Ausführung eines Clusters im kombinierten Modus die folgenden Empfehlungen:

Führen Sie das VPC CNI auf Knoten in AWS Cloud und entweder Cilium oder Calico auf Hybridknoten aus. Cilium und Calico werden nicht unterstützt, AWS wenn sie auf Knoten in der Cloud ausgeführt werden. AWS
Konfigurieren Sie Webhooks so, dass sie auf Knoten in Cloud ausgeführt werden. AWS Lesen SieWebhooks für Add-Ons konfigurieren, wie Sie die Webhooks für AWS und Community-Add-Ons konfigurieren.
Wenn für Ihre Anwendungen Pods erforderlich sind, die auf Knoten in der AWS Cloud ausgeführt werden, um direkt mit Pods zu kommunizieren, die auf Hybridknoten laufen („Ost-West-Kommunikation“), und Sie das VPC-CNI auf Knoten in der AWS Cloud und Cilium oder Calico auf Hybridknoten verwenden, muss Ihr lokales Pod-CIDR in Ihrem lokalen Netzwerk routbar sein.
Führen Sie mindestens ein Replikat von CoreDNS auf Knoten in AWS Cloud und mindestens ein Replikat von CoreDNS auf Hybridknoten aus.
Konfigurieren Sie die Verteilung des Service-Datenverkehrs, um den Service-Datenverkehr lokal in der Zone zu halten, aus der er stammt. Weitere Informationen zur Verteilung des Service-Datenverkehrs finden Sie unter Verteilung des Service-Datenverkehrs konfigurieren.
Wenn Sie AWS Application Load Balancers (ALB) oder Network Load Balancers (NLB) für den Workload-Verkehr verwenden, der auf Hybridknoten läuft, müssen die mit dem ALB oder NLB verwendeten IP-Ziele routbar sein. AWS
Das Metriken-Server-Add-On erfordert eine Verbindung von der EKS-Steuerebene zur IP-Adresse des Metriken-Server-Pods. Wenn Sie das Metriken-Server-Add-On in Hybridknoten ausführen, muss Ihr lokaler Pod-CIDR in Ihrem On-Premises-Netzwerk routingfähig sein.
Um Metriken für Hybridknoten mithilfe von Amazon Managed Service für Prometheus (AMP) verwalteten Kollektoren zu erfassen, muss Ihr On-Premises-Pod-CIDR in Ihrem On-Premises-Netzwerk routingfähig sein. Oder Sie können den AMP Managed Collector für EKS-Control-Plane-Metriken und Ressourcen verwenden, die in der AWS Cloud ausgeführt werden, und das AWS Distro for OpenTelemetry (ADOT) -Add-on, um Metriken für Hybridknoten zu sammeln.

Cluster im kombinierten Modus konfigurieren

Um die mutierenden und validierenden Webhooks anzuzeigen, die auf Ihrem Cluster ausgeführt werden, können Sie den Ressourcentyp Erweiterungen im Ressourcenbereich der EKS-Konsole für Ihren Cluster anzeigen oder die folgenden Befehle verwenden. EKS meldet auch Webhook-Metriken im Cluster-Beobachtbarkeits-Dashboard. Weitere Informationen finden Sie unter Überwachen Ihres Clusters im Dashboard „Beobachtbarkeit“.


kubectl get mutatingwebhookconfigurations


kubectl get validatingwebhookconfigurations

Verteilung des Service-Datenverkehrs konfigurieren

Bei der Ausführung von Clustern im kombinierten Modus empfehlen wir die Verwendung der Verteilung des Service-Datenverkehrs, um den Service-Datenverkehr lokal in der Zone zu halten, aus der er stammt. Die Verteilung des Service-Datenverkehrs (verfügbar für Kubernetes-Versionen 1.31 und höher in EKS) wird gegenüber dem topologiebewussten Routing als Lösung empfohlen, da sie vorhersehbarer ist. Mit der Verteilung des Service-Datenverkehrs erhalten fehlerfreie Endpunkte in der Zone den gesamten Datenverkehr für diese Zone. Bei Topologiebewusstem Routing muss jeder Service mehrere Bedingungen in dieser Zone erfüllen, um das benutzerdefinierte Routing anzuwenden. Andernfalls wird der Datenverkehr gleichmäßig auf alle Endpunkte verteilt.

Wenn Sie Cilium als CNI verwenden, müssen Sie das CNI mit dem Wert enable-service-topology auf true ausführen, um die Verteilung des Service-Datenverkehrs zu aktivieren. Sie können diese Konfiguration mit dem Helm-Installations-Flag --set loadBalancer.serviceTopology=true übergeben oder eine vorhandene Installation mit dem Cilium-CLI-Befehl cilium config set enable-service-topology true aktualisieren. Der auf jedem Knoten ausgeführte Cilium-Agent muss nach der Aktualisierung der Konfiguration für eine vorhandene Installation neu gestartet werden.

Im folgenden Abschnitt wird ein Beispiel für die Konfiguration der Verteilung des Service-Datenverkehrs für den CoreDNS-Service gezeigt. Wir empfehlen, dies für alle Services in Ihrem Cluster zu aktivieren, um unbeabsichtigten Datenverkehr zwischen Umgebungen zu vermeiden.

CoreDNS-Replikate konfigurieren

Wenn Sie einen Cluster im gemischten Modus mit Hybridknoten und Knoten in der AWS Cloud ausführen, empfehlen wir, dass Sie mindestens ein CoreDNS-Replikat auf Hybridknoten und mindestens ein CoreDNS-Replikat auf Ihren Knoten in Cloud haben. AWS Um Latenz- und Netzwerkprobleme in einer Cluster-Konfiguration im kombinierten Modus zu vermeiden, können Sie den CoreDNS-Service so konfigurieren, dass er die nächstgelegene CoreDNS-Replik mit der Verteilung des Service-Datenverkehrs bevorzugt.

Die Verteilung des Service-Datenverkehrs (verfügbar für Kubernetes-Versionen 1.31 und höher in EKS) wird gegenüber dem topologiebewussten Routing als Lösung empfohlen, da sie vorhersehbarer ist. Bei der Verteilung des Service-Datenverkehrs erhalten alle fehlerfreien Endpunkte in der Zone den gesamten Datenverkehr für diese Zone. Beim topologiebewussten Routing muss jeder Service mehrere Bedingungen in dieser Zone erfüllen, um das benutzerdefinierte Routing anzuwenden. Andernfalls wird der Datenverkehr gleichmäßig auf alle Endpunkte verteilt. Die folgenden Schritte konfigurieren die Verteilung des Service-Datenverkehrs.

Fügen Sie für jeden Ihrer Hybridknoten eine Topologie-Zonenbezeichnung hinzu, beispielsweise topology.kubernetes.io/zone: onprem. Alternativ können Sie die Bezeichnung in der nodeadm init-Phase festlegen, indem Sie die Bezeichnung in Ihrer nodeadm-Konfiguration angeben, siehe Knotenkonfiguration zur Anpassung von kubelet (optional). Beachten Sie, dass Knoten, die in der AWS Cloud ausgeführt werden, automatisch mit einer Topologiezonenbezeichnung versehen werden, die der Verfügbarkeitszone (AZ) des Knotens entspricht.
```
kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone
               
```

Fügen Sie podAntiAffinity mit dem Topologie-Zonenschlüssel zur CoreDNS-Bereitstellung hinzu. Alternativ können Sie die CoreDNS-Bereitstellung während der Installation mit EKS-Add-Ons konfigurieren.


kubectl edit deployment coredns -n kube-system


spec:
  template:
    spec:
      affinity:
       ...
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: k8s-app
                  operator: In
                  values:
                  - kube-dns
              topologyKey: kubernetes.io/hostname
            weight: 100
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: k8s-app
                  operator: In
                  values:
                  - kube-dns
              topologyKey: topology.kubernetes.io/zone
            weight: 50
      ...

Fügen Sie die Einstellung trafficDistribution: PreferClose zur Service-Konfiguration kube-dns hinzu, um die Verteilung des Service-Datenverkehrs zu aktivieren.
```
kubectl patch svc kube-dns -n kube-system --type=merge -p '{
  "spec": {
    "trafficDistribution": "PreferClose"
  }
}'
```

Sie können überprüfen, ob die Verteilung des Service-Datenverkehrs aktiviert ist, indem Sie die Endpunkt-Segmente für den kube-dns-Service anzeigen. Ihre Endpunkt-Segmente müssen die hints für Ihre Topologie-Zonenbezeichnungen anzeigen, was bestätigt, dass die Verteilung des Service-Datenverkehrs aktiviert ist. Wenn Sie für jede Endpunktadresse kein hints sehen, ist die Verteilung des Service-Datenverkehrs nicht aktiviert.


kubectl get endpointslice -A | grep "kube-dns"


kubectl get endpointslice kube-dns-<id>  -n kube-system -o yaml


addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
  - <your-hybrid-node-pod-ip>
  hints:
    forZones:
    - name: onprem
  nodeName: <your-hybrid-node-name>
  zone: onprem
- addresses:
  - <your-cloud-node-pod-ip>
  hints:
    forZones:
    - name: us-west-2a
  nodeName: <your-cloud-node-name>
  zone: us-west-2a

Webhooks für Add-Ons konfigurieren

Die folgenden Add-Ons verwenden Webhooks und werden für die Verwendung mit Hybridknoten unterstützt.

AWS Load Balancer Controller
CloudWatch Agent für Beobachtbarkeit
AWS Distribution für OpenTelemetry (ADOT)
cert-manager

In den folgenden Abschnitten finden Sie Informationen zur Konfiguration der Webhooks, die von diesen Add-Ons für die Ausführung auf Knoten in der Cloud verwendet werden. AWS

AWS Load-Balancer-Controller

Um den Load AWS Balancer Controller in einem Cluster-Setup im gemischten Modus zu verwenden, müssen Sie den Controller auf Knoten in AWS Cloud ausführen. Fügen Sie dazu Folgendes zu Ihrer Helm-Wertekonfiguration hinzu oder geben Sie die Werte mithilfe der EKS-Add-On-Konfiguration an.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

CloudWatch Observability Agent

Das CloudWatch Observability Agent-Add-on verfügt über einen Kubernetes-Operator, der Webhooks verwendet. Um den Operator auf Knoten in der AWS Cloud in einem Cluster-Setup im gemischten Modus auszuführen, bearbeiten Sie die CloudWatch Observability Agent-Operatorkonfiguration. Sie können die Operator-Affinität während der Installation mit Helm- und EKS-Add-Ons nicht konfigurieren (siehe Container-Roadmap-Problem Nr. 2431).


kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager


spec:
  ...
  template:
    ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: eks.amazonaws.com/compute-type
                operator: NotIn
                values:
                - hybrid

AWS Distribution für OpenTelemetry (ADOT)

Das AWS Distro for OpenTelemetry (ADOT) -Add-on verfügt über einen Kubernetes-Operator, der Webhooks verwendet. Um den Operator auf Knoten in der AWS Cloud in einem Cluster-Setup im gemischten Modus auszuführen, fügen Sie Ihrer Helm-Wertekonfiguration Folgendes hinzu oder geben Sie die Werte mithilfe der EKS-Add-On-Konfiguration an.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

Wenn Ihr Pod-CIDR in Ihrem On-Premises-Netzwerk nicht routingfähig ist, muss der ADOT-Kollektor in Hybridknoten ausgeführt werden, um die Metriken von Ihren Hybridknoten und den darauf ausgeführten Workloads zu erfassen. Bearbeiten Sie dazu die benutzerdefinierte Ressourcendefinition (CRD).


kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics


spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: In
            values:
            - hybrid

Sie können den ADOT-Kollektor so konfigurieren, dass er nur Metriken von Hybridknoten und den auf Hybridknoten ausgeführten Ressourcen erfasst, indem Sie das folgende relabel_configs zu jedem scrape_configs in der ADOT-Kollektor-CRD-Konfiguration hinzufügen.


relabel_configs:
  - action: keep
    regex: hybrid
    source_labels:
    - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type

cert-managerFür die Installation des ADOT-Add-Ons müssen die TLS-Zertifikate, die vom ADOT-Operator-Webhook verwendet werden, installiert werden. cert-managerführt auch Webhooks aus und Sie können es so konfigurieren, dass es auf Knoten in der AWS Cloud mit der folgenden Helm-Wertekonfiguration ausgeführt wird.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid

`cert-manager`

Das cert-manager Add-on führt Webhooks aus und Sie können es so konfigurieren, dass es auf Knoten in AWS Cloud mit der folgenden Helm-Wertekonfiguration ausgeführt wird.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Add-Ons konfigurieren

Proxy konfigurieren