Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Fehlerbehebung mit EKS Auto Mode

Mit EKS Auto Mode übernimmt AWS mehr Verantwortung für die EC2-Instances in Ihrem AWS-Konto. EKS übernimmt die Verantwortung für die Container-Laufzeit auf den Knoten, das Betriebssystem auf den Knoten und bestimmte Controller. Dazu gehören ein Blockspeicher-Controller, ein Load-Balancing-Controller und ein Compute-Controller.

Zur Fehlerbehebung bei Knoten müssen Sie AWS- und Kubernetes-APIs verwenden. Sie haben folgende Möglichkeiten:

Möglicherweise treten die folgenden Probleme auf, für die es spezifische Lösungen für EKS-Auto-Mode-Komponenten gibt:

Sie können die folgenden Methoden zur Fehlerbehebung bei EKS-Auto-Mode-Komponenten anwenden:

Knotenüberwachungsagent

EKS Auto Mode umfasst den Amazon-EKS-Knoten-Überwachungsagent. Mit diesem Agenten können Sie Informationen zur Fehlerbehebung und zum Debugging von Knoten anzeigen. Der Knoten-Überwachungsagent veröffentlicht Kubernetes events und Knoten conditions. Weitere Informationen finden Sie unter Aktivieren der automatischen Knoten-Reparatur und untersuchen von Problemen mit dem Zustand des Knotens .

Rufen Sie die Konsolenausgabe einer verwalteten EC2-Instance mithilfe der AWS EC2 CLI ab.

Dieses Verfahren unterstützt bei der Fehlerbehebung von Problemen beim Systemstart oder auf Kernel-Ebene.

Zunächst müssen Sie die EC2-Instance-ID der Instance ermitteln, die Ihrer Workload zugeordnet ist. Anschließend rufen Sie mithilfe der AWS-CLI die Konsolenausgabe ab.

Knotenprotokolle mithilfe von Debug-Containern und der kubectl-CLI abrufen

Die empfohlene Methode zum Abrufen von Protokollen von einem EKS-Auto-Mode-Knoten ist die Verwendung der NodeDiagnostic-Ressource. Diese Schritte finden Sie unter Abrufen von Knotenprotokollen für einen verwalteten Knoten mithilfe von kubectl und S3.

Sie können Protokolle jedoch auch live von einer Instance streamen, indem Sie den Befehl kubectl debug node verwenden. Dieser Befehl startet einen neuen Pod auf dem Knoten, den Sie debuggen möchten, und den Sie dann interaktiv verwenden können.

Aus Sicherheitsgründen installiert das Amazon-Linux-Container-Image standardmäßig nicht viele Binärdateien. Mit dem Befehl yum whatprovides können Sie das Paket identifizieren, das installiert werden muss, um eine bestimmte Binärdatei bereitzustellen.

yum whatprovides ps

Last metadata expiration check: 0:03:36 ago on Thu Jan 16 14:49:17 2025.
procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : @System
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

procps-ng-3.3.17-1.amzn2023.0.2.x86_64 : System and process monitoring utilities
Repo        : amazonlinux
Matched from:
Filename    : /usr/bin/ps
Provide    : /bin/ps

Ressourcen im Zusammenhang mit dem EKS Auto Mode in der AWS-Konsole anzeigen

Über die AWS-Konsole können Sie den Status der Ressourcen anzeigen, die Ihrem EKS-Auto-Mode-Cluster zugeordnet sind.

Anzeigen von IAM-Fehlern in Ihrem AWS-Konto

Suchen Sie nach Fehlern im Zusammenhang mit Ihrem EKS-Cluster. Verwenden Sie die Fehlermeldungen, um Ihre EKS-Zugriffseinträge, die Cluster-IAM-Rolle oder die Knoten-IAM-Rolle zu aktualisieren. Möglicherweise müssen Sie diesen Rollen eine neue Richtlinie mit Berechtigungen für den EKS-Automodus zuordnen.

