Warum konnten die Worker-Knoten meinem Amazon-EKS-Cluster nicht beitreten?

Kurzbeschreibung

Wenn du versuchst, dem Amazon-EKS-Cluster Worker-Knoten hinzuzufügen, tritt möglicherweise eines der folgenden Probleme auf:

• Wenn du eine verwaltete Knotengruppe im EKS-Cluster erstellst, wechselt die verwaltete Knotengruppe in den Status Erstellung fehlgeschlagen. Die Worker-Knoten treten dem EKS-Cluster nicht bei, und du erhältst die Fehlermeldung „Instances failed to join the kubernetes cluster“.
• Die neuen Worker-Knoten können dem EKS-Cluster nicht beitreten, wenn du die verwaltete Knotengruppe im EKS-Cluster aktualisierst.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

Das Systems Manager-Automatisierungs-Runbook verwenden

Verwende das AWSSupport-TroubleshootEKSWorkerNode-Runbook, um zu ermitteln, warum die Worker-Knoten dem Cluster nicht beitreten.

Wichtig: Damit die Automatisierung funktioniert, müssen die Worker-Knoten die Berechtigung haben, auf AWS Systems Manager zuzugreifen und ihn auszuführen. Um die Genehmigung zu erteilen, füge die von AWS verwaltete-Richtlinie AmazonSSMManagedInstanceCore an die AWS Identity and Access Management (IAM)-Rolle für das Amazon Elastic Compute Cloud (Amazon EC2)-Instance-Profil an. Verwende die AmazonSSMManagedInstanceCore-Richtlinie als Standardkonfiguration für die von Amazon EKS verwalteten Knotengruppen, die du über eksctl erstellst. Verwende das Format [-a-zA-Z0-9]{1,100}$ für den Clusternamen.

Gehe wie folgt vor, um die Automatisierung auszuführen:

1. Öffne auf der Systems-Manager-Konsole das AWSSupport-TroubleshootEKSWorkerNode-Runbook.
2. Hinweis: Weitere Informationen zum Runbook findest du im Abschnitt Dokumentdetails des Runbook.
3. Vergewissere dich, dass du die AWS-Region auf dieselbe Region wie der Cluster festgelegt hast.
4. Gib im Abschnitt Eingabeparameter den Namen des Clusters im Feld ClusterName und die Amazon-EC2-Instance-ID im Feld WorkerID ein.
5. (Optional) Gib im Feld AutomationAssumeRole den Amazon-Ressourcennamen (ARN) der IAM-Rolle ein, mit der die Automatisierung Aktionen für dich ausführen kann. Wenn du keine IAM-Rolle angibst, verwendet die Automatisierung die Berechtigungen des Benutzers, der das Runbook startet.
6. Wähle Ausführen aus.
7. Lies den Abschnitt Ausgaben, um die Ursache des Problems zu ermitteln und Maßnahmen zu seiner Behebung zu ergreifen.

Die DNS-Unterstützung für die Amazon-VPC überprüfen

Vergewissere dich, dass du die DNS-Hostnamen und die DNS-Auflösung in der Amazon Virtual Private Cloud (Amazon VPC) für den EKS-Cluster aktiviert hast.

Sicherstellen, dass die Worker-Knoten des Instance-Profils über die richtigen Berechtigungen verfügen

Füge die folgenden von AWS verwalteten Richtlinien an die Rolle an, die den Worker-Knoten des Instance-Profils zugeordnet ist: 

• AmazonEKSWorkerNodePolicy
• AmazonEKS_CNI_Policy
• AmazonEC2ContainerRegistryReadOnly

Stelle sicher, dass die Berechtigungsgrenze oder die Service-Kontrollrichtlinie (SCP) auf Organisations- oder Kontoebene den Worker-Knoten nicht darauf beschränkt, API-Aufrufe zu tätigen. 

Die Benutzerdaten für die Worker-Knoten konfigurieren

Hinweis: Wenn du AWS CloudFormation verwendest, um die Worker-Knoten zu starten, musst du die Benutzerdaten für die Worker-Knoten nicht konfigurieren. Verwende stattdessen die CloudFormation-Konsole, um selbstverwaltete Amazon-Linux-Knoten zu starten.

Wenn du verwaltete Knotengruppen verwendest, um den Worker-Knoten zu starten, musst du keine Benutzerdaten mit Amazon-EKS-optimierten Amazon Machine Images (AMIs) von Amazon Linux konfigurieren. Konfiguriere die Benutzerdaten nur, wenn du benutzerdefinierte AMIs verwendest, um die Worker-Knoten über verwaltete Knotengruppen zu starten.

Wenn du von Amazon EKS verwaltete Knotengruppen mit einer benutzerdefinierten Startvorlage verwendest, gib in der Startvorlage die richtigen Benutzerdaten an. Wenn der Amazon-EKS-Cluster ein vollständig privater Cluster ist, der VPC-Endpunkte für die Verbindung verwendet, musst du die Benutzerdaten aktualisieren. Gib die Zertifizierungsstelle (CA), den API-Serverendpunkt und die DNS-Cluster-IP-Adresse in den Benutzerdaten an.

Beispiel für eine Benutzerdatenkonfiguration:

#!/bin/bash
set -ex
B64_CLUSTER_CA=CA-CERT
API_SERVER_URL=ENDPOINT
K8S_CLUSTER_DNS_IP=IP-ADDRESS
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments} —b64-cluster-ca $B64_CLUSTER_CA —apiserver-endpoint $API_SERVER_URL —dns-cluster-ip $K8S_CLUSTER_DNS_I

Hinweis: Ersetze CA-CERT, ENDPOINT und IP-ADDRESS durch die Werte aus deiner Instance. Ersetze außerdem ${ClusterName} durch den Namen deines EKS-Clusters und ${BootstrapArguments} durch zusätzliche Bootstrap-Werte, falls erforderlich.

Wenn du Benutzerdaten angeben musst, um Argumente an die bootstrap.sh-Datei für das Amazon-EKS-optimierte Linux/Bottlerocket-AMI weiterzugeben, gib eine AMI-ID im ImageField der Startvorlage an.

Um Benutzerdaten für die Worker-Knoten zu konfigurieren, gib die Benutzerdaten an, wenn du die EC2-Instances startest.

Wenn du beispielsweise ein Drittanbieter-Tool wie Terraform verwendest, aktualisiere das Benutzerdaten-Feld, um die EKS-Worker-Knoten zu starten.

Beispiel für eine Benutzerdatenkonfiguration:

#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh ${ClusterName} ${BootstrapArguments}

Hinweis: Ersetze ${ClusterName} durch den Namen des EKS-Clusters und ${BootstrapArguments} durch zusätzliche Bootstrap-Werte, falls erforderlich.

Wenn du ein Amazon-Linux-2023-AMI verwendest, füge den Benutzerdaten die mindestens erforderlichen Parameter im folgenden Format hinzu:

MIME-Version: 1.0Content-Type: multipart/mixed; boundary="//"

--//
Content-Type: application/node.eks.aws

---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
  cluster:
    apiServerEndpoint: https://example.com
    certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
    cidr: 10.100.0.0/16
    name: my-cluster

--//--

Sicherstellen, dass du das Netzwerk für die Amazon-VPC-Subnetze korrekt konfiguriert hast und dass sich die Worker-Knoten in derselben Amazon-VPC wie der EKS-Cluster befinden

Wenn du ein Internet-Gateway verwendest, vergewissere dich, dass du es korrekt an die Routing-Tabelle angefügt hast.

Wenn du ein NAT-Gateway verwendest, stelle sicher, dass du es in einem öffentlichen Subnetz richtig konfiguriert hast. Stelle außerdem sicher, dass du die Routing-Tabelle richtig konfiguriert hast.

Wenn du private VPC-Endpunkte für einen vollständig privaten Cluster verwendest, stelle sicher, dass du über die folgenden Schnittstellenendpunkte verfügst:

• com.amazonaws.region.ec2
• com.amazonaws.region.ecr.api
• com.amazonaws.region.ecr.dkr
• com.amazonaws.region.sts

Stelle außerdem sicher, dass du den Gateway-Endpunkt com.amazonaws.region.s3 hast.

Du kannst die VPC-Endpunktrichtlinie des Amazon Simple Storage Service (Amazon S3)-Gateways für Amazon ECR einschränken. Weitere Informationen findest du unter Mindestberechtigungen für Amazon-S3-Buckets für Amazon ECR.

Pods, die du mit IAM-Rollen für Servicekonten konfigurierst, erhalten Anmeldeinformationen aus einem API-Aufruf von AWS Security Token Service (AWS STS). Wenn kein ausgehender Internetzugriff besteht, musst du einen AWS-STS-VPC-Endpunkt in der VPC erstellen und verwenden.

Die Sicherheitsgruppe für den VPC-Endpunkt muss über eine Regel für eingehenden Datenverkehr verfügen, die den Datenverkehr von Port 443 zulässt. Weitere Informationen findest du unter Datenverkehr zu deinen AWS-Ressourcen mithilfe von Sicherheitsgruppen steuern.

Stelle sicher, dass die Richtlinie, die an den VPC-Endpunkt angefügt ist, über die erforderlichen Berechtigungen verfügt, um API-Aufrufe an den jeweiligen Service zu tätigen.

Ermittle im Abschnitt Netzwerk des EKS-Clusters die Subnetze, die deinem Cluster zugeordnet sind. Vergewissere dich, dass sie derselben VPC angehören.

Du musst für jeden AWS-Service, den du verwendest, separate Endpunkte erstellen. Eine Liste der Endpunkte für gängige AWS-Services findest du in der Tabelle unter Pod requirements (Pod-Anforderungen). Du kannst auch einen Endpunkt-Service erstellen, der auf deinem Anwendungsfall basiert.

Du kannst ebenso verschiedene Subnetze konfigurieren, in denen die Worker-Knoten gestartet werden. Die Subnetze müssen in derselben Amazon-VPC vorhanden sein, und du musst sie entsprechend markieren. Amazon EKS verwaltet automatisch Tags nur für Subnetze, die du bei der Cluster-Erstellung konfigurierst. Weitere Informationen findest du unter Anforderungen und Überlegungen zu Subnetzen.

Aktualisieren der ConfigMap aws-auth mit der NodeInstanceRole deiner Worker-Knoten

Stelle sicher, dass du die ConfigMap aws-auth korrekt mit der IAM-Rolle des Worker-Knotens und nicht mit dem Instance-Profil konfiguriert hast.

Führe den folgenden Befehl aus:

kubectl describe configmap -n kube-system aws-auth

Wenn du die ConfigMap aws-auth nicht korrekt konfiguriert hast, erhältst du die folgende Fehlermeldung:

„571 reflector.go:153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:458 : Failed to list *v1.Node: Unauthorized“

Wenn du die EKS-API-Authentifizierungsmethode verwendest, erstelle einen Zugriffseintrag für die NodeInstanceRole. Wähle für Typ die Option EC2_linux aus.

Die Sicherheitsgruppenanforderungen der Worker-Knoten erfüllen

Vergewissere dich, dass du die Sicherheitsgruppe der Steuerebene und die Worker-Knoten-Sicherheitsgruppe mit den erforderlichen Einstellungen für eingehenden und ausgehenden Datenverkehr konfiguriert hast. Stelle außerdem sicher, dass du die Regeln für die Netzwerk-Zugriffssteuerungsliste (Netzwerk-ACL) so konfiguriert hast, dass der Datenverkehr zu und von 0.0.0.0/0 für die Ports 80, 443 und 1025-65535 zugelassen wird.

Festlegen der Tags für deine Worker-Knoten

Lege für die Tag-Eigenschaft der Worker-Knoten Schlüssel auf kubernetes.io/cluster/clusterName und Wert auf owned (nicht eigenständig) fest.

Weitere Informationen findest du unter Anforderungen und Überlegungen zu VPCs.

Prüfen, ob die Worker-Knoten den API-Serverendpunkt für den EKS-Cluster erreichen können

Starte Worker-Knoten in einem Subnetz, das mit einer Routing-Tabelle verknüpft ist, die über ein NAT- oder Internet-Gateway zum API-Endpunkt weitergeleitet wird. Wenn du die Worker-Knoten in einem eingeschränkten privaten Netzwerk startest, stelle sicher, dass die Worker-Knoten den EKS-API-Serverendpunkt erreichen können. Wenn du Worker-Knoten mit einer Amazon-VPC startest, die ein benutzerdefiniertes DNS anstelle von AmazonProvidedDNS verwendet, lösen die Worker-Knoten den Endpunkt möglicherweise nicht auf.

