Ein visueller Leitfaden zur Fehlerbehebung bei Kubernetes

Notiz. übersetzen: Dieser Artikel ist Teil der öffentlich zugänglichen Projektmaterialien learnk8s, Schulung von Unternehmen und einzelnen Administratoren für die Arbeit mit Kubernetes. Darin gibt Daniele Polencic, Projektmanager, visuelle Anweisungen, welche Schritte bei allgemeinen Problemen mit Anwendungen, die auf dem K8s-Cluster laufen, zu unternehmen sind.

TL;DR: Hier ist ein Diagramm, das Ihnen beim Debuggen der Bereitstellung in Kubernetes hilft:

Flussdiagramm zum Finden und Beheben von Fehlern in einem Cluster. Das Original (auf Englisch) ist verfügbar unter PDF и als Bild.

Wenn Sie eine Anwendung auf Kubernetes bereitstellen, müssen Sie normalerweise drei Komponenten definieren:

• Einsatz - Dies ist eine Art Rezept zum Erstellen von Kopien der Anwendung, sogenannten Pods;
• Service – interner Load Balancer, der den Datenverkehr auf Pods verteilt;
• Eintritt – eine Beschreibung, wie der Datenverkehr von der Außenwelt zum Dienst gelangt.

Hier ist eine kurze grafische Zusammenfassung:

1) In Kubernetes empfangen Anwendungen Datenverkehr von der Außenwelt über zwei Ebenen von Load Balancern: intern und extern.

2) Der interne Balancer heißt Service, der externe heißt Ingress.

3) Die Bereitstellung erstellt Pods und überwacht sie (sie werden nicht manuell erstellt).

Nehmen wir an, Sie möchten eine einfache Anwendung a la bereitstellen Hallo Welt. Die YAML-Konfiguration dafür sieht folgendermaßen aus:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

Die Definition ist ziemlich lang und es kann leicht zu Verwirrung darüber kommen, in welcher Beziehung die Komponenten zueinander stehen.

Zum Beispiel:

• Wann sollten Sie Port 80 und wann 8080 verwenden?
• Sollte ich für jeden Dienst einen neuen Port erstellen, damit es nicht zu Konflikten kommt?
• Sind Labelnamen wichtig? Sollten sie überall gleich sein?

Bevor wir uns auf das Debuggen konzentrieren, erinnern wir uns daran, wie die drei Komponenten zueinander in Beziehung stehen. Beginnen wir mit Bereitstellung und Service.

Beziehung zwischen Bereitstellung und Service

Sie werden überrascht sein, aber Bereitstellung und Service hängen in keiner Weise zusammen. Stattdessen verweist der Dienst direkt auf Pods und umgeht die Bereitstellung.

Daher interessiert uns, wie Pods und Dienste miteinander zusammenhängen. Drei Dinge, die Sie beachten sollten:

1. Auswahl (selector) für den Dienst muss mit mindestens einem Pod-Label übereinstimmen.
2. targetPort muss passen containerPort Behälter im Pod.
3. port Service kann alles sein. Verschiedene Dienste können denselben Port verwenden, da sie unterschiedliche IP-Adressen haben.

Das folgende Diagramm stellt alle oben genannten Punkte in grafischer Form dar:

1) Stellen Sie sich vor, der Dienst leitet den Datenverkehr an einen bestimmten Pod weiter:

2) Beim Erstellen eines Pods müssen Sie angeben containerPort für jeden Behälter in Pods:

3) Beim Erstellen eines Dienstes müssen Sie angeben port и targetPort. Aber welches dient zur Verbindung mit dem Container?

4) Über targetPort. Es muss passen containerPort.

5) Nehmen wir an, Port 3000 ist im Container geöffnet. Dann der Wert targetPort sollte gleich sein.

In der YAML-Datei sind Labels und ports / targetPort muss passen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

Was ist mit dem Etikett? track: canary oben im Abschnitt „Bereitstellung“? Sollte es passen?

Diese Bezeichnung ist einsatzspezifisch und wird vom Dienst nicht zum Weiterleiten des Datenverkehrs verwendet. Mit anderen Worten: Es kann entfernt oder ein anderer Wert zugewiesen werden.

Was ist mit dem Selektor? matchLabels?

Es muss immer mit den Beschriftungen des Pods übereinstimmen, da es vom Deployment zum Verfolgen von Pods verwendet wird.