Fehlerbehebung bei fehlgeschlagener Pod-Planung in Knoten im Automatikmodus

Wenn Pods im Pending-Status verbleiben und nicht auf einen Automatikmodus-Knoten geplant werden, überprüfen Sie, ob Ihr Pod- oder Bereitstellungs-Manifest ein nodeSelector enthält. Wenn nodeSelector vorhanden ist, stellen Sie sicher, dass eks.amazonaws.com/compute-type: auto verwendet wird, um auf Knoten geplant zu werden, die von EKS Auto Mode erstellt wurden. Weitere Informationen zu den Knotenbezeichnungen, die von EKS Auto Mode verwendet werden, finden Sie unter Überprüfen, ob eine Workload in Knoten von EKS Auto Mode bereitgestellt wird.

Fehlerbehebung für Knoten, die nicht dem Cluster beitreten

EKS Auto Mode konfiguriert neue EC2-Instances automatisch mit den korrekten Informationen für den Beitritt zum Cluster, einschließlich des Cluster-Endpunkts und der Cluster-Zertifizierungsstelle (CA). Es kann jedoch vorkommen, dass diese Instances dennoch nicht als Knoten dem EKS-Cluster beitreten können. Führen Sie die folgenden Befehle aus, um Instances, die nicht dem Cluster beigetreten sind, zu identifizieren:

Gängige Fehlermeldungen:

Erkennung von Problemen mit der Knotenkonnektivität mit VPC Reachability Analyzer

Ein Grund dafür, dass eine Instance dem Cluster nicht beigetreten ist, ist ein Problem mit der Netzwerkkonnektivität, das sie daran hindert, den API-Server zu erreichen. Zur Diagnose dieses Problems können Sie mit dem VPC Reachability Analyzer die Konnektivität zwischen einem Knoten, der dem Cluster nicht beitreten kann, und dem API-Server analysieren. Sie benötigen zwei Informationen:

Um die Instance-ID zu erhalten, müssen Sie eine Workload auf dem Cluster erstellen, damit EKS Auto Mode eine EC2-Instance startet. Dadurch wird auch ein NodeClaim-Objekt in Ihrem Cluster erstellt, das die Instance-ID enthält. Führen Sie kubectl get nodeclaim -o yaml aus, um alle NodeClaims in Ihrem Cluster auszudrucken. Jedes NodeClaim enthält die Instance-ID als Feld und erneut in der providerID:

kubectl get nodeclaim -o yaml

Eine Beispielausgabe sieht wie folgt aus.

    nodeName: i-01234567890123456
    providerID: aws:///us-west-2a/i-01234567890123456

Sie können Ihren Kubernetes-API-Server-Endpunkt ermitteln, indem Sie kubectl get endpoint kubernetes -o yaml ausführen. Die Adressen befinden sich im Adressfeld:

kubectl get endpoints kubernetes -o yaml

Eine Beispielausgabe sieht wie folgt aus.

apiVersion: v1
kind: Endpoints
metadata:
  name: kubernetes
  namespace: default
subsets:
- addresses:
  - ip: 10.0.143.233
  - ip: 10.0.152.17
  ports:
  - name: https
    port: 443
    protocol: TCP

Mit diesen beiden Informationen können Sie die S-Analyse durchführen. Navigieren Sie zunächst zum VPC Reachability Analyzer in AWS-Managementkonsole.

Freigabe von Volumes über Pods hinweg

EKS-Auto-Mode-Knoten werden mit SELinux im Durchsetzungsmodus konfiguriert. Dies bietet eine bessere Isolierung zwischen Pods, die in demselben Knoten ausgeführt werden. Wenn SELinux aktiviert ist, wird den meisten nicht privilegierten Pods automatisch ihr eigenes Multi-Category Security (MCS)-Label zugewiesen. Dieses MCS-Label ist für jeden Pod einzigartig und soll sicherstellen, dass ein Prozess in einem Pod keinen Prozess in einem anderen Pod oder auf dem Host manipulieren kann. Selbst wenn ein gekennzeichneter Pod als Root ausgeführt wird und Zugriff auf das Host-Dateisystem hat, kann er keine Dateien manipulieren, keine vertraulichen Systemaufrufe im Host ausführen, nicht auf die Container-Laufzeitumgebung zugreifen und kein geheimes Schlüsselmaterial von Kubelet abrufen.

Aus diesem Grund können Probleme auftreten, wenn Sie versuchen, Daten zwischen Pods auszutauschen. Beispielsweise erlaubt ein PersistentVolumeClaim mit einem Zugriffsmodus von ReadWriteOnce immer noch nicht, dass mehrere Pods gleichzeitig auf das Volume zugreifen.

Um diese Freigabe zwischen Pods zu ermöglichen, können Sie das seLinuxOptions des Pods verwenden, um auf diesen Pods dasselbe MCS-Label zu konfigurieren. In diesem Beispiel weisen wir dem Pod die drei Kategorien c123,c456,c789 zu. Dies steht nicht im Widerspruch zu den Kategorien, die den Pods auf dem Knoten automatisch zugewiesen werden, da ihnen nur zwei Kategorien zugewiesen werden.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456,c789"

Anzeige von Karpenter-Ereignissen in den Protokollen der Steuerebene

Für EKS-Cluster mit aktivierten Steuerebenen-Protokollen können Sie durch Abfragen der Protokolle Einblicke in die Aktionen und Entscheidungsprozesse von Karpenter gewinnen. Dies kann besonders nützlich sein, um Probleme in EKS Auto Mode im Zusammenhang mit der Bereitstellung, Skalierung und Beendigung von Knoten zu beheben. Um Ereignisse im Zusammenhang mit Karpenter anzuzeigen, verwenden Sie die folgende Abfrage in CloudWatch Logs Insights:

fields @timestamp, @message
| filter @logStream like /kube-apiserver-audit/
| filter @message like 'DisruptionBlocked'
or @message like 'DisruptionLaunching'
or @message like 'DisruptionTerminating'
or @message like 'DisruptionWaitingReadiness'
or @message like 'Unconsolidatable'
or @message like 'FailedScheduling'
or @message like 'NoCompatibleInstanceTypes'
or @message like 'NodeRepairBlocked'
or @message like 'Disrupted'
or @message like 'Evicted'
or @message like 'FailedDraining'
or @message like 'TerminationGracePeriodExpiring'
or @message like 'TerminationFailed'
or @message like 'FailedConsistencyCheck'
or @message like 'InsufficientCapacityError'
or @message like 'UnregisteredTaintMissing'
or @message like 'NodeClassNotReady'
sort @timestamp desc

Diese Abfrage filtert nach bestimmten Karpenter-bezogenen Ereignissen in den Überwachungsprotokollen des Kube-API-Servers. Zu den Ereignissen zählen verschiedene Störungszustände, Planungsfehler, Kapazitätsprobleme und knotenbezogene Probleme. Durch die Analyse dieser Protokolle erhalten Sie ein besseres Verständnis für Folgendes:

So verwenden Sie diese Abfrage:

Die Ergebnisse zeigen Ihnen eine Zeitleiste mit Karpenter-bezogenen Ereignissen, die Ihnen bei der Fehlerbehebung und beim Verständnis des Verhaltens von EKS Auto Mode in Ihrem Cluster behilflich sein können. Um die Aktionen von Karpenter auf einem bestimmten Knoten zu überprüfen, können Sie den folgenden Zeilenfilter mit der Instance-ID zur oben genannten Abfrage hinzufügen:

|filter @message like /[.replaceable]`i-12345678910123456`/

Fehlerbehebung für im Automatikmodus enthaltene Controller

Bei Problemen mit einem Controller sollten Sie Folgendes prüfen:

Zugehörige Ressourcen

Verwenden Sie diese Artikel aus AWS re:Post für erweiterte Schritte zur Fehlerbehebung: