Wie behebe ich eksctl-Probleme mit Amazon-EKS-Clustern und Knotengruppen?

Kurzbeschreibung

Im Folgenden sind häufige Probleme aufgeführt, die auftreten können, wenn Sie eksctl zum Erstellen oder Verwalten eines Amazon-EKS-Clusters oder einer Knotengruppe verwenden:

• Sie wissen nicht, wie Sie mit eksctl einen Cluster erstellen können. Weitere Informationen finden Sie unter Erste Schritte mit Amazon EKS – eksctl und im Abschnitt eksctl unter Erstellen eines Amazon-EKS-Clusters.
• Sie wissen nicht, wie Sie Kubelet-Bootstrap-Optionen für verwaltete Knotengruppen angeben können. Befolgen Sie die Schritte im Auflösungsabschnitt für Kubelet-Bootstrap-Optionen angeben.
• Sie können den Instance-Typ einer vorhandenen Knotengruppe nicht ändern. Sie müssen eine neue Knotengruppe erstellen. Weitere Informationen finden Sie unter Migration zu einer neuen Knotengruppe und Unveränderlichkeit von Knotengruppe (auf der eskctl-Website).
• Sie haben die maximale Anzahl von AWS-Ressourcen erreicht. Überprüfen Sie Ihre Ressourcen, um zu sehen, ob Sie diejenigen löschen können, die Sie nicht verwenden. Wenn Sie noch mehr Kapazität benötigen, lesen Sie Quotenerhöhung beantragen.
• Sie starten Steuerebenen-Instances in einer Availability Zone mit begrenzter Kapazität. Weitere Informationen finden Sie unter Wie behebe ich Fehler bei der Cluster-Erstellung in Amazon EKS?
• Ihre Knoten können nicht in den Bereit-Zustand versetzt werden. Befolgen Sie die Schritte im Abschnitt Probleme mit dem Zeitlimit für den Vorgang lösen.
• Exportwerte sind für den Cluster nicht vorhanden. Befolgen Sie die Schritte im Auflösungsabschnitt Die Knotengruppe in privaten Subnetzen erstellen.
• Sie haben einen nicht unterstützten Instance-Typ verwendet, um einen Cluster oder eine Knotengruppe zu erstellen. Befolgen Sie die Schritte im Auflösungsabschnitt Prüfen, ob Ihr Instance-Typ unterstützt wird.

Auflösung

Festlegen von Kubelet-Bootstrap-Optionen

Standardmäßig erstellt eksctl ein Bootstrap-Skript und fügt es der Startvorlage hinzu, die die Worker-Knoten während des Bootstrap-Prozesses ausführen. Um Ihre eigenen Kubelet-Bootstrap-Optionen anzugeben, verwenden Sie die Spezifikation overrideBootstrapCommand, um das Bootstrap-Skript eksctl zu überschreiben. Verwenden Sie den overrideBootstrapCommand für verwaltete und selbstverwaltete Knotengruppen.

Konfigurationsdatei-Spezifikation:

managedNodeGroups:
  name: custom-ng
  ami: ami-0e124de4755b2734d
  securityGroups:
    attachIDs: ["sg-1234"]
  maxPodsPerNode: 80
  ssh:
    allow: true
  volumeSize: 100
  volumeName: /dev/xvda
  volumeEncrypted: true
  disableIMDSv1: true
  overrideBootstrapCommand: |
  #!/bin/bash
  /etc/eks/bootstrap.sh managed-cluster --kubelet-extra-args '--node-labels=eks.amazonaws.com/nodegroup=custom-ng,eks.amazonaws.com/nodegroup-image=ami-0e124de4755b2734d'

Hinweis: Sie können overrideBootstrapCommand nur verwenden, wenn Sie ein benutzerdefiniertes AMI verwenden. Wenn Sie keine AMI-ID angeben, schlägt die Cluster-Erstellung fehl.

Eine benutzerdefinierte AMI-ID wurde nicht angegeben

Wenn Sie beim Erstellen verwalteter Knotengruppen keine benutzerdefinierte AMI-ID angeben, verwendet Amazon EKS standardmäßig ein für Amazon EKS optimiertes AMI- und Bootstrap-Skript. Um ein für Amazon EKS optimiertes AMI mit benutzerdefinierten Benutzerdaten zur Angabe von Bootstrap-Parametern zu verwenden, geben Sie die AMI-ID in Ihrer Konfiguration für verwaltete Knotengruppen an.

Führen Sie den folgenden Befehl aus, um die neueste AMI-ID für das neueste für Amazon EKS optimierte AMI abzurufen:

aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.21/amazon-linux-2/recommended/image_id --region Region --query "Parameter.Value" --output text

Hinweis: Ersetzen Sie die Region durch Ihre AWS-Region.

Beheben von Problemen mit dem Betriebs-Timeout

Wenn Sie beim Erstellen eines Knotens die folgende Fehlermeldung erhalten, kann es bei Ihrer Knotengruppe zu Timeout-Problemen kommen:

waiting for at least 1 node(s) to become ready in "nodegroup"

Wenn Sie eine EKS-Knotengruppe mit eksctl erstellen, stellt die eksctl-CLI eine Verbindung zum API-Server her, um kontinuierlich den Status des Kubernetes-Knotens zu überprüfen. Die CLI wartet darauf, dass die Knoten in den Zustand Bereit versetzt werden und läuft schließlich ab, wenn sich die Knoten nicht bewegen können.

Die folgenden Gründe sind, warum die Knoten nicht in den Zustand Bereit versetzt werden können:

• Das Kubelet kann während des Bootstrapping-Vorgangs nicht mit dem EKS-API-Server-Endpunkt kommunizieren oder sich authentifizieren.
• Die Pods aws-node und kube-proxy befinden sich nicht im Status Wird ausgeführt.
• Die Benutzerdaten des Amazon Elastic Compute Cloud (Amazon EC2)-Worker-Knotens wurden nicht erfolgreich ausgeführt.

Das Kubelet kann nicht mit dem EKS-API-Server-Endpunkt kommunizieren

Wenn das Kubelet während des Bootstrapping-Vorgangs nicht mit dem EKS-API-Server-Endpunkt kommunizieren kann, rufen Sie den EKS-API-Server-Endpunkt ab.

Führen Sie den folgenden Befehl auf Ihrem Worker-Knoten aus:

curl -k https://123456DC0A12EC12DE0C12BC312FCC1A.yl4.us-east-1.eks.amazonaws.com
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {
    
  },
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {
    
  },
  "code": 403
}

Der vorhergehende Befehl sollte den HTTP-403-Statuscode zurückgeben. Wenn der Befehl eine Zeitüberschreitung hat, liegt möglicherweise ein Problem mit der Netzwerkkonnektivität zwischen dem EKS-API-Server und den Worker-Knoten.

Führen Sie einen der folgenden Schritte aus, die sich auf Ihren Anwendungsfall beziehen, um das Konnektivitätsproblem zu beheben:

• Wenn sich die Worker-Knoten in einem privaten Subnetz befinden, überprüfen Sie, ob sich der EKS-API-Serverendpunkt im privaten oder öffentlichen und privaten Zugriffsmodus befindet.
• Wenn der EKS-API-Server-Endpunkt auf Privat festgelegt ist, müssen Sie bestimmte Regeln für die private gehostete Zone anwenden, um den Datenverkehr zum API-Server weiterzuleiten. Die Amazon Virtual Private Cloud (Amazon VPC)-Attribute enableDnsHostnames und enableDNSSupport müssen auf True festgelegt sein. Außerdem müssen die für die Amazon VPC festgelegten DHCP-Optionen AmazonProvideDNS in seiner Domänenliste enthalten.
• Wenn Sie die Knotengruppe in öffentlichen Subnetzen erstellt haben, stellen Sie sicher, dass das öffentliche IPv4-Adressierungsattribut der Subnetze auf True festgelegt ist. Wenn Sie das Attribut nicht auf True festlegen, wird den Worker-Knoten keine öffentliche IP-Adresse zugewiesen und sie können nicht auf das Internet zugreifen.
• Prüfen Sie, ob die Amazon-EKS-Cluster-Sicherheitsgruppe eingehende Anforderungen an Port 443 von der Sicherheitsgruppe des Worker-Knotens zulässt.

Das Kubelet kann sich nicht mit dem EKS-API-Server-Endpunkt authentifizieren

Wenn sich das Kubelet während des Bootstrapping-Vorgangs nicht beim EKS-API-Server-Endpunkt authentifizieren kann, führen Sie die folgenden Schritte aus.

1.    Führen Sie den folgenden Befehl aus, um sicherzustellen, dass der Worker-Knoten Zugriff auf den STS-Endpunkt hat:

telnet sts.region.amazonaws.com 443

Hinweis: Ersetzen Sie die Region durch Ihre AWS-Region.

2.    Stellen Sie sicher, dass die AWS-IAM-Rolle (Identity and Access Management) des Worker-Knotens zur ConfigMap aws-auth hinzugefügt wurde.

Beispiel:

