Familie Krais

GitOps

Was ist GitOps?

Das Wort GitOps ist eine Zusammensetzung aus Git und Operations und setzt Git und eine funktionsfähige Kubernetes-Umgebung voraus. GitOps setzt dabei auf die deklarative Beschreibung in Git. Die Beschreibung in einem Git-Repo wird daher uch als „Source of Truth“ bezeichnet. Ein in Kubernetes installierter Operator besitzt dabei die Rechte, ins Git zu „schauen“, um dann auf Änderungen im Git-Repo zu reagieren. Der Operator vergleicht dabei ständig das SOLL (Git-Repo) und das IST (Kubernetes-Umgebung) und reagiert entsprechend. Manuelle Änderungen an der Umgebung sind daher nicht mehr „state-of-the-art“ und zu vermeiden, da diese vom SOLL abweichen, vom Operator erkannt und bereinigt werden. Dieser Vorgang wird als reconciliation bezeichnet.

Vorbedingungen – Folgende Dinge sollten vor der Installation vorhanden sein:

  • Gitlab oder Github Account mit einem eigenen Repo
  • Minikube lauffähig (siehe Minikube)
  • installierten Operator in Kuberenetes (z.B. fluxcd.io oer ArgoCD)

Nachfolgend wird ein Beispiel skizziert, welches Gitlab und fluxcd.io nutzt.

Einrichtungen in Git

In Gitlab wird am besten ein eigenes Repo angelegt und für dieses Repo dann ein eigener Account für den Git-Operator hinterlegt wird.

  • Repo: fluxcd
  • User für GitOps mit den Rechten „Owner“ in Gitlab: fluxop
  • Access-Token für diesen User fluxop ausstellen in Gitlab unter dem Repo im Abschnitt „Settings  –> Access Token“  erstellt. Achtung, das erstellte Token hat ein Gültigkeitsende.
    • Alternativ lässt für den User fluxop auch ein ssh-Schlüsselpaar generieren und der ssh-pub-key im User-Profil von fluxop hinterlegen

Download und Installation Operator fluxcd.io

Installation fluxcd.io auf dem Host, wo auch Minikube installiert ist:

tester@host:~$ curl -s https://fluxcd.io/install.sh | sudo bash

Einrichtung Bootstrap für fluxcd.io

Am besten wird ein eigenes Bash-Skript bootstrap.sh erstellt mit folgendem Inhalt:


#!/bin/bash
export GITLAB_TOKEN= "HIER DAS ACCESS TOKEN AUS GITLAB EINFUEGEN"

flux bootstrap gitlab \
  --owner=fluxop \
  --repository=fluxcd \
  --branch=main \
  --path=clusters/my-cluster \
  --personal

Vorbedingung: Minikube muss zuvor gestartet sein.
Danach dann die Dateirechte ändern und starten:

tester@host:~$ chmod +x ./bootstrap.sh
tester@host:~$ ./bootstrap.sh

Damit wird nun fluxcd.io in den k8s-Cluster integriert.

Nginx-Beispiel in Git

Hierfür ist es sinnvoll, Visual Studio Code mit einer funktionierenden Git-Plugin-Umgebung und Zugriff auf das oben genannte Repo zu haben. Für den Funktionstest werden unter dem Ordner minikube folgende 3 yaml-Dateien angelegt:

  • kustomization.yaml
  • namespace-nsnginx.yaml
  • nginx-deployment.yaml
  • nginx-service.yaml

Inhalt der Dateien

Die Dateien sind in der yaml-Notation verfasst, d.h. Einrückungen müssen auch yaml-konform als Einrückungen berücksichtigt werden.

 

kustomization.yaml

Diese Datei ist quasi der Kleber zwischen den anderen yaml-Dateien und definiert für den eigenen Namespace nsnginx die notwendigen Ressourcefiles.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: nsnginx

resources:
- namespace-nsnginx.yaml
- nginx-deployment.yaml
- nginx-service.yaml

namespace-nsnginx.yaml

Für das Beispiel-Deployment des nginx wird ein eigener Namespace nsnginx festgelegt und in dieser Datei deklariert.

apiVersion: v1
kind: Namespace
metadata:
  name: nsnginx

nginx-service.yaml

Für die spätere Kommunikation wird in dieser Datei die Kommunikationsbeziehung zwischen dem „externen“ Port 80 und dem „internen“ Port 31007 des Pods festgelegt. Dadurch kann dann später die Weiterleitung von Port 80 auf Port 31007 des Pods erfolgen.

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: nsnginx
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 31007

nginx-deployment.yaml

In dieser yaml-Datei wird das eigentliche Deployment des nginx beschrieben.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: nsnginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

 

Jetzt wird es spannend.

Sind alle Dateien angelegt, so sind diese mit den gängigen git-Befehlen „git-add“ und „git-commit“ in das lokale git-repo einzubinden und dann an den Gitlab-Server per „git push“ zu übermitteln.

Sobald der git-Operator fluxcd.io ein Delta in seinem ihm in der Konfiguration zugeteilten git-Repo erkennt, wird die reconciliation angestartet.

Wird über „minikube dashboard &“ das k8s-Dashboard geöffnet und auf den Namespace nsnginx navigiert, sind die 3 Pods erkennbar, welche durch das Deployment im Abschnitt replicas angegeben wurden.

Änderung der replicas auf 8

In der deployment.yaml wird nun der Abschnitt von „replicas: 3“ auf „replicas: 8“ geändert. Die Änderung wird mit dem git-Plugin in Visual Studio Code erkannt und visuell angezeigt.

Die Änderung wird nun in Visual Studio Code zum lokalen Repo hinzugefügt, mit einem Commit versehen und auf den Server gepushed.

Daraufhin wird der Operator fluxio.cd aktiv und führt die reconciliation aus. In dieser Darstellung werden gerade 5 der 8 Replicas erstellt:

Im Abschluss ist dann das Replica auf 8 gestellt:

Verbindung zum nginx herstellen

Mit Hilfe von minikube kann eine Verbindung zum Webserver nginx hergestellt werden:

test@host:~$ minikube service -n nsnginx nginx
┌───────────┬───────┬─────────────┬───────────────────────────┐
│ NAMESPACE │ NAME  │ TARGET PORT │            URL            │
├───────────┼───────┼─────────────┼───────────────────────────┤
│ nsnginx   │ nginx │ 80          │ http://192.168.49.2:31007 │
└───────────┴───────┴─────────────┴───────────────────────────┘
🎉  Öffne Service nsnginx/nginx im Default-Browser...
Wird in einer aktuellen Browsersitzung geöffnet.
test@host:~$

Finales Rücksetzen des Replica auf 3

Durch das Setzen der Replica auf 3 in der deployment.yaml wird der Ursprungszustand wiederhergestellt. Nach dem „git push“ wird das Replica wieder auf 3 gesetzt.

Details lassen sich auch über kubectl beispielsweise abfragen:

test@host:~$ kubectl get pods -n nsnginx
NAME                     READY   STATUS    RESTARTS       AGE
nginx-59f86b59ff-8dfsn   1/1     Running   11 (30m ago)   21d
nginx-59f86b59ff-8nhv2   1/1     Running   11 (30m ago)   21d
nginx-59f86b59ff-t67b5   1/1     Running   11 (30m ago)   21d
test@host:~$

 

Joachim Krais