View a markdown version of this page

Behebung von Ausgangsproblemen auf der Steuerungsebene - Amazon EKS
Erkennen Sie einen fehlgeschlagenen WebhookKeine Ausgangsroute zu den erforderlichen EndpunktenNACLs blockieren den Webhook- oder KontrollflugzeugverkehrSicherheitsgruppen verhindern den ZugriffAktualisierung des DHCP-Optionssatzes fehlgeschlagenProbleme mit dem IPv6-RoutingOIDC-Anbieter nicht erreichbar

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.

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

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"

  2. Ü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"

  3. 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"

  2. Stellen Sie sicher, dass die folgenden Regeln existieren:

    Richtung Protocol (Protokoll) Port-Bereich Destination/Source Action

    Ausgehend

    TCP

    443

    0.0.0. 0/0 (oder Webhook CIDR)

    Sobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf

    Ausgehend

    TCP

    10250

    VPC-CIDR

    Sobald Sie die Details auf dieser Seite überprüft haben, klicken Sie auf

    Eingehend

    TCP

    1024—65535

    0,0.0. 0/0

    Zulassen (kurzlebiger Rückverkehr)
    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"

  2. Überprüfen Sie, ob die Regeln für ausgehende Nachrichten Folgendes zulassen:

    Protocol (Protokoll) Port Ziel

    TCP

    443

    0.0.0. 0/0 (Webhook-Endpunkte, OIDC-Anbieter)

    TCP

    10250

    Knotensicherheitsgruppe oder VPC CIDR (Kubelet-API)

  3. 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

  2. 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.

  3. 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.

  4. 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"

  2. Ü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']"

  3. 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

  4. 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

  2. Stellen Sie sicher, dass die Cluster-Sicherheitsgruppe ausgehendes TCP 443 zulässt 0.0.0.0/0 (siehe). Sicherheitsgruppen verhindern den Zugriff

📝 Bearbeiten Sie diese Seite auf GitHub