apiVersion:v1 kind:ConfigMap metadata:name:aws-auth namespace:kube-system data:mapRoles:|
    - rolearn: ARN of instance role (not instance profile)
      username: system:node:{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Hinweis: Für Microsoft-Windows-Knotengruppen müssen Sie eine zusätzliche eks:kube-proxy-windows-RBAC-Gruppe zum Abschnitt mapRoles für die IAM-Rolle der Knotengruppe hinzufügen.

Die AWS-Node- und Kube-Proxy-Pods sind nicht im Status „Wird ausgeführt“

Führen Sie den folgenden Befehl aus, um zu überprüfen, ob sich die Pods aws-node und kube-proxy im Status Wird ausgeführt befinden:

kubectl get pods -n kube-system

Wenn sich der Pod aws-node im Status Schlägt fehl befindet, überprüfen Sie die Verbindung zwischen dem Worker-Knoten und dem Amazon-EC2-Endpunkt:

ec2.region.amazonaws.com

Hinweis: Ersetzen Sie die Region durch Ihre AWS-Region.

Überprüfen Sie, ob die von AWS verwalteten Richtlinien AmazonEKSWorkerNodePolicy und AmazonEC2ContainerRegistryReadOnly an die IAM-Rolle der Knotengruppe angehängt sind.

Wenn sich die Knoten in einem privaten Subnetz befinden, konfigurieren Sie Amazon-ECR-VPC-Endpunkte so, dass Images aus der Amazon Elastic Container Registry (Amazon ECR) abgerufen werden können.

Wenn Sie IRSA für Ihre Amazon VPC CNI verwenden, hängen Sie die AWS-verwaltete Richtlinie AmazonEKS_CNI_Policy an die IAM-Rolle an, die die Pods aws-node verwenden. Sie müssen die Richtlinie auch ohne IRSA an die IAM-Rolle der Knotengruppe anhängen.

Die Benutzerdaten des EC2-Worker-Knotens wurden nicht erfolgreich ausgeführt

Um zu überprüfen, ob bei der Ausführung der Benutzerdaten Fehler aufgetreten sind, überprüfen Sie die Cloud-Init-Protokolle unter /var/log/cloud-init.log und /var/log/cloud-init-output.log.

Führen Sie das EKS-Logs-Collector-Skript auf den Worker-Knoten aus, um weitere Informationen zu erhalten.

Erstellen der Knotengruppe in privaten Subnetzen

Wenn Sie beim Erstellen einer Knotengruppe die folgende Fehlermeldung erhalten, erstellen Sie die Knotengruppe in privaten Subnetzen:

No export named eksctl--cluster::SubnetsPublic found. Rollack requested by user

Wenn Sie den Amazon-EKS-Cluster mit PrivateOnly-Netzwerk erstellt haben, kann AWS CloudFormation keine öffentlichen Subnetze erstellen. Das bedeutet, dass Exportwerte für öffentliche Subnetze nicht existieren. Wenn für den Cluster keine Exportwerte vorhanden sind, schlägt die Erstellung der Knotengruppe fehl.

Um dieses Problem zu beheben, können Sie das Flag --node-private-networking einschließen, wenn Sie den Inline-Befehl eksctl verwenden. Sie können auch die Spezifikation privateNetworking: true innerhalb der Knotengruppenkonfiguration verwenden, um die Erstellung von Knotengruppen in privaten Subnetzen anzufordern.

Aktualisieren Ihrer eksctl-Version oder Angeben der richtigen AWS-Region

Wenn Sie die folgende Fehlermeldung erhalten, überprüfen Sie Ihre AWS-Region:

no eksctl-managed CloudFormation stacks found for "cluster-name"

Wenn Sie eine eksctl-Version verwenden, die älter als 0.40.0 ist, können Sie nur Amazon-EKS-Ressourcen anzeigen oder verwalten, die Sie mit eksctl erstellt haben. Um Ressourcen zu verwalten, die nicht mit eksctl erstellt wurden, aktualisieren Sie eksctl auf Version 0.40.0 oder höher. Informationen zu den Befehlen, die Sie für Cluster ausführen können, die nicht mit eksctl erstellt wurden, finden Sie unter Nicht von Eksctl erstellte Cluster (von der eksctl-Website).

Außerdem werden von eksctl verwaltete CloudFormation-Stacks nicht gefunden, wenn Sie eine falsche AWS-Region angeben. Um dieses Problem zu beheben, stellen Sie sicher, dass Sie die richtige Region angeben, in der sich Ihre Amazon-EKS-Ressourcen befinden.

Prüfen Sie, ob Ihr Instance-Typ unterstützt wird

Wenn Sie einen nicht unterstützten Instance-Typ zum Erstellen eines Clusters oder Knotens verwendet haben, wird der folgende Fehler angezeigt:

You must use a valid fully-formed launch template. The requested configuration is currently not supported. Please check the documentation for supported configurations'

Um zu überprüfen, ob Ihr Instance-Typ oder andere Konfigurationen in einer bestimmten AWS-Region unterstützt werden, führen Sie den folgenden Befehl aus:

aws ec2 describe-instance-type-offerings --region Region --query 'InstanceTypeOfferings[*].{InstanceType:InstanceType}'

Hinweis: Ersetzen Sie die Region durch Ihre AWS-Region.

---