Zum Inhalt

Manifest oder Deployment as Code

Um Applikationen in eine Kubernetes Umgebung aufzubauen empfiehlt es sich mit sog. Manifests zu arbeiten um dadurch eine reproduzierbare und nachvollziehbare Umgebung zu erhalten - hierbei spricht man auch gerne von "Deployment as Code".

Zum Verständnis: In Kubernetes wird alles in APIs aufgeteilt, die wiederum ihre eigenen Variationen beinhalten - dies zeigt sich bei den Manifest-Eigenschaften apiVersion und kind.

grundlegender Aufbau eines Manifests

Ein Manifest ist eine in Yaml beschriebenes Objekt/Ressource im Kubernetes. Eine Manifest- bzw. Yaml-Datei kann ein oder auch mehrere Objekte enthalten.

Grundlegend besteht ein Manifest aus der Benennung der verwendeten API, dessen Objekt-Art, dazugehörige Metadaten und der Spezifikationen des Objekts: 

---
apiVersion: <verwendete API>
kind: <Komponente in der API>
metadata:
  name: <Name des Objekts>
  namespace: <Namespace>            # optional
  labels:                           # optional
    app: <Name des Labels 'app'>    # optional
spec:
  <Eigenschaften des Objekts>
  ...
  ...
Wenn man bei den Metadaten namespace weglässt, wird entweder default dafür eingesetzt, oder man muss mit kubectl -n <Namespace> den Namespace mit angeben. Dadurch erhält man eine Möglichkeit ein Manifest ohne weitere Änderungen immer wieder in verschiedenen (eigenen) Namespaces verwenden zu können - vorausgesetzt es werden nicht andere Eigenschaften speziell zu dem Namespace benötigt. Beispiel dafür wäre ein Ingerss-Gateway, der den genauen FQDN benötigt mit dem die Applikation erreicht werden soll.

Somit wäre es möglich ein Manifest beispielsweise für eine WordPress-Installation mit Datenbank inklusive persistenten Volumes und dessen Service-Objekt zu erstellen und man müsste nur für jede Installation den Ingress-Gateway und ggf. dessen Zertifikats-Einstellungen separat für jeden Namespace nachziehen.

Bestandteile zu einem umfänglichen Deployment

Zunächst: Ein Deployment bezeichnet hier die Bereitstellung eines Services oder einer Applikation mit all seinen benötigten Bestandteilen. Es sei erwähnt, dass es im technischen Kontext zu Kubernetes ebenfalls ein Deployment im Rahmen eines API-Calls gibt.

Wie im Kapitel systemischer Aufbau bereits veranschaulicht werden mehrere Kubernetes Objekte zum Betrieb (und dessen Erreichbarkeit) einer Applikation benötigt.

simples WordPress in Kubernetessimples WordPress in KubernetesKubernetes Clusterwordpress01[Namespace] persistent Volume persistent Volume Storage Class TLS-Secrets wpdb.wordpress01.svc sqlDB-Pod myblog.domain.com web.wordpress01.svc Webserver-Pod ConfigMap Secret Volume VolumeClaim ConfigMap Secret Volume VolumeClaimUserexterner Zugriff auf IP-Ebene HTTPS  service: web             mysql://wpdbDarstellung ist sehr grob umrissen und dient nur der Veranschaulichung für das Zusammenspiel der Komponenten
simples WordPress in Kubernetessimples WordPress in KubernetesKubernetes Clusterwordpress01[Namespace] persistent Volume persistent Volume Storage Class TLS-Secrets wpdb.wordpress01.svc sqlDB-Pod myblog.domain.com web.wordpress01.svc Webserver-Pod ConfigMap Secret Volume VolumeClaim ConfigMap Secret Volume VolumeClaimUserexterner Zugriff auf IP-Ebene HTTPS  service: web             mysql://wpdbDarstellung ist sehr grob umrissen und dient nur der Veranschaulichung für das Zusammenspiel der Komponenten

Aus der Darstellung ergeben sich folgende, benötigte Objekte:

  • Namespace - der Namespace in dem alles laufen soll
  • ConfigMap - für Environments oder Konfigurationsdateien zum Container
  • Secret - ebenfalls für Container Environments oder Dateien, aber mit sensiblen Daten (DB-User und Passwort)
  • PVC / persistenter Volume Claim - um persistente Daten zu speichern
  • Pod - (zumeist) ein, oder mehrere Container als eine Einheit
  • Deployment - zur Erstellung der eigentlichen Pods (hierbei gibt es drei Grundarten (kind): Deployment, StatefulSet und DaemonSet)
  • Service - um einen definierten Ansprechpunkt für die Pods zu erzeugen (Service-Discovery)
  • Ingress - ähnlich einem Reverse-Proxy für Zugriffe von Außen
  • TLS-Secret - mit Zertifikats-Daten für den Ingress

Bei diesem Szenario werden ein Cert-Manager und ein Provisioner zu Storage-Cass (und persistenten Volumes) vorausgesetzt - gerade das Thema mit der Storage-Class ist sehr spezifisch.