Hinweis: Der Endpunkt ist ungelöst, wenn du den öffentlichen Zugriff auf den Endpunkt deaktivierst und nur den privaten Zugriff aktivierst. Weitere Informationen findest du unter Aktivieren der DNS-Auflösung für Amazon-EKS-Cluster-Endpunkte.

Sich vergewissern, dass du Kubelet die erforderlichen Endpunkte erreichen kann

Führe die folgenden Befehle aus, um zu testen, ob Kubelet die Endpunkte erreichen kann:

$ nc -vz ec2.region.amazonaws.com 443

$ nc -vz dkr.ecr.region.amazonaws.com 443

$ nc -vz api.ecr.region.amazonaws.com 443

$ nc -vz s3.region.amazonaws.com 443

Hinweis: Ersetze region durch deine Region.

Sich vergewissern, dass du die Clusterrolle richtig konfiguriert hast

Du musst AmazonEKSClusterPolicy an deine Amazon-EKS-Cluster-IAM-Rolle anfügen. Außerdem muss die Vertrauensstellung des Clusters den Service eks.amazonaws.com für sts:AssumeRole zulassen.

Beispiel für eine Vertrauensrichtlinie:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Sich vergewissern, dass du regionale STS-Endpunkte aktiviert hast

Wenn sich der Cluster in einer Region befindet, die STS-Endpunkte unterstützt, aktiviere den regionalen STS-Endpunkt, um das Kubelet zu authentifizieren. Das Kubelet kann dann das Knotenobjekt erstellen.

Sicherstellen, dass du das AMI so konfiguriert hast, dass es mit EKS funktioniert und dass das AMI die erforderlichen Komponenten enthält

Das für Amazon-EKS-optimierte Amazon-Linux-AMI enthält die erforderlichen Komponenten, um mit dem EKS-Cluster zu arbeiten. Wenn das AMI der Worker-Knoten nicht das Amazon-EKS-optimierte Amazon-Linux-AMI ist, stelle sicher, dass sich die folgenden Kubernetes-Komponenten im Status Aktiv befinden:

• kubelet
• AWS IAM Authenticator
• Docker (Amazon EKS Version 1.23 und früher)
• containerd

SSH verwenden, um eine Verbindung zur EKS-Worker-Knoten-Instance herzustellen und die Kubelet-Agent-Protokolle zu überprüfen

Überprüfe, ob du den Kubelet-Agent als systemd-Service in der EKS-Worker-Knoten-Instance konfiguriert hast.

Führe den folgenden Befehl aus, um die Kubelet-Protokolle zu validieren:

journalctl -f -u kubelet

Informationen zum Beheben von Problemen findest du unter Problembehandlung bei Amazon-EKS-Clustern und -Knoten.

Das Collector-Skript des Amazon-EKS-Protokolls verwenden, um Fehler zu beheben

Verwende die Protokolldateien und Betriebssystemprotokolle, um Probleme im Amazon-EKS-Cluster zu beheben. Amazon-EKS-Cluster-Worker-Knoten speichern cloud-init-Initialisierungsprotokolle in /var/log/cloud-init-output.log und /var/log/cloud-init.log.

Um das EKS-Protokoll-Collector-Skript zum Erfassen von Protokollen zu verwenden, musst du SSH verwenden, um eine Verbindung zum Worker-Knoten herzustellen, bei dem das Problem auftritt. Führe dann das folgende Skript aus:

curl -O https://raw.githubusercontent.com/awslabs/amazon-eks-ami/master/log-collector-script/linux/eks-log-collector.sh

sudo bash eks-log-collector.sh

Sicherstellen, dass die Amazon-VPC-Subnetze für den Worker-Knoten über verfügbare IP-Adressen verfügen

Wenn die Amazon-VPC keine verfügbaren IP-Adressen hat, kannst du der bestehenden Amazon-VPC ein sekundäres CIDR zuordnen. Weitere Informationen findest du unter Amazon-EKS-Netzwerkanforderungen für VPC und Subnetze anzeigen. Das EKS-optimierte AMI enthält die für die Arbeit mit dem EKS-Cluster erforderlichen Komponenten.