**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 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.
# 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 AWS Load Balancer Controller und dem CloudWatch-Beobachtbarkeits-Agenten verwendet, um Mutations- und Validierungsfunktionen zur Laufzeit 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 es skalierbarer und einfacher zu verwalten ist als alternative Lösungen, die eine benutzerdefinierte oder manuelle Routing-Konfiguration erfordern. AWS unterstützt die BGP-Funktionen von Cilium und Calico für die Bekanntmachung für Pod-CIDRs. Weitere Informationen finden Sie unter [CNI für Hybridknoten konfigurieren](hybrid-nodes-cni.md) und [Routingfähige Fern-Pod-CIDRs](hybrid-nodes-concepts-kubernetes.md#hybrid-nodes-concepts-k8s-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 kombinierten Modus* sind EKS-Cluster, die sowohl Hybridknoten als auch Knoten umfassen, die in der AWS Cloud ausgeführt werden. Beachten Sie bei der Ausführung eines Clusters im kombinierten Modus die folgenden Empfehlungen:
+ Führen Sie das VPC CNI auf Knoten in der AWS Cloud und entweder Cilium oder Calico auf Hybridknoten aus. Cilium und Calico werden von AWS nicht unterstützt, wenn sie auf Knoten in der AWS Cloud ausgeführt werden.
+ Konfigurieren Sie Webhooks für die Ausführung auf Knoten in der AWS Cloud. Informationen zur Konfiguration der Webhooks für AWS und Community-Add-Ons finden Sie unter [Webhooks für Add-Ons konfigurieren](#hybrid-nodes-webhooks-add-ons).
+ Wenn Ihre Anwendungen erfordern, dass Pods, die auf Knoten in der AWS Cloud ausgeführt werden, direkt mit Pods kommunizieren, die auf Hybridknoten ausgeführt werden („Ost-West-Kommunikation“), und Sie das VPC CNI auf Knoten in der AWS Cloud und Cilium oder Calico auf Hybridknoten verwenden, muss Ihr On-Premises-Pod-CIDR in Ihrem On-Premises-Netzwerk routingfähig sein.
+ Führen Sie mindestens eine Replik von CoreDNS in Knoten in der AWS Cloud und mindestens eine Replik von CoreDNS in 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](#hybrid-nodes-mixed-service-traffic-distribution).
+ Wenn Sie AWS Application Load Balancer (ALB) oder Network Load Balancer (NLB) für den Workload-Datenverkehr auf Hybridknoten verwenden, müssen die mit ALB oder NLB verwendeten IP-Ziele von AWS aus routingfähig sein
+ 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. Alternativ können Sie den AMP Managed Collector für EKS-Steuerebenen-Metriken und in der AWS Cloud ausgeführte Ressourcen sowie das AWS Distro for OpenTelemetry (ADOT)-Add-On verwenden, um Metriken für Hybridknoten zu erfassen.
## 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“](observability-dashboard.md).
```
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 [https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution), 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](https://kubernetes.io/docs/concepts/services-networking/topology-aware-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 kombinierten Modus mit Hybridknoten und Knoten in der AWS Cloud ausführen, empfehlen wir Ihnen, mindestens eine CoreDNS-Replik auf Hybridknoten und mindestens eine CoreDNS-Replik auf Ihren Knoten in der AWS Cloud zu haben. 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](https://kubernetes.io/docs/reference/networking/virtual-ips/#traffic-distribution) 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](https://kubernetes.io/docs/concepts/services-networking/topology-aware-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.
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.
1. 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)](hybrid-nodes-nodeadm.md#hybrid-nodes-nodeadm-kubelet). Beachten Sie, dass Knoten, die in der AWS Cloud ausgeführt werden, automatisch eine Topologie-Zonenbezeichnung erhalten, die der Availability Zone (AZ) des Knotens entspricht.
```
kubectl label node {{hybrid-node-name}} topology.kubernetes.io/zone={{zone}}
```
1. 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
...
```
1. 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"
}
}'
```
1. 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 [.replaceable]`kube-dns-` -n kube-system -o yaml
```
```
addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
-
hints:
forZones:
- name: onprem
nodeName:
zone: onprem
- addresses:
-
hints:
forZones:
- name: us-west-2a
nodeName:
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-Lastenverteilungs-Controller
+ CloudWatch-Beobachtbarkeits-Agent
+ AWS Distro for OpenTelemetry (ADOT)
+ `cert-manager`
Informationen zum Konfigurieren der von diesen Add-Ons verwendeten Webhooks für die Ausführung auf Knoten in der AWS Cloud finden Sie in den folgenden Abschnitten.
#### AWS-Lastenverteilungs-Controller
Um den AWS Load Balancer Controller in einer Cluster-Konfiguration im kombinierten Modus zu verwenden, ist es erforderlich, den Controller auf Knoten in der AWS Cloud auszufü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-Beobachtbarkeits-Agent
Das Add-On für den CloudWatch-Beobachtbarkeits-Agent verfügt über einen Kubernetes-Operator, der Webhooks verwendet. Um den Operator auf Knoten in der AWS Cloud in einer Cluster-Konfiguration im kombinierten Modus auszuführen, bearbeiten Sie die Konfiguration des Operators für den CloudWatch-Beobachtbarkeits-Agenten. 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](https://github.com/aws/containers-roadmap/issues/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 Distro for 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 einer Cluster-Konfiguration im kombinierten Modus auszuführen, fügen Sie 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
```
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
```
Das ADOT-Add-on erfordert die Installation von `cert-manager` für die vom ADOT-Operator-Webhook verwendeten TLS-Zertifikate. `cert-manager` führt ebenfalls Webhooks aus und kann mit der folgenden Helm-Wertekonfiguration für die Ausführung auf Knoten in der AWS Cloud konfiguriert werden.
```
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 mit der folgenden Helm-Wertekonfiguration so konfigurieren, dass es auf Knoten in der AWS Cloud 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
```