CKAd-Selbststudium
Modul 1
Broad Skills bietet eine breite Palette von Beratungsdiensten zu Open Source-Technologien
CKAD Selbststudium Mod 1
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
Basis-Pods
Pods sind die atomare Bereitstellungseinheit in Kubernetes und bestehen aus einem oder mehreren Containern in verschiedenen Arrays in einer PodSpec:
- Container (erforderlich) – Container mit langer Laufzeit für Anwendungen, Proxys, Logging-/Monitoring-Sidecars usw. Init-Container (optional) – Bootstrapping-Container, die einmal ausgeführt werden, um lang laufende App-Container zu booten. Ephemere Container (optional) – eine Alpha-Funktion in Kubernetes, Diese Container können zur Laufzeit zur Ad-hoc-Fehlerbehebung hinzugefügt werden
Ein einfacher Pod würde einen einzelnen Container enthalten und könnte mit yaml oder imperativ erstellt werden:
$ kubectl run ckad-basic-pod --image=nginx:latest
Sicherheitskontext
Dies ist eine Einstellung in einer PodSpec, die die Sicherheit für einen oder alle Container in einem Pod erhöht und die folgenden Einstellungen hat:
- Discretionary Access Control: Definieren Sie Benutzer-ID (UID) und Gruppen-ID (GID)-Einstellungen für Prozesse innerhalb von containerSecurity Enhanced Linux (SELinux): Aufrufen vordefinierter SicherheitslabelsLinux Capabilities: grobkörnige Steuerung von Systemaufrufen an den Linux-Kernel in einer Whitelist oder BlacklistMarkierung a pod withprivileged = true gewährt alle FähigkeitenAppArmor: Ruft vordefinierte Programmprofile auf, um die Fähigkeiten einzelner Programme einzuschränkenSeccomp: Feingranulare Kontrolle über die Systemaufrufe eines Prozesses durch die Verwendung von json-RichtlinienAllowPrivilegeEscalation: Steuert, ob ein Prozess mehr Privilegien erlangen kann als sein Elternteil
SecurityContext-Einstellungen können für den Pod und/oder jeden Container im Pod festgelegt werden, zum Beispiel:
apiVersion: v1
Art: Pod
Metadaten:
Name: ckad-training-pod
spezifikation:
securityContext: # Pod-Sicherheitskontext
fsGruppe: 2000
Behälter:
- Name: ckad-training-container
Bild: nginx
securityContext: # Container-Sicherheitskontext
Fähigkeiten:
hinzufügen: ["NET_ADMIN"]
Anforderungen und Grenzen von Containerressourcen
Ressourcenanforderungen und -limits werden pro Container innerhalb eines Pods festgelegt. Durch Angabe einer Ressourcenanforderung teilen wir dem Kubernetes-Scheduler die _minimale_ Menge jeder Ressource (CPU und Arbeitsspeicher) mit, die ein Container benötigt. Durch die Angabe von Grenzwerten richten wir Kontrollgruppen-Einschränkungen auf dem Knoten ein, auf dem der Prozess ausgeführt wird. Ein Beispiel für das Festlegen von Anforderungen/Limits sieht wie folgt aus:
apiVersion: v1
Art: Pod
Metadaten:
Name: ckad-resource-pod
spezifikation:
Behälter:
- Name: ckad-Ressourcencontainer
Bild: meine-App: v3.3
Ressourcen:
Grenzen:
CPU: "1"
Speicher: „1Gi“
Anfragen:
CPU: "0.5"
Speicher: „500Mi“
ConfigMaps
ConfigMaps sind entkoppelte Konfigurationsartefakte, die containerisierte Anwendungen portabel halten.
Die ConfigMap-API-Ressource bietet Mechanismen, um Container mit Konfigurationsdaten zu injizieren, während Container Kubernetes-unabhängig bleiben. Eine ConfigMap kann verwendet werden, um feinkörnige Informationen wie einzelne Eigenschaften oder grobkörnige Informationen wie ganze Konfigurationsdateien oder JSON-Blobs zu speichern.
Es gibt mehrere Möglichkeiten, eine ConfigMap zu erstellen: aus einem Verzeichnis-Upload, einer Datei oder aus Literalwerten in der Befehlszeile, wie im folgenden Beispiel gezeigt:
$ kubectl create configmap ckad-example-config --from-literal foo=bar
Geheimnisse
Geheimnisse enthalten vertrauliche Informationen wie Kennwörter, OAuth-Token und SSH-Schlüssel. Diese Informationen in einem Secret zu speichern ist sicherer und flexibler, als sie wörtlich in einer Pod-Definition oder einem Docker-Image zu platzieren!
Es gibt drei Arten von Geheimnissen, die durch das Flag --help erklärt werden:
$ kubectl create secret --help
Erstellen Sie mit dem angegebenen Unterbefehl ein Geheimnis.
Verfügbare Befehle:
docker-registry Erstellen Sie ein Geheimnis zur Verwendung mit einer Docker-Registrierung
generisch Erstellen Sie ein Geheimnis aus einer lokalen Datei, einem Verzeichnis oder einem Literalwert
tls Erstelle ein TLS-Geheimnis
Beispiel für die zwingende Erstellung eines Geheimnisses:
$ kubectl erstelle geheimes generisches my-secret \
--from-literal=username=ckad-user \
--from-literal=password=Char1!3-K!10-Alpha-D31ta
Mounten von ConfigMaps/Secrets als Volumes oder Umgebungsvariablen
ConfigMaps und Secrets werden von Pods entweder als Volumes oder als Umgebungsvariablen bereitgestellt, die von einem Container in einem Pod verwendet werden. ConfigMaps und Secrets können auf zwei Arten mit einem Pod verwendet werden:
- Dateien in einem VolumeUmgebungsvariablen
Secrets können auch vom Kubelet beim Abrufen von Images für einen Pod verwendet werden, die als imagePullSecret bezeichnet werden -training-docker-token ” als imagePullSecret :
apiVersion: v1
Art: Pod
Metadaten:
Name: pod-config
spezifikation:
Behälter:
- Name: nginx
Bild: nginx:neueste
imagePullSecrets:
- Name: ckad-training-docker-token
volumeMounts:
- Name: config
mountPath: /etc/myapp
Bände:
- Name: config
configMap:
Name: ckad-example-config
Übungsübung
Erstellen Sie einen Pod, der das nginx-Image ausführt und ein Dienstkonto namens my-sa verwendet.
