CKA-Selbststudium

Modul 5

Broad Skills bietet eine breite Palette von Beratungsdiensten zu Open Source-Technologien

KONTAKTIERE UNS

CKA Selbststudium Mod 5

In diesem Modul des Online-CKA-Vorbereitungskurses Broad Skills behandeln wir die im CNCF-CKA-Prüfungscurriculum identifizierten Themen zu Clusterarchitektur, Installation und Konfiguration. Wenn Sie mit dem Curriculum noch nicht vertraut sind, nehmen Sie sich einen Moment Zeit, um sich vertraut zu machen, da Sie jedes der Themen kennen müssen, um den Test zu bestehen.

CKA Selbststudium Mod 5

Beheben von Anwendungsfehlern

Anwendungen, die unter Kubernetes ausgeführt werden, werden in Containern innerhalb von Pods ausgeführt. Es gibt mehrere Möglichkeiten, Anwendungsfehler zu beheben:

    Lesen der Protokolle des Anwendungscontainers mithilfe von kubectl-Protokollen Anzeigen von mit dem Pod verknüpften Ereignissen mithilfe von kubectl-Ereignissen Direkte Interaktion mit dem Anwendungscontainer mithilfe von kubectl exec

$ kubectl logs debugapp


2020-02-28 16:05:48 00:00 [Hinweis] [Entrypoint]: Einstiegspunktskript für MySQL Server 1:10.4.12 maria~bionic gestartet.

2020-02-28 16:05:49 00:00 [Anmerkung] [Einstiegspunkt]: Wechsel zum dedizierten Benutzer 'mysql'

2020-02-28 16:05:49 00:00 [Hinweis] [Entrypoint]: Einstiegspunktskript für MySQL Server 1:10.4.12 maria~bionic gestartet.

2020-02-28 16:05:49 00:00 [ERROR] [Entrypoint]: Datenbank ist nicht initialisiert und Passwortoption ist nicht angegeben

Sie müssen eines von MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD und MYSQL_RANDOM_ROOT_PASSWORD angeben


$

Fehler bei Steuerungsebenenfehlern beheben

Komponenten der Steuerungsebene wie kube-apiserver, kube-scheduler, etcd und kube-controllermanager werden alle in statischen Pods in einem kubeadm-bootstrapped-Cluster ausgeführt. Manifeste der Komponenten der Steuerungsebene befinden sich im statischen Pfadverzeichnis kubelet des Master-Knotens. Der Standardwert ist: /etc/kubernetes/manifests . Da die Komponenten der Steuerungsebene in einem Cluster als Pods ausgeführt werden, bieten kubectl-Protokolle und kubectl-Ereignisse Einblicke in alle Aktivitäten und mögliche Probleme, mit denen diese Komponenten der Steuerungsebene konfrontiert sind. In Clustern, in denen Komponenten der Steuerungsebene als Daemons auf Systemebene ausgeführt werden, bietet die Verwendung von systemctl und journalctl denselben Ansatz.

$ kubectl logs -n kube-system kube-scheduler-$(hostname)


I0225 19:54:25.957861 1 Serving.go:312] Generiertes selbstsigniertes Zertifikat im Speicher

W0225 19:54:26.142234 1 configmap_cafile_content.go:102] kann das anfängliche CA-Bundle für: "client-ca::kube-system::extension-apiserver-authentication::client-ca-file" nicht laden wegen: configmap " Erweiterung-Apiserver-Authentifizierung" nicht gefunden

W0225 19:54:26.142423 1 configmap_cafile_content.go:102] kann das anfängliche CA-Bundle für: "client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file" nicht laden aufgrund von: configmap "extension-apiserver-authentication" nicht gefunden

W0225 19:54:26.157329 1 authorisation.go:47] Autorisierung ist deaktiviert

W0225 19:54:26.157413 1 authentication.go:92] Authentifizierung ist deaktiviert

I0225 19:54:26.157435 1 deprecated_insecure_serving.go:51] Serving healthz unsicher auf [::]:10251

I0225 19:54:26.159618 1 configmap_cafile_content.go:205] Starten von client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file

I0225 19:54:26.159658 1 shared_informer.go:197] Warten auf Synchronisierung der Caches für client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file