Nehmen wir an, Sie haben die richtigen Änderungen vorgenommen. Wie kann man sie überprüfen?

Sie können das Pod-Label mit dem folgenden Befehl überprüfen:

kubectl get pods --show-labels

Oder, wenn Pods zu mehreren Anwendungen gehören:

kubectl get pods --selector any-name=my-app --show-labels

Wo any-name=my-app ist ein Etikett any-name: my-app.

Gibt es noch Schwierigkeiten?

Sie können sich mit dem Pod verbinden! Dazu müssen Sie den Befehl verwenden port-forward in kubectl. Damit können Sie eine Verbindung zum Dienst herstellen und die Verbindung überprüfen.

kubectl port-forward service/<service name> 3000:80

Hier:

• service/<service name> - Dienstname; in unserem Fall ist es so my-service;
• 3000 ist der Port, der auf dem Computer geöffnet werden muss;
• 80 - im Feld angegebener Port port Service.

Wenn die Verbindung hergestellt wurde, sind die Einstellungen korrekt.

Wenn die Verbindung fehlschlägt, liegt ein Problem mit den Bezeichnungen vor oder die Ports stimmen nicht überein.

Beziehung zwischen Dienst und Ingress

Der nächste Schritt bei der Bereitstellung des Zugriffs auf die Anwendung besteht in der Einrichtung von Ingress. Ingress muss wissen, wie man einen Dienst findet, dann Pods findet und den Datenverkehr dorthin leitet. Ingress findet den erforderlichen Dienst anhand des Namens und des offenen Ports.

In der Beschreibung von Ingress und Service müssen zwei Parameter übereinstimmen:

1. servicePort in Ingress muss mit dem Parameter übereinstimmen port im Dienst;
2. serviceName in Ingress muss mit dem Feld übereinstimmen name im Dienst.

Das folgende Diagramm fasst die Portverbindungen zusammen:

1) Wie Sie bereits wissen, hört der Service einem gewissen zu port:

2) Ingress hat einen Parameter namens servicePort:

3) Dieser Parameter (servicePort) muss immer übereinstimmen port in der Service-Definition:

4) Wenn im Service Port 80 angegeben ist, ist dies erforderlich servicePort war auch gleich 80:

In der Praxis müssen Sie auf folgende Zeilen achten:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

Wie überprüfe ich, ob Ingress ausgeführt wird?

Sie können die Methode mit verwenden kubectl port-forward, aber anstelle des Dienstes müssen Sie eine Verbindung zum Ingress-Controller herstellen.

Zuerst müssen Sie den Namen des Pods mit dem Ingress-Controller herausfinden:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Suchen Sie den Ingress-Pod (er befindet sich möglicherweise in einem anderen Namespace) und führen Sie den Befehl aus describeUm die Portnummern herauszufinden:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

Stellen Sie abschließend eine Verbindung zum Pod her:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Jedes Mal, wenn Sie nun eine Anfrage an Port 3000 Ihres Computers senden, wird diese mit dem Ingress-Controller an Port 80 des Pods weitergeleitet. Indem man geht http://localhost:3000, sollten Sie die von der Anwendung generierte Seite sehen.

Zusammenfassung der Häfen

Erinnern wir uns noch einmal daran, welche Ports und Labels übereinstimmen müssen:

1. Der Selektor in der Dienstdefinition muss mit der Bezeichnung des Pods übereinstimmen;
2. targetPort in der Definition Service muss übereinstimmen containerPort Behälter in einer Kapsel;
3. port In der Definition kann Service alles sein. Verschiedene Dienste können denselben Port verwenden, da sie unterschiedliche IP-Adressen haben.
4. servicePort Der Eingang muss übereinstimmen port in der Definition von Service;
5. Der Dienstname muss mit dem Feld übereinstimmen serviceName im Ingress.

Leider reicht es nicht aus, zu wissen, wie man eine YAML-Konfiguration richtig strukturiert.

Was passiert, wenn etwas schief geht?

Der Pod startet möglicherweise nicht oder stürzt ab.

3 Schritte zur Diagnose von Anwendungsproblemen in Kubernetes

Bevor Sie mit dem Debuggen Ihrer Bereitstellung beginnen, müssen Sie ein gutes Verständnis der Funktionsweise von Kubernetes haben.

Da jede in K8s heruntergeladene Anwendung aus drei Komponenten besteht, sollten diese in einer bestimmten Reihenfolge, von ganz unten beginnend, debuggt werden.

1. Zuerst müssen Sie sicherstellen, dass die Pods funktionieren, dann ...
2. Überprüfen Sie, ob der Dienst Datenverkehr an die Pods liefert, und dann ...
3. Überprüfen Sie, ob Ingress richtig konfiguriert ist.

Visuelle Darstellung:

1) Sie sollten ganz unten mit der Suche nach Problemen beginnen. Überprüfen Sie zunächst, ob Pods Status haben Ready и Running:

2) Wenn die Pods fertig sind (Ready), sollten Sie herausfinden, ob der Dienst den Datenverkehr zwischen Pods verteilt:

3) Abschließend müssen Sie die Verbindung zwischen dem Dienst und dem Ingress analysieren:

1. Diagnose von Pods

In den meisten Fällen hängt das Problem mit dem Pod zusammen. Stellen Sie sicher, dass die Pods als aufgelistet sind Ready и Running. Sie können dies mit dem Befehl überprüfen:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

In der obigen Befehlsausgabe wird der letzte Pod als aufgeführt Running и ReadyBei den anderen beiden ist dies jedoch nicht der Fall.

Wie kann man verstehen, was schief gelaufen ist?

Es gibt vier nützliche Befehle zum Diagnostizieren von Pods:

1. kubectl logs <имя pod'а> ermöglicht das Extrahieren von Protokollen aus Containern in einem Pod;
2. kubectl describe pod <имя pod'а> ermöglicht Ihnen, eine Liste der mit dem Pod verbundenen Ereignisse anzuzeigen;
3. kubectl get pod <имя pod'а> ermöglicht es Ihnen, die YAML-Konfiguration eines in Kubernetes gespeicherten Pods abzurufen;
4. kubectl exec -ti <имя pod'а> bash ermöglicht es Ihnen, eine interaktive Befehlsshell in einem der Pod-Container zu starten

Welches sollten Sie wählen?

Tatsache ist, dass es keinen universellen Befehl gibt. Es sollte eine Kombination davon verwendet werden.

Typische Pod-Probleme

Es gibt zwei Haupttypen von Pod-Fehlern: Startfehler und Laufzeitfehler.

Startfehler:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

Laufzeitfehler:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

Einige Fehler treten häufiger auf als andere. Hier sind einige der häufigsten Fehler und wie man sie behebt.

ImagePullBackOff

Dieser Fehler tritt auf, wenn Kubernetes kein Image für einen der Pod-Container abrufen kann. Hier sind die drei häufigsten Gründe dafür:

1. Der Name des Bildes ist falsch – Sie haben beispielsweise einen Fehler darin gemacht oder das Bild existiert nicht;
2. Für das Bild wurde ein nicht vorhandenes Tag angegeben;
3. Das Image wird in einer privaten Registry gespeichert und Kubernetes hat keine Berechtigung, darauf zuzugreifen.

Die ersten beiden Gründe lassen sich leicht beseitigen – korrigieren Sie einfach den Bildnamen und das Tag. Im letzteren Fall müssen Sie in Secret Anmeldeinformationen für die geschlossene Registry eingeben und in Pods Links dazu hinzufügen. In der Kubernetes-Dokumentation es gibt ein Beispiel wie das gemacht werden kann.

Crash-Loop-Backoff

Kubenetes gibt einen Fehler aus CrashLoopBackOff, wenn der Container nicht starten kann. Dies geschieht normalerweise, wenn:

1. Es gibt einen Fehler in der Anwendung, der den Start verhindert;
2. Behälter falsch konfiguriert;
3. Der Lebendigkeitstest ist zu oft fehlgeschlagen.

Sie müssen versuchen, auf die Protokolle des Containers zuzugreifen, um den Grund für den Fehler herauszufinden. Wenn der Zugriff auf die Protokolle schwierig ist, weil der Container zu schnell neu startet, können Sie den folgenden Befehl verwenden:

kubectl logs <pod-name> --previous

Es werden Fehlermeldungen der vorherigen Inkarnation des Containers angezeigt.

RunContainerError

Dieser Fehler tritt auf, wenn der Container nicht gestartet werden kann. Es entspricht dem Moment vor dem Start der Anwendung. Die Ursache liegt meist in falschen Einstellungen, zum Beispiel:

• Versuch, ein nicht vorhandenes Volume wie ConfigMap oder Secrets bereitzustellen;
• ein Versuch, ein schreibgeschütztes Volume als Lese-/Schreibzugriff bereitzustellen.

Das Team ist gut geeignet, solche Fehler zu analysieren kubectl describe pod <pod-name>.

Pods befinden sich im Status „Ausstehend“.

Nach der Erstellung bleibt der Pod in diesem Zustand Pending.

Warum passiert das?

Hier sind die möglichen Gründe (ich gehe davon aus, dass der Planer einwandfrei funktioniert):

1. Der Cluster verfügt nicht über genügend Ressourcen wie Rechenleistung und Arbeitsspeicher, um den Pod auszuführen.
2. Das Objekt wird im entsprechenden Namespace installiert ResourceQuota und das Erstellen eines Pods führt dazu, dass der Namespace das Kontingent überschreitet.
3. Der Pod ist an „Ausstehend“ gebunden PersistentVolumeClaim.

In diesem Fall empfiehlt sich die Verwendung des Befehls kubectl describe und überprüfen Sie den Abschnitt Events:

kubectl describe pod <pod name>

Im Falle von Fehlern im Zusammenhang mit ResourceQuotas, wird empfohlen, die Clusterprotokolle mit dem Befehl anzuzeigen

kubectl get events --sort-by=.metadata.creationTimestamp

Pods sind nicht bereit

Wenn Pod als aufgeführt ist Running, befindet sich aber nicht in einem Zustand Ready, bedeutet, seine Bereitschaft zu überprüfen (Bereitschaftssonde) scheitert.

In diesem Fall stellt der Pod keine Verbindung zum Dienst her und es fließt kein Datenverkehr dorthin. Der Fehler beim Bereitschaftstest wird durch Probleme in der Anwendung verursacht. In diesem Fall müssen Sie den Abschnitt analysieren, um den Fehler zu finden Events in der Befehlsausgabe kubectl describe.

2. Servicediagnose

Wenn Pods aufgeführt sind als Running и Ready, die Anwendung aber immer noch nicht antwortet, sollten Sie die Diensteinstellungen überprüfen.

Dienste sind für die Weiterleitung des Datenverkehrs an Pods abhängig von ihren Labels verantwortlich. Daher müssen Sie zunächst prüfen, wie viele Pods mit dem Dienst funktionieren. Dazu können Sie die Endpunkte im Dienst überprüfen:

kubectl describe service <service-name> | grep Endpoints

Endpunkt ist ein Wertepaar der Form <IP-адрес:порт>, und mindestens ein solches Paar muss in der Ausgabe vorhanden sein (d. h. mindestens ein Pod funktioniert mit dem Dienst).

Wenn Abschnitt Endpoins leer, zwei Optionen sind möglich:

1. es gibt keine Pods mit der richtigen Bezeichnung (Hinweis: Überprüfen Sie, ob der Namespace richtig ausgewählt ist);
2. Es liegt ein Fehler in den Serviceetiketten im Selektor vor.

Wenn Sie eine Liste mit Endpunkten sehen, aber immer noch nicht auf die Anwendung zugreifen können, liegt wahrscheinlich ein Fehler darin targetPort in der Leistungsbeschreibung.

Wie überprüfe ich die Funktionalität des Dienstes?

Unabhängig von der Art des Dienstes können Sie den Befehl verwenden kubectl port-forward um eine Verbindung herzustellen:

kubectl port-forward service/<service-name> 3000:80

Hier:

• <service-name> - Dienstname;
• 3000 ist der Port, den Sie auf dem Computer öffnen;
• 80 - Port auf der Serviceseite.

3. Ingress-Diagnose

Wenn Sie bis hierhin gelesen haben, dann:

• Pods werden aufgeführt als Running и Ready;
• Der Dienst verteilt den Datenverkehr erfolgreich auf Pods.

Sie können die App jedoch immer noch nicht erreichen.

Dies bedeutet, dass der Ingress-Controller höchstwahrscheinlich nicht richtig konfiguriert ist. Da es sich beim Ingress-Controller um eine Drittanbieterkomponente im Cluster handelt, gibt es je nach Typ unterschiedliche Debugging-Methoden.

Bevor Sie jedoch auf spezielle Tools zur Konfiguration von Ingress zurückgreifen, können Sie etwas ganz Einfaches tun. Ingress-Nutzungen serviceName и servicePort um eine Verbindung zum Dienst herzustellen. Sie müssen überprüfen, ob sie richtig konfiguriert sind. Sie können dies mit dem Befehl tun:

kubectl describe ingress <ingress-name>

Wenn-Spalte Backend leer ist, besteht eine hohe Wahrscheinlichkeit eines Konfigurationsfehlers. Wenn die Backends vorhanden sind, die Anwendung aber immer noch nicht zugänglich ist, kann das Problem folgende Ursachen haben:

• Einstellungen für die Zugänglichkeit von Ingress aus dem öffentlichen Internet;
• Cluster-Zugänglichkeitseinstellungen aus dem öffentlichen Internet.

Sie können Probleme mit der Infrastruktur erkennen, indem Sie eine direkte Verbindung zum Ingress-Pod herstellen. Suchen Sie dazu zunächst den Ingress Controller-Pod (er befindet sich möglicherweise in einem anderen Namespace):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Verwenden Sie den Befehl describeSo stellen Sie den Port ein:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

Stellen Sie abschließend eine Verbindung zum Pod her:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Jetzt werden alle Anfragen an Port 3000 auf dem Computer an Port 80 des Pods umgeleitet.

Funktioniert es jetzt?

• Wenn ja, dann liegt das Problem bei der Infrastruktur. Es ist notwendig, genau herauszufinden, wie der Verkehr zum Cluster weitergeleitet wird.
• Wenn nicht, liegt das Problem beim Ingress-Controller.

Wenn Sie den Ingress-Controller nicht zum Laufen bringen können, müssen Sie ihn debuggen.

Es gibt viele Arten von Ingress-Controllern. Am beliebtesten sind Nginx, HAProxy, Traefik usw. (Weitere Informationen zu vorhandenen Lösungen finden Sie unter unsere Bewertung - ca. übersetzt) Weitere Informationen finden Sie in der Fehlerbehebungsanleitung in der entsprechenden Controller-Dokumentation. Weil das Ingress Nginx der beliebteste Ingress-Controller ist, haben wir in den Artikel einige Tipps aufgenommen, um damit verbundene Probleme zu lösen.

Debuggen des Ingress-Nginx-Controllers

Das Ingress-nginx-Projekt hat einen offiziellen Plugin für kubectl. Team kubectl ingress-nginx kann verwendet werden für:

• Analyse von Protokollen, Backends, Zertifikaten usw.;
• Verbindungen zu Ingress;
• Studieren der aktuellen Konfiguration.

Die folgenden drei Befehle helfen Ihnen dabei:

• kubectl ingress-nginx lint - Schecks nginx.conf;
• kubectl ingress-nginx backend – erkundet das Backend (ähnlich wie kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs – überprüft die Protokolle.

Beachten Sie, dass Sie in einigen Fällen möglicherweise mithilfe des Flags den richtigen Namespace für den Ingress-Controller angeben müssen --namespace <name>.

Zusammenfassung

Die Fehlerbehebung bei Kubernetes kann eine Herausforderung sein, wenn Sie nicht wissen, wo Sie anfangen sollen. Sie sollten das Problem immer von unten nach oben angehen: Beginnen Sie mit den Pods und gehen Sie dann zum Dienst und zum Ingress über. Die in diesem Artikel beschriebenen Debugging-Techniken können auf andere Objekte angewendet werden, wie zum Beispiel:

• Leerlaufjobs und CronJobs;
• StatefulSets und DaemonSets.

Ich drücke meine Dankbarkeit aus Gergely Risko, Daniel Weibel и Charles Christyraj für wertvolle Kommentare und Ergänzungen.

PS vom Übersetzer

Lesen Sie auch auf unserem Blog:

• «kubectl-debug-Plugin zum Debuggen in Kubernetes-Pods";
• «6 unterhaltsame Systemfehler im Betrieb von Kubernetes [und ihre Lösung]";
• «Tools für Entwickler von Anwendungen, die auf Kubernetes ausgeführt werden";
• «6 praktische Geschichten aus unserem SRE-Alltag ".

Source: habr.com