Deployment aus Git

Statt selbst kubectl apply auszuführen, kannst du deinen Namespace auf ein Git-Repository zeigen lassen. Die Plattform beobachtet es und wendet an, was darin steht. Deployen wird damit zu einem Push.

Eingerichtet wird das im Portal im Bereich Kubernetes unter Git. Vier Felder:

Feld	Was es ist
Repository-URL	Wo deine Manifeste liegen
Pfad	Das Verzeichnis im Repository, das angewendet wird. Leer heißt das ganze Repository
Revision	Branch, Tag oder Commit, dem gefolgt wird
Self-Heal	Ob Änderungen, die direkt per kubectl gemacht wurden, zurückgenommen werden

Alles unter diesem Pfad wird in deinen Namespace angewendet. Es gibt nichts zu installieren und keine Zugangsdaten herauszugeben.

Vier Dinge, die du vorher wissen solltest

Das Repository muss ohne Zugangsdaten erreichbar sein. Es gibt kein Feld für Benutzername, Token oder Deploy Key, praktisch muss das Repository also öffentlich lesbar sein. Ein privates Repository synchronisiert nicht.

Nur https:// und ssh:// werden akzeptiert. Keine nackte IP-Adresse und kein Host innerhalb des Clusters.

Pruning ist immer an. Das ist keine Einstellung. Was du aus dem Repository entfernst, wird beim nächsten Sync aus deinem Namespace gelöscht. Genau darum geht es bei dieser Art zu deployen, aber es heißt auch: Das Repository ist die ganze Wahrheit. Ein Objekt, das nur existiert, weil es jemand einmal von Hand angelegt hat, verschwindet.

Self-Heal ist das Einzige, was du wählst. Ist es an, wird eine Änderung per kubectl auf den Stand aus dem Repository zurückgesetzt. Ist es aus, bleibt deine Änderung bestehen, bis sich diese Datei in Git das nächste Mal ändert. Lass es an, wenn du keinen Grund dagegen hast: Der halbe Nutzen von Git-Deployments ist, dass der Cluster nicht auseinanderdriften kann.

Was du auf diesem Weg deployen kannst

Fast alles, was dein Namespace anlegen darf, aber nicht ganz alles. Das hier funktioniert per kubectl und wird über Git abgelehnt:

• Vertical Pod Autoscaler
• ClientSettingsPolicies

Wenn ein Manifest von Hand durchgeht und nach einem Sync nie auftaucht, prüf zuerst, ob es eins davon ist. Alles Übrige aus Berechtigungen und Richtlinien wird angenommen, also Deployments, Services, ConfigMaps, Secrets, PVCs, Jobs, CronJobs, HPAs, Routen und alle drei Datenbank-Operatoren.

Clusterweite Objekte werden abgelehnt, genau wie per kubectl.

Ein Repository-Aufbau, der funktioniert

my-app/
  k8s/
    deployment.yaml
    service.yaml
    httproute.yaml

Setz Pfad auf k8s, Revision auf main, fertig. An den Manifesten ändert sich nichts, es sind dieselben Dateien wie in Erstes Deployment.

Commit keine Secrets im Klartext. Ein Secret in Git kann jeder lesen, der das Repository lesen kann, und dieses Repository ist öffentlich. Leg Secrets per kubectl an und halte sie aus dem synchronisierten Pfad heraus, oder verweise auf Werte, die deine Anwendung woanders herbekommt.

Stattdessen mit kubectl aus CI deployen

Wenn du das Deployment lieber aus deiner eigenen Pipeline steuerst, leg die Kubeconfig als CI-Secret ab und ruf kubectl apply aus der Pipeline auf.

Zwei Dinge, die du einplanen solltest:

Die Kubeconfig läuft nach einem Jahr ab. In deiner Pipeline warnt dich nichts. Vor Ablauf bekommst du eine E-Mail; trag dir die Erneuerung an einer Stelle ein, die du siehst, sonst scheitert die Pipeline etwa ein Jahr nach der Einrichtung an der Authentifizierung.

Behandle die Kubeconfig als langlebiges Geheimnis

Ein neuer Download macht den alten nicht ungültig, und selbst widerrufen kannst du ihn nicht. Eine abhandengekommene Datei funktioniert den Rest ihres Jahres weiter, und das einzudämmen erfordert den Support, der den Zugriff auf den Namespace sperrt.

Leg sie als maskiertes CI-Secret ab, nie ins Repository, und gib sie nie in der Job-Ausgabe aus.

Beides steht vollständig unter Zugang und kubectl.

Wie es weitergeht

• Images und Pull-Secrets, damit dein Image gebaut und gezogen wird
• Berechtigungen und Richtlinien, was angelegt werden darf