I0225 19:54:26.159628 1 secure_serving.go:178] Serving sicher auf 127.0.0.1:10259


$

Fehlerbehebung bei Worker-Knotenfehlern

Ein Knoten, der Pods in einem Kubernetes-Cluster ausführt, wird durch ein Kubelet dargestellt. Jedes Kubelet benötigt eine Container-Laufzeit (wie Docker), um Container auszuführen. Da die Kubelet- und Container-Laufzeit als Systemagenten ausgeführt werden, müssen Sie Tools auf Hostebene wie systemctl oder journalctl verwenden, um deren Protokolle anzuzeigen.

$ sudo systemctl status kubelet


● kubelet.service - kubelet: Der Kubernetes-Knotenagent

Geladen: geladen (/lib/systemd/system/kubelet.service; aktiviert; Herstellervoreinstellung: aktiviert)

Drop-In: /etc/systemd/system/kubelet.service.d

└─10-kubeadm.conf

Aktiv: aktivierend (automatischer Neustart) (Ergebnis: Exit-Code) seit Fr 2020-02-28 08:08:03 PST; vor 8s

Dokumente: https://kubernetes.io/docs/home/

Prozess: 2175 ExecStart = /usr/bin/kubelet $ KUBELET_KUBECONFIG_ARGS $ KUBELET_CONFIG_ARGS $ KUBELET_KUBE

Haupt-PID: 2175 (Code=beendet, Status=255)


28.02.2018 08:08:03 labsys systemd[1]: kubelet.service: Hauptprozess beendet, code=beendet, status=255/n/a

28. Feb. 08:08:03 labsys systemd[1]: kubelet.service: Einheit in den Fehlerzustand eingetreten.

28. Feb 08:08:03 labsys systemd[1]: kubelet.service: Fehler mit Ergebnis 'exit-code'.


$ journalctl -u kubelet | Schwanz -5


28. Feb. 08:09:15 labsys kubelet[2771]: I0228 08:09:15.417176 2771 server.go:641] --cgroups-per-qos aktiviert, aber --cgroup-root wurde nicht angegeben. standardmäßig auf /

28. Feb. 08:09:15 labsys kubelet[2771]: F0228 08:09:15.417372 2771 server.go:273] Kubelet konnte nicht ausgeführt werden: Ausführung mit aktiviertem Swap wird nicht unterstützt, bitte deaktivieren Sie Swap! oder setzen Sie das Flag --fail-swap-on auf false. /proc/swaps enthalten: [Dateiname Typ Verwendete Größe Priorität /dev/dm-1 Partition 4194300 0 -1]

28.02.2018 08:09:15 labsys systemd[1]: kubelet.service: Hauptprozess beendet, code=exited, status=255/n/a

28. Feb. 08:09:15 labsys systemd[1]: kubelet.service: Einheit in den Fehlerzustand eingetreten.

28. Feb 08:09:15 labsys systemd[1]: kubelet.service: Fehler mit Ergebnis 'exit-code'.


$

Kubelets (und damit Worker-Knoten) benötigen funktionale Container-Laufzeiten, um Pods zu betreiben. Bei Standardinstallationen muss auch der System-Swap deaktiviert sein.

Netzwerkfehler beheben

Jeder Pod, der in einem Kubernetes-Cluster ausgeführt wird, muss eine eigene IP-Adresse haben. Pods erhalten ihre eindeutigen IPs vom Cluster Container Network Interface (CNI)-Plug-in. Um ein CNI-Plugin richtig zu verwenden, muss jedes Kubelet so konfiguriert sein, dass es CNI-Plugins in seinem systemd-Dienst erwartet.


Ohne funktionsfähiges CNI kann das Kubelet das Netzwerk der Container-Laufzeit nicht konfigurieren und meldet dem Cluster keinen „Bereit“-Status:

$ sudo systemctl status kubelet


● kubelet.service - kubelet: Der Kubernetes-Knotenagent

Geladen: geladen (/lib/systemd/system/kubelet.service; aktiviert; Herstellervoreinstellung: aktiviert)

Drop-In: /etc/systemd/system/kubelet.service.d

└─10-kubeadm.conf

Aktiv: aktiv (läuft) seit Fr. 2020-02-28 08:50:27 PST; vor 5min

Dokumente: https://kubernetes.io/docs/home/

Haupt-PID: 19302 (Würfel)

Aufgaben: 16 (Limit: 512)

Speicher: 45,2 M

CPU: 3.761s

CGroup: /system.slice/kubelet.service

└─19302 / usr / bin / kubelet --bootstrap-kubeconfig = / etc / kubernetes / bootstrap-kubelet.conf --kubeconfig = / etc / kubernetes / kubelet.conf --config = / var / lib / kubelet / config. yaml --cgroup-driver = cgroupfs


28. Feb. 08:55:58 labsys kubelet[19302]: E0228 08:55:58.668145 19302 kubelet.go:2183] Container-Laufzeitnetzwerk nicht bereit: NetworkReady=false Grund:NetworkPluginNotReady message:docker: network plugin i

28. Feb. 08:56:02 labsys kubelet[19302]: W0228 08:56:02.452412 19302 cni.go:237] cni-Konfiguration kann nicht aktualisiert werden: keine Netzwerke in /etc/cni/net.d . gefunden


$


28. Feb. 08:09:15 labsys kubelet[2771]: I0228 08:09:15.417176 2771 server.go:641] --cgroups-per-qos aktiviert, aber --cgroup-root wurde nicht angegeben. standardmäßig auf /

28. Feb. 08:09:15 labsys kubelet[2771]: F0228 08:09:15.417372 2771 server.go:273] Kubelet konnte nicht ausgeführt werden: Ausführung mit aktiviertem Swap wird nicht unterstützt, bitte deaktivieren Sie Swap! oder setzen Sie das Flag --fail-swap-on auf false. /proc/swaps enthalten: [Dateiname Typ Verwendete Größe Priorität /dev/dm-1 Partition 4194300 0 -1]

28.02.2018 08:09:15 labsys systemd[1]: kubelet.service: Hauptprozess beendet, code=exited, status=255/n/a

28. Feb. 08:09:15 labsys systemd[1]: kubelet.service: Einheit in den Fehlerzustand eingetreten.

28. Feb 08:09:15 labsys systemd[1]: kubelet.service: Fehler mit Ergebnis 'exit-code'.


$

Andere Symptome eines nicht funktionierenden oder falsch konfigurierten CNI-Plugins sind:

    Pods, die eine lokale Docker-IP erhalten. Neue Pods bleiben in der ContainerCreating-Phase, auch wenn das Image abgerufen wird

Andere Netzwerkfehler können Faktoren innerhalb der zugrunde liegenden Infrastruktur des Clusters betreffen, wie beispielsweise Firewallregeln oder vollständige Netzwerkpartitionen, die die Kommunikation verhindern.

Übungsübung

Führen Sie den folgenden Befehl aus. Dieser Befehl startet einen Pod, der nicht ausgeführt wird:

kubectl run --restart Never --image redis:0.2 redispod

Rufen Sie die mit diesem Pod verknüpften Ereignisse (in beliebiger Reihenfolge aufgelistet) ab und schreiben Sie sie in eine Datei: /tmp/troubleshooting-answer.txt

  • Übungsübung: Antwort

    Führen Sie zuerst den Befehl aus:

Kurse

150

Lernende

50k

Sportschuhe

46

Aktionspreis

90%

  • Wie wir auf Covid-19 reagieren

    In diesen schwierigen Zeiten bleibt Broad Skills voll funktionsfähig. Wir engagieren uns für den Erfolg unserer Kunden und halten die Weltwirtschaft in Bewegung. Alle unsere Kurse und Beratungsdienste sind virtuell verfügbar und wir sind bereit, die Bedürfnisse unserer Kunden weltweit durch Fernunterricht und Videokonferenzen zu unterstützen.

Wir sind Technologieexperten und bieten eine umfassende Palette von Schulungsdienstleistungen, die

Fordern Sie nicht nur Ihren Verstand heraus, sondern geben Sie Ihnen auch beruflich erforderliche Fähigkeiten, die Sie in die Pole-Position versetzen, um weitgehend zum Erfolg und Wachstum Ihres Unternehmens beizutragen.

Stephen Brown

Ausbilder, BroadSkills

Share by: