**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.
# Behebung von Ausgangsproblemen auf der Steuerungsebene
Wenn Sie den Ausgangsmodus der `CUSTOMER_ROUTED` Steuerungsebene verwenden, sind Sie für die Netzwerkkonnektivität der ENIs der Steuerungsebene verantwortlich. Auf dieser Seite werden häufig auftretende Probleme und deren Lösungen behandelt.
## Erkennen Sie einen fehlgeschlagenen Webhook
Wenn die Steuerungsebene keinen Webhook-Server oder OIDC-Anbieter erreichen kann, tritt das Symptom normalerweise als Webhook-Timeout auf. Um eine Ressource zu bestätigen, zu erstellen oder zu ändern, die den Webhook auslöst, und den Fehler zu überprüfen:
```
kubectl apply -f my-resource.yaml
```
Ein Konnektivitäts- oder DNS-Fehler führt normalerweise zu einem Fehler, der dem folgenden ähnelt:
```
Error from server (InternalError): error when creating "my-resource.yaml": Internal error occurred:
failed calling webhook "my-webhook.example.com": failed to call webhook:
Post "https://my-webhook.example.com/validate?timeout=10s": context deadline exceeded
```
Sie können auch aktuelle Ereignisse im gesamten Cluster auf Webhook-Fehler überprüfen:
```
kubectl get events --all-namespaces --field-selector reason=FailedCreate
```
+ Wenn der Fehler ein Timeout (`context deadline exceeded`) oder eine verweigerte Verbindung ist, kann die Steuerungsebene den Webhook-Endpunkt nicht erreichen. Siehe [Keine Ausgangsroute zu den erforderlichen Endpunkten](#egress-troubleshoot-natgw), [NACLs blockieren den Webhook- oder Kontrollflugzeugverkehr](#egress-troubleshoot-nacl) und [Sicherheitsgruppen verhindern den Zugriff](#egress-troubleshoot-sg).
+ Wenn in dem Fehler ein DNS-Fehler oder kein Hostausfall angegeben ist, kann die Steuerungsebene den Endpunkt nicht auflösen. Siehe [Aktualisierung des DHCP-Optionssatzes fehlgeschlagen](#egress-troubleshoot-dhcp).
## Keine Ausgangsroute zu den erforderlichen Endpunkten
**Symptome:**
+ Zeitlimit für Webhooks bei Zulassung.
+ Die Erkennung des OIDC-Anbieters schlägt fehl.
+ Die Clustererstellung oder -aktualisierung kommt zum Stillstand.
**Ursache:**
Die Subnetze der Netzwerkschnittstelle der Steuerungsebene haben keine funktionierende Route zu den Endpunkten, die die Steuerungsebene erreichen muss. In den meisten Fällen fehlt in der Subnetz-Routentabelle eine Standardroute zu einem Ausgangsgerät. Alternativ ist dieses Gerät falsch konfiguriert. Das Ausgangsgerät ist normalerweise ein NAT-Gateway. Es kann sich jedoch um eine NAT-Instance, eine Firewall oder eine Proxy-Appliance oder ein Transit-Gateway zu einer zentralen Ausgangs-VPC VPC.
**Lösung:**
1. Identifizieren Sie die Subnetze, die Ihr Cluster für Netzwerkschnittstellen auf der Steuerungsebene verwendet:
```
aws eks describe-cluster --name my-cluster \
--query "cluster.resourcesVpcConfig.subnetIds"
```
1. Überprüfen Sie für jedes Subnetz die zugehörige Routing-Tabelle:
```
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1"
```
1. Stellen Sie sicher, dass eine Route für Ihr Ausgangsgerät existiert `0.0.0.0/0` (oder eine Route, die den Endpunkt abdeckt). Falls sie fehlt, fügen Sie die Route hinzu. Im folgenden Beispiel wird eine NAT-Gateway-Route hinzugefügt. Ersetzen Sie Ihr eigenes Ausgangsziel (z. B. ein Transit-Gateway oder eine Netzwerkschnittstelle):
```
aws ec2 create-route \
--route-table-id rtb-ExampleID \
--destination-cidr-block 0.0.0.0/0 \
--nat-gateway-id nat-ExampleID
```
## NACLs blockieren den Webhook- oder Kontrollflugzeugverkehr
**Symptome:**
+ Timeout für Zugriffs-Webhook-Aufrufe (Fehler:). `failed calling webhook`
+ Zeitweise auftretende Fehler beim Erstellen oder Ändern von Kubernetes-Ressourcen, die mutierende oder validierende Webhooks verwenden.
**Ursache:**
Netzwerk-ACLs auf den ENI-Subnetzen der Steuerungsebene blockieren ausgehenden Datenverkehr zu Webhook-Endpunkten oder blockieren den eingehenden kurzlebigen Port-Return-Verkehr.
**Lösung:**
1. Identifizieren Sie die NACLs, die Ihren Subnetzen auf der Kontrollebene zugeordnet sind:
```
aws ec2 describe-network-acls \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1"
```
1. Stellen Sie sicher, dass die folgenden Regeln existieren:
[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/eks/latest/userguide/control-plane-egress-troubleshooting.html)
**Anmerkung**
NACLs sind staatenlos. In den Regeln für eingehenden Datenverkehr müssen Sie Rückverkehr auf kurzlebigen Ports (1024—65535) ausdrücklich zulassen.
Diese Regeln decken zwei verschiedene Pfade ab. Die Port-443-Regel gilt für ausgehenden Datenverkehr zu Webhook- und OIDC-Endpunkten, der die VPC über Ihr Ausgangsgerät verlässt. Die Port-10250-Regel gilt für die Kubelet-API, die in Ihrer VPC zwischen der Kontrollebene und Ihren Knoten verbleibt. Ein fehlendes Ausgangsgerät wirkt sich nicht auf Port 10250 aus, aber eine restriktive Netzwerk-ACL kann ihn blockieren.
## Sicherheitsgruppen verhindern den Zugriff
**Symptome:**
+ Webhook-Aufrufe schlagen fehl.
+ Die Kontrollebene kann die Kubelet-API auf den Knoten (Port 10250) nicht erreichen.
+ `kubectl exec`,, oder `kubectl logs` scheitern. `kubectl port-forward`
**Ursache:**
Die an die ENiS der Steuerungsebene angefügte Sicherheitsgruppe (die *Cluster-Sicherheitsgruppe*) lässt ausgehenden Datenverkehr an den erforderlichen Ports nicht zu.
**Lösung:**
1. Identifizieren Sie die Cluster-Sicherheitsgruppe:
```
aws eks describe-cluster --name my-cluster \
--query "cluster.resourcesVpcConfig.clusterSecurityGroupId"
```
1. Überprüfen Sie, ob die Regeln für ausgehende Nachrichten Folgendes zulassen:
[See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/eks/latest/userguide/control-plane-egress-troubleshooting.html)
1. Wenn ausgehende Regeln restriktiv sind, fügen Sie Regeln für den erforderlichen Datenverkehr hinzu:
```
aws ec2 authorize-security-group-egress \
--group-id sg-ExampleClusterSG \
--protocol tcp \
--port 443 \
--cidr 0.0.0.0/0
```
**Anmerkung**
Wenn Sie strenge Anforderungen für ausgehenden Datenverkehr haben und die IP-Bereiche Ihrer Webhook- und OIDC-Endpunkte kennen, können Sie die Port-443-Regel stattdessen auf diese spezifischen CIDRs beschränken. `0.0.0.0/0` Die Regel für Port 10250 (Kubelet-API) lautet VPC-internal: Beschränken Sie sie auf Ihre Knotensicherheitsgruppe oder VPC-CIDR und nicht auf das Internet.
## Aktualisierung des DHCP-Optionssatzes fehlgeschlagen
**Symptome:**
+ Die DNS-Auflösung schlägt auf der Steuerungsebene fehl.
+ Clustervorgänge, die DNS-Suchen erfordern (OIDC-Erkennung, Webhook-Auflösung), schlagen fehl.
+ Das Problem tritt auf, nachdem die VPC-DHCP-Optionen geändert wurden oder nach einem Update der Steuerungsebene.
**Ursache:**
Der VPC-DHCP-Optionssatz wurde geändert. Alternativ sind Server für Domainnamen nicht `AmazonProvidedDNS` in der Liste enthalten. Möglicherweise fehlt auch ein anderer Resolver, der die Namen, die die Steuerungsebene benötigt, auflösen kann. Die Steuerungsebene erkennt automatisch Änderungen am DHCP-Optionssatz und wendet die neuen DNS-Einstellungen an, normalerweise innerhalb einer Stunde. Die Kontrollebene kann dies nur tun, wenn die Cluster-IAM-Rolle die erforderlichen Amazon EC2 EC2-Leseberechtigungen gewährt.
**Lösung:**
1. Überprüfen Sie den DHCP-Optionssatz für Ihre VPC:
```
aws ec2 describe-vpcs --vpc-ids vpc-ExampleID \
--query "Vpcs[0].DhcpOptionsId" \
--region region-code
```
```
aws ec2 describe-dhcp-options --dhcp-options-ids dopt-ExampleID --region region-code
```
1. Vergewissern Sie sich, dass dies `AmazonProvidedDNS` (den Amazon-provided DNS-Resolver, der die Basis Ihres VPC-IPv4-CIDR bildet, plus zwei) oder einen anderen Resolver `domain-name-servers` enthält, der die Namen auflösen kann, die die Kontrollebene benötigt.
1. Bestätigen Sie, dass die Cluster-IAM-Rolle gewährt wird und. `ec2:DescribeVpcs` `ec2:DescribeDhcpOptions` Ohne diese Berechtigungen kann die Steuerungsebene die aktualisierten DHCP-Optionen nicht lesen und ihre DNS-Einstellungen nicht aktualisieren. Weitere Informationen finden Sie unter [Amazon EKS-Cluster-IAM-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/cluster-iam-role.html).
1. Warten Sie nach einer Änderung der DHCP-Optionen bis zu einer Stunde, bis die Steuerungsebene die neuen Einstellungen automatisch erkennt und anwendet. Es ist kein Cluster-Update oder Instanzaustausch erforderlich. Wenn die DNS-Auflösung nach einer Stunde immer noch fehlschlägt und die oben genannten Berechtigungen vorhanden sind, wenden Sie sich an den AWS Support.
## Probleme mit dem IPv6-Routing
**Symptome:**
+ IPv6-Cluster können keine externen OIDC- oder Webhook-Endpunkte erreichen.
+ Die Knotenregistrierung funktioniert über IPv4, aber IPv6-Dienste schlagen fehl.
**Ursache:**
In der Subnetz-Routentabelle fehlt eine `::/0` Route zu einem Internet-Gateway, das nur für ausgehenden Verkehr bestimmt ist, oder die Sicherheitsvorkehrungen groups/NACLs lassen keinen IPv6-Verkehr zu.
**Lösung:**
1. Stellen Sie sicher, dass ein Internet-Gateway nur für ausgehenden Datenverkehr vorhanden und mit der VPC verbunden ist:
```
aws ec2 describe-egress-only-internet-gateways \
--filters "Name=attachment.vpc-id,Values=vpc-ExampleID"
```
1. Überprüfen Sie, ob die Routentabelle für die Subnetze der Kontrollebene eine Route enthält: `::/0`
```
aws ec2 describe-route-tables \
--filters "Name=association.subnet-id,Values=subnet-ExampleID1" \
--query "RouteTables[0].Routes[?DestinationIpv6CidrBlock=='::/0']"
```
1. Falls sie fehlt, fügen Sie die Route hinzu:
```
aws ec2 create-route \
--route-table-id rtb-ExampleID \
--destination-ipv6-cidr-block ::/0 \
--egress-only-internet-gateway-id eigw-ExampleID
```
1. Stellen Sie sicher, dass NACLs und Sicherheitsgruppen ausgehende IPv6-Verbindungen auf Port 443 und eingehende ephemere Ports zulassen.
## OIDC-Anbieter nicht erreichbar
**Symptome:**
+ `IAM roles for service accounts`(IRSA) schlägt fehl — Pods können keine Rollen übernehmen.
+ Clusterereignisse zeigen OIDC-Erkennungsfehler an.
**Ursache:**
Die Steuerungsebene kann den Endpunkt des OIDC-Anbieters nicht erreichen (z. B.`oidc.eks.region-code.amazonaws.com`), da der Ausgang blockiert ist.
**Lösung:**
1. Stellen Sie sicher, dass der Ausgangspfad und die Routentabelle ausgehenden HTTPS-Verkehr zulassen. Schritte zur Fehlerbehebung, wenn die Ausgangsroute fehlt oder falsch konfiguriert ist, finden Sie unter. [Keine Ausgangsroute zu den erforderlichen Endpunkten](#egress-troubleshoot-natgw)
1. Stellen Sie sicher, dass die Cluster-Sicherheitsgruppe ausgehendes TCP 443 zulässt `0.0.0.0/0` (siehe). [Sicherheitsgruppen verhindern den Zugriff](#egress-troubleshoot-sg)
📝 [Bearbeiten Sie diese Seite auf GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23control-plane-egress-troubleshooting%5D&type=code)