Marken

Trainingskategorien

Microsoft-Technik

Microsoft-Endbenutzer

CKAd-Selbststudium

Modul 2

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

KONTAKTIERE UNS

CKAD Selbststudium Mod 2

In diesem Modul des Online-CKAD-Vorbereitungskurses Broad Skills behandeln wir die Kernkonzepte und Konfigurationsthemen, die im CNCF CKAD-Prüfungscurriculum identifiziert wurden. Wenn Sie mit dem Lehrplan noch nicht vertraut sind, nehmen Sie sich einen Moment Zeit, um sich vertraut zu machen, da Sie Ihr Wissen zu jedem Thema nachweisen müssen, um die Prüfung zu bestehen.

ckaD Selbststudienmodule

Multi-Container-Pods

Ein Pod kann einen oder mehrere Container ausführen. Multi-Container-Pods sind eng gekoppelt, indem die Container gemeinsam platziert und geplant werden und die Container dieselben Netzwerk-, uts- und ipc-Namespaces verwenden. Es gibt drei Muster von Multi-Container-Pods:

Sidecar - Sidecar-Container erweitern und verbessern den „Haupt“-Container im Pod. Das Diagramm unten zeigt einen Webserver-Container, der seine Protokolle in einem freigegebenen Dateisystem speichert. Der Log-Save-Sidecar-Container sendet die Logs des Webservers an einen Log-Aggregator.

Ambassador – Botschafter-Container stellen die lokale Verbindung eines Pods zur Außenwelt her. Das Diagramm zeigt einen Redis-Cluster mit drei Knoten (1, 2, 3). Der Botschafter-Container ist ein Proxy, der die entsprechenden Lese- und Schreibvorgänge vom Hauptanwendungscontainer an den Redis-Cluster sendet. Der Hauptanwendungscontainer ist so konfiguriert, dass er eine Verbindung zu einem lokalen Redis-Server herstellt, da die beiden Container denselben uts-Namespace verwenden.

Adapter - Adaptercontainer standardisieren und normalisieren die Ausgabe für Fernüberwachungssysteme, die Standarddatenformate erfordern. Das Diagramm unten zeigt einen Monitoring-Adapter-Container, auf dem ein Agent ausgeführt wird, der die Daten der Hauptanwendung liest, sie verarbeitet und dann die normalisierten Daten an andere Monitoring-Systeme im Netzwerk exportiert.

Ein Multi-Container-Pod wird erstellt, indem ein oder mehrere zusätzliche Containereinträge in einem Pod-Manifest angegeben werden. Unten sehen Sie ein Beispiel für einen Multi-Container-Pod mit einem nginx-Hauptcontainer und einem Fluent-Bit-Container-Sidecar in yaml. Der nginx-Container schreibt seine Protokolle in eine Datei unter /tmp/nginx/ , die von allen Containern im Pod gemeinsam genutzt wird. Der Fluent-Bit-Container liest die Datei aus dem freigegebenen Verzeichnis und gibt sie auf seiner eigenen Standardausgabe aus.

apiVersion: v1

Art: Pod

Metadaten:

Name: Beiwagen

spezifikation:

Behälter:

- Name: nginx

Bild: nginx:neueste

volumeMounts:

- Name: shared-vol

mountPfad: /tmp/nginx/

Befehl:

- /bin/sh

- -C

-nginx -g 'Daemon aus;' > /tmp/nginx/nginx.log

- Name: Adapter

Bild: fließend/fließend-bit

Befehl:

- /fließend-bit/bin/fließend-bit

- -ich

- Schwanz

- -P

- path=/nginx/nginx.log

- -Ö

- stdout

volumeMounts:

- Name: shared-vol

mountPfad: /nginx

Bände:

- Name: shared-vol

leerDir: {}

restartPolicy: OnFailure

Lebendigkeitssonden und Bereitschaftssonden

Ein Liveness-Test ist eine Zustandsprüfung, die einem Kubelet mitteilt, wann ein Container neu gestartet werden soll. Liveness-Prüfungen helfen, Sperren abzufangen, wenn eine Anwendung ausgeführt zu werden scheint, aber nicht fortgesetzt werden kann. Die Implementierung eines Liveness-Probes in einer Bereitstellung ist ein Anfang für die Erstellung einer selbstheilenden Anwendung.

Eine Anwendung ist möglicherweise nicht sofort bereit, Datenverkehr zu akzeptieren, wenn ihr Container zum ersten Mal gestartet wird. Ein Readiness-Probe informiert Kubernetes, wenn es in Ordnung ist, nach dem Booten Datenverkehr an einen Container zu senden. Beispielsweise kann das Laden eines Containers einer Java-Anwendung Minuten dauern und möglicherweise erst dann Datenverkehr annehmen, wenn er vollständig ausgeführt wird. In diesem Szenario verringert die Bereitschaftsprüfung lange Ladezeiten.

Es gibt drei Optionen für Lebendigkeits- und Bereitschaftsprüfungen:

exec - nimmt einen Befehl an, ein Exit-Code von 0 ist erfolgreichhttpGet - führt ein http-Get durch, ein 200-399-Status ist goodtcpSocket - eine erfolgreiche Verbindung zu einem angegebenen Port ist erfolgreich

Aktivitäts- und Bereitschaftstests werden für jeden Container in einem Pod ähnlich konfiguriert. Das folgende Pod-Manifest enthält beispielsweise eine nginx . Container mit einem Liveness-Probe, der ein HTTP-Get zum Root-Pfad zu Port 80 ausführt. Wenn der nginx-Webserver mit einem 200 - 399-Code antwortet, ist der Pod aktiv. Die Lebendigkeitssonde wartet 10 Sekunden vor der ersten Überprüfung und überprüft regelmäßig alle 20 Sekunden. Konto::

apiVersion: v1

Art: Pod

Metadaten:

Name: ready-pod

Etiketten:

App: Ready-Pod

spezifikation:

Behälter:

- Name: nginx

Bild: nginx:neueste

livenessProbe:

httpGet:

Weg: /

Hafen: 80

initialDelaySeconds: 10

ZeitraumSekunden: 20

Container-Logging

Kubernetes ruft Container-Logs aus der Standardausgabe und den Standardfehlerstreams eines Containers ab. Die im Container ausgeführten Anwendungen müssen ihre Protokolle an einen Ort ausgeben, der von der Container-Protokollierungs-Engine gelesen wird (normalerweise STDOUT).

Sie können Container-Logs mit dem Befehl kubectl logs pod_name abrufen. Wenn der Pod ein Multi-Container-Pod ist, muss der Container mit der Option -c mit dem Containernamen angegeben werden kubectl logs pod_name -c container_name

In diesem Beispiel erstellen wir einen Pod namens Logging-Pod, der jede Sekunde das Systemdatum und die Systemzeit ausgibt.

$ kubectl run logging-pod --generator=run-pod/v1 --image=busybox:latest \

--command -- /bin/sh -c 'während wahr; Datum machen; Schlaf 1; getan'

Pod/Logging-Pod erstellt

Dann werden die Containerlogs mit kubectl logs abgerufen

$ kubectl logs Logging-Pod

Mo Feb 24 23:25:16 UTC 2020

Mo. Feb 24 23:25:17 UTC 2020

Mo Feb 24 23:25:18 UTC 2020

Mo Feb 24 23:25:19 UTC 2020

Mo. Feb 24 23:25:20 UTC 2020

Hier sind weitere nützliche Container-Logging-Optionen:

--vorherige - Ruft Container-Logs von der vorherigen Instanziierung eines Containers ab, dies ist hilfreich für Container, die eine Absturzschleife durchlaufen. enthält Zeitstempel

Überwachungsanwendungen

Für die CKAD-Prüfung liegt der Umfang der Überwachungsanwendungen nur im Umfang von Kubernetes (einschließlich des Kubernetes-Metrikenservers). Zu den wichtigsten zu überwachenden Metriken zählen Ressourcen wie CPU und Arbeitsspeicher sowie Bereitstellungen und deren ausgeführte Pods. Labels filtern während der Überwachung nach einer bestimmten Anwendung oder Domäne.

Der Kubernetes-Metrikserver wird nicht mit der Kubernetes-Installation mit kubeadm installiert. Installieren Sie den Kubernetes-Metrikenserver und erfahren Sie hier mehr über den Metrikserver.

Wenn der Metrikserver installiert ist, können Sie die von den Kubelets in jedem Pod mit kubectl top pods gemeldeten Ressourcen anzeigen:

$ kubectl top pods -n kube-system

NAME CPU(Kerne) SPEICHER(Byte)

coredns-6955765f44-dwv9q 2m 8Mi

coredns-6955765f44-kjlc7 2m 8Mi

etcd-ubuntu 11m 71Mi

apiserver-persönlichkeit sein 27m 225Mi

kube-controller-manager-ubuntu 8m 36Mi

kube-proxy-zhhs8 1m 14Mi

be scheduler-ubuntu 2m 15Mi

Metrik-Server-64cfb5b5d8-cxq7d 1m 10Mi

web-net-fv9mb 1m 45Mi

Debugging

Das Debuggen laufender Anwendungen in Kubernetes beginnt mit dem Abrufen einfacher Statusinformationen zu den Pods.

Hier sind ein paar Orte, an denen Sie mit der Suche beginnen können:

Pod-Status – wird der Pod ausgeführt, ausstehend oder stürzt eine Schleife ab?Pod-Neustartanzahl – hat der Pod viele Neustarts in letzter Zeit durchgeführt?Pod-Ressourcen – fordert der Pod mehr Ressourcen an, die in seinem Namespace oder auf seinem Knoten verfügbar sind? der pod mit kubectl describe pod pod_name .

Sehen Sie sich anhand der Pod-Beschreibung an, wie häufige Pod-Probleme behoben werden.

Hier sind die wichtigsten Segmente in einer Beschreibung eines ausstehenden Pods:

$ kubectl beschreiben Pod busybox

Name: Busybox

Namensraum: Standard

...

Status: Ausstehend

IP: 10.32.0.5

IPs:

IP: 10.32.0.5

Behälter:

myapp-Container:

Container-ID:

Bild: busyBOX

...

Bedingungen:

Typstatus

Initialisiert wahr

Bereit Falsch

ContainerReady False

PodGeplant wahr

...

Veranstaltungen:

Geben Sie den Grund für das Alter aus der Nachricht ein

---- ------ ---- ---- -------

Normal Geplanter 10s default-scheduler Ubuntu erfolgreich default/busybox zugewiesen

Warnung InspectFailed 9s (x2 over 9s) kubelet, ubuntu Fehler beim Anwenden des Standard-Image-Tags "busyBOX": Bildreferenz konnte nicht geparst werden "busyBOX": ungültiges Referenzformat: Repository-Name muss in Kleinbuchstaben angegeben werden

Warnung fehlgeschlagen 9s (x2 über 9s) kubelet, ubuntu Fehler: InvalidImageName

Der Abschnitt "Ereignisse" der Beschreibung weist darauf hin, dass der Bildname ungültig ist. Das Korrigieren des Bildnamens wird dieses Problem beheben.

Hier ist ein weiterer ausstehender Pod:

$ kubectl Pods erhalten

NAME BEREIT STATUS NEU STARTET ALTER

nginx 0/1 Ausstehend 0 2m15s

Dieser Nginx-Pod ist seit über 2 Minuten ausstehend.

Schauen wir uns die Ereignisse des Pods an.

$ kubectl beschreiben pod nginx | grep -A4 Ereignisse

Veranstaltungen:

Geben Sie den Grund für das Alter aus der Nachricht ein

---- ------ ---- ---- -------

Warnung FailedScheduling 76s (x4 über 3m54s) Standard-Scheduler 0/1-Knoten sind verfügbar: 1 Unzureichende CPU.

Im Cluster sind nicht genügend Ressourcen verfügbar. Wir können sehen, ob der Pod eine harte Ressourcenanforderung stellt, indem Sie sich den Abschnitt Container der Pod-Beschreibung ansehen.

$ kubectl beschreiben pod nginx | grep -A10 Container

Behälter:

nginx:

Bild: nginx

Hafen:

Host-Port:

Grenzen:

CPU: 2

Speicher: 2Gi

Anfragen:

CPU: 1500m

Speicher: 1536Mi

Der Pod benötigt 1500 m CPU. Es gibt keine Knoten im Cluster mit 1500 m freier CPU, sodass der Pod ausstehend bleibt. Es gibt mehrere Möglichkeiten, dieses Problem zu beheben: Reduzieren Sie die CPU-Anforderung des Containers, geben Sie die CPU auf einem Cluster-Knoten frei oder fügen Sie dem Cluster einen neuen Worker-Knoten hinzu.

Übungsübung

Erstellen Sie einen Multi-Container-Pod mit dem Namen ckad-sidecar, der Folgendes enthält:

Der Hauptcontainer heißt nginx und führt das nginx-Image aus. Sidecar-Container heißt busybox und führt das busybox-Image aus Führen Sie im Busybox-Container den Befehl aus der Shell aus: wget -qO - http://ckad-sidecar | awk NR==4 && tail -f /dev/null Der Pod startet nur bei einem Fehler neu. Holen Sie dann die Container-Logs aus dem Busybox-Container.