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.

Fehlerbehebung mit EKS Auto Mode

AWS Übernimmt mit dem automatischen Modus von EKS mehr Verantwortung für 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.

Sie müssen Kubernetes verwenden AWS , um Fehler bei Knoten APIs zu beheben. Sie können:

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 Knotenreparatur und Untersuchen von Problemen mit dem Zustand des Knotens.

Rufen Sie mithilfe der AWS EC2 CLI die Konsolenausgabe von einer EC2 verwalteten Instanz ab

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

Zunächst müssen Sie die EC2 Instanz-ID der Instanz ermitteln, die Ihrem Workload zugeordnet ist. Verwenden Sie zweitens die AWS CLI, um die Konsolenausgabe abzurufen.

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

Zeigen Sie die mit dem automatischen Modus von EKS verknüpften Ressourcen in der AWS Konsole an

Sie können die AWS Konsole verwenden, um den Status der Ressourcen anzuzeigen, die Ihrem EKS-Auto-Mode-Cluster zugeordnet sind.

IAM-Fehler in Ihrem AWS Konto anzeigen

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

Der automatische EKS-Modus konfiguriert automatisch neue EC2 Instances mit den richtigen 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 Instanz-ID zu erhalten, müssen Sie einen Workload auf dem Cluster erstellen, damit der automatische Modus von EKS 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

Die EKS-Automodus-Knoten sind SELinux im Modus „Enforcing“ konfiguriert, was für mehr Isolation zwischen Pods sorgt, die auf demselben Knoten ausgeführt werden. Wenn diese Option aktiviert SELinux ist, erhalten die meisten nicht privilegierten Pods automatisch ein eigenes Sicherheitslabel (Multi-Category Security, MCS). 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. Verwenden Sie die folgende Logs Insights-Abfrage, um Ereignisse im Zusammenhang mit Karpenter anzuzeigen: CloudWatch

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

In diesen Artikeln von AWS re:POST finden Sie weitere Schritte zur Fehlerbehebung: