GitOps mit K8s in der Praxis – ein Erfahrungsbericht

Für viele ist GitOps die Weiterentwicklung klassischer CI/CD-Prozesse. Es klingt simpel und bietet viele Vorteile, beispielsweise beim Durchsetzen von Infrastructure As Code (IaC). Auch benötigt der CI-Server bei GitOps keinen Zugriff auf den Cluster.

Bis zur erfolgreichen Implementierung sind dann aber doch erstaunlich viele Detailfragen zu beantworten: Wie lassen sich beispielsweise Fehler bemerken, Helm Charts deployen oder Ressourcen löschen?

Antworten auf diese und weitere Fragen liefert dieser Vortrag – kombiniert mit Praxistipps zur Realisierung von GitOps mit K8s und Flux.

Dabei fließen Erfahrungen aus zwei Fallbeispielen ein, der Neueinführung von GitOps beim ITZ Bund und der Migration von CI/CD zu GitOps bei der Cloudogu GmbH.

Transcript

1. /
   // GITOPS MIT K8S IN DER PRAXIS
   — EIN ERFAHRUNGSBERICHT
   Gerd Huber, ITZBund
   Johannes Schnatterer, Cloudogu GmbH
   Version: 202011041342-4e4f6c7
   @jschnatterer
   1 . 1
   

   View Slide

2. /
   Agenda
   • Was ist GitOps?
   • Anwendungsbeispiele
   • Neueinführung von GitOps (OnPrem)
   • Migration CI/CD GitOps (Public Cloud)
   • Herausforderungen und Erkenntnisse aus der Praxis
   • Fazit und Empfehlung
   1 . 2
   

   View Slide

3. /
   Was ist GitOps?
   • Begriff (August 2017):
   use developer tooling to drive operations
   • Funktioniert gut mit K8s ist aber nicht darauf beschränkt
   weave.works/blog/gitops-operations-by-pull-request
   2 . 1
   

   View Slide

4. /
   "Klassisches" Continuous Delivery ("CIOps" )
   Developer
   Git Repo CI Server K8s Cluster
   push pull deploy
   GitOps
   K8s Cluster
   Developer
   Git Repo
   CI Server
   GitOps
   operator
   push
   pull
   pull
   deploy
   K8s Cluster
   Developer
   Git Repo
   CI Server
   GitOps
   operator
   OCI Registry
   push
   pull
   push
   pull
   pull
   deploy
   2 . 2
   

   View Slide

5. /
   K8s Cluster
   Developer
   Git Repo
   CI Server
   GitOps
   operator
   push
   pull
   pull
   deploy
   Vorteile von GitOps
   • Weniger schreibende Zugriff auf Cluster nötig
   • Keine Credentials im CI Server
   • Config As Code: Auditierung, Reproduzierbarkeit,
   Cluster und Git automatisch synchronisiert
   • Zugriff auf Git oft organisatorisch einfacher als
   auf API-Server. Stichwort: Firewall-Freischaltung
   2 . 3
   

   View Slide

6. /
   Anwendungsfall:
   Neueinführung von GitOps (OnPrem)
   3 . 1
   

   View Slide

7. /
   GitOps mit K8s – Ausgangslage
   ITZBund – IT-Dienstleister für Bundesverwaltungen
   Dienstleistungen (u.a.)
   • bietet IT-Infrastruktur (z.B. Client-Virtualisierung, Cloud-Lösungen,
   Entwicklungsplattformen)
   • Hosting von Anwendungen
   Anforderungen
   • Staging von SW-Entwicklungen im Haus (mittels standardisierter
   Entwicklungsumgebung)
   • Staging für SW-Entwicklungen außerhalb des Hauses
   • Continuous Delivery/Staging
   • Forderung, fertige SWE-Produkte schnell zu stagen
   • Abstimmung der Konfiguration → Infrastructure as Code
   3 . 2
   

   View Slide

8. /
   GitOps mit K8s - Motivation
   Motivation für GitOps
   • automatisiertes Stagen
   • Berücksichtigung der Umgebungskonfiguration
   • pull-Operationen von einem höheren Security-Level
   • kein Veröffentlichen von credentials der Staging-Umgebungen an Dev
   Entwicklungs
   -
   plattform
   Staging
   GitOps
   Soll
   Abgleich Ist
   SWE
   extern
   3 . 3
   

   View Slide

9. /
   Anwendungsfall:
   Migration CI/CD GitOps (Public Cloud)
   4 . 1
   

   View Slide

10. /
    Ausgangslage
    • Kleines, junges Unternehmen
    • Prio: Quick Time to Market
    • Seit 2017 Continuous Delivery nach K8s in public Cloud
    4 . 2
    

    View Slide

11. /
    Motivation für GitOps
    Continuous Delivery funktionert gut. Aber:
    • Viele 3rd Party Anwendungen ohne CD Pipeline,
    mit manuellem Deployment
    Gefahr: commit/push vergessen
    • Schreibender Zugriff auf Cluster notwendig (Devs & CI)
    Security?
    Zusätzliche Gefahr: "ausversehen etwas deployt"
    • Erneuter Build für jede Stage
    langsam
    4 . 3
    

    View Slide

12. /
    Herausforderungen und
    Erkenntnisse aus der Praxis
    5 . 1
    

    View Slide

13. /
    Mehr Infrastruktur - GitOps Operator / CI/CD
    • Flux (ehemals weaveworks, jetzt CNCF Sandbox)
    • Argo (CNCF Incubator)
    • JenkinsX (CDF)
    • Spinnaker (CDF)
    • Carvel kapp (VMWare)
    • viele weitere:
    weaveworks/awesome-gitops
    5 . 2
    

    View Slide

14. /
    Entscheidung und erste Erfahrungen
    • Viele Lösungen sind vollständige CI/CD Lösungen
    • Flux: Reiner GitOps-Operator
    Integriert gut mit bestehender CI/CD Lösung -
    • Einfach deployt und konfiguriert
    5 . 3
    

    View Slide

15. /
    Offene Fragen bei Flux
    • Technischer Durchstich schnell erreicht
    • Direkt danach warten viele Detailfragen
    • Git-sync via Polling?
    • Wie Helm/Kustomize deployen?
    • Ressourcen löschen?
    • Umgang mit Fehlern?
    • Wie Staging implementieren?
    • Infrastruktur im Applikations-Repo oder im GitOps-Repo?
    • Lokale Entwicklung?
    • Zukunft von Flux?
    • ...
    5 . 4
    

    View Slide

16. /
    Mehr Infrastruktur 2 - webhook receiver
    • Flux pollt Git alle 5 Minuten langsameres Deployment
    • Alternativen
    • Mehr Infra:
    • Manuell anstoßen
    • Warten
    fluxcd/flux-recv
    fluxctl sync --k8s-fwd-ns kube-system
    5 . 5
    

    View Slide

17. /
    Mehr Infrastruktur 3 - Helm/Kustomize Operators
    Je nach verwendeten Tools, mehr Operators notwendig
    • Helm Operator
    • Kustomize Operator
    • Kein direkter Support für andere Templating-Tools
    5 . 6
    

    View Slide

18. /
    Löschen von Ressourcen
    • "garbage collection" kann in Flux aktiviert werden
    •
    • ... oder doch lieber manuell löschen
    5 . 7
    

    View Slide

19. /
    Fehlerbehandlung
    • Build und Deployment entkoppelt
    • Fehlermeldung asynchron Fehler werden später bemerkt
    • Abhilfe:
    • Statische Code Analyse mit CI Server - wenn Pipeline vorhanden
    • Monitoring und Alerting - mit Flux gewöhnungsbedürftig
    5 . 8
    

    View Slide

20. /
    Herausforderungen Monitoring und Alerting mit Flux (1)
    delta(flux_daemon_sync_duration_seconds_count{success='true'}[6m]) < 1
    docs.fluxcd.io/en/1.21.0/references/monitoring
    5 . 9
    

    View Slide

21. /
    Herausforderungen Monitoring und Alerting mit Flux (2)
    • Betroffene Anwendung und Ursache muss im Log gesucht werden
    • Ursachen im Flux und Helm Operator Log schwer zu finden
    • Viele Alerts: Schwierig zu differenzieren von "echten" Deployment-
    Fehlern. Beispiele:
    • Alerts während Wartungsfenster von Git Server
    • Operator Pod Neustarts
    • Operator Pod OOM Kills
    5 . 10
    

    View Slide

22. /
    Implementierung von Stages
    Idee 1: Staging Branches
    • Develop Staging
    • Main Production
    • Flux kann nur mit einem Git Repo umgehen
    Ein Flux pro Stage (Cluster/Namespace)
    • Branching-Logik aufwendig und fehleranfällig
    • Betrieb aufwendig (mehrere Flux-Instanzen notwendig)
    5 . 11
    

    View Slide

23. /
    Idee 2: Staging Ordner
    • Ein Ordner pro Stage
    • Alle auf demselben Branch
    • Wenn nötig: Staging Namespace in Ressourcen nennen
    • Prozess: Staging einfach committen; für Prod PR erstellen
    • Manuell zwar umständlich, aber gut für Automatisierung
    • Branching-Logik simpler
    • Betrieb weniger aufwendig
    5 . 12
    

    View Slide

24. /
    Applikations-Repo vs im GitOps-Repo
    • Bisher: Infrastruktur direkt neben Code im App Repo
    • Jetzt: Infrastruktur getrennt vom Code im GitOps Repo ?!
    Nachteile:
    • Getrennte Pflege
    • Getrennte Versionierung
    • Aufwendigeres Review
    • Aufwendigere lokaler Entwicklung
    5 . 13
    

    View Slide

25. /
    Lösung: CI-Server
    K8s Cluster
    Developer
    App Repo GitOps Repo
    CI Server
    GitOps
    operator
    OCI Registry
    push
    pull push
    push
    pull
    pull
    deploy
    5 . 14
    

    View Slide

26. /
    Resultat
    My gitops workflow might be turing complete
    ― Darren Shepherd, CTO Rancher Labs
    twitter.com/ibuildthecloud/status/1311474999148961798
    5 . 15
    

    View Slide

27. /
    Nachteile
    • Komplexität
    • Entwicklungsaufwand für Logik der CI-Pipeline
    • Viele Fehlerfälle. Beispiele:
    • Git Conflicts durch Concurrency
    • Dadurch Gefahr von Inkonsistenz
    Empfehlung: Plugin, Library dafür nutzen
    5 . 16
    

    View Slide

28. /
    Vorteile
    • Fail early: statische YAML-Analyse durch CI-Server (yamlint, kubeval)
    • Automatische PR-Erstellung
    • Arbeit auf echten Dateien CI-Server erzeugt inline YAML
    • Test-Deployment von Feature Branch möglich
    • Lokale Entwicklung ohne GitOps weiterhin möglich
    • Erleichterung von Reviews durch Anreicherung Commit Message
    5 . 17
    

    View Slide

29. /
    Lokale Entwicklung
    • Option 1: Flux und Git Repo in lokalen Cluster deployen
    Umständlich
    • Option 2: Keine Änderung. Möglich, wenn Infrastruktur im
    Applikations-Repo verbleibt.
    5 . 18
    

    View Slide

30. /
    Zukunft von Flux
    • August 2019: Flux + Argo GitOps Engine = Flux v2
    • Juli 2020: Flux v2 GitOps Engine GitOps Toolkit
    • Egal wie: Breaking Changes
    • Dafür viele neue Features:
    • Alerting
    • Webhook Receiver eingebaut
    • Helm und Kustomize Operators
    • Mehrere Git Repos
    • Mandanten
    • Flux aktualisiert sich selbst mit GitOps
    • ... toolkit.fluxcd.io
    5 . 19
    

    View Slide

31. /
    Das Flux-Dillema (Stand 11/2020)
    This also means that Flux v1 is in maintenance mode.
    Once we have reached feature-parity [..], we will continue to support
    Flux v1 and Helm Operator v1 for 6 more months
    • Flux v2 hat aber noch nicht alle Features von Flux:
    • und ist nicht stable - Version 0.x
    github.com/fluxcd/flux/blob/738d47/README.md
    github.com/fluxcd/flux/issues/3320
    toolkit.fluxcd.io/roadmap
    github.com/fluxcd/flux2/releases
    5 . 20
    

    View Slide

32. /
    Fazit
    • ITZBund
    • Vereinfacht / beschleunigt Prozesse
    • Konfiguration liegt an definierter, zentraler Stelle vor
    • GitOps-Prozess als Konvention einheitlich über viele Projekte
    • Vorteile bei Security
    • Cloudogu
    • CI/CD-Prozess "runder"
    • schnelleres Deployment in Produktion
    • Git und Cluster immer in Sync
    • Aber: Security-Vorteile tragen erst nach vollständiger Migration
    6 . 1
    

    View Slide

33. /
    Destillierte GitOps-Erfahrung
    Funktionierendes GitOps hat viele Vorteile
    Der Weg dorthin kann aufwendig sein!
    6 . 2
    

    View Slide

34. /
    Empfehlung für Flux?
    Dilemma: Flux v1 in maintenance, Flux v2 noch nicht stable.
    • Bei bestehendem CI/CD-Prozess:
    Nur mit gutem Grund migrieren bevor Flux v2 stable ist
    • Bei Neueinführung von Kubernetes:
    Flux v2 ausprobieren
    6 . 3
    

    View Slide

35. /
    Gerd Huber, ITZBund
    Johannes Schnatterer, Cloudogu GmbH
    In Arbeit
    • GitOps-Jenkins Library
    • GitOps-Artikel
    cloudogu.com/gitops
    cloudogu.com/schulungen
    github.com/cloudogu/k8s-gitops-playground
    cloudogu.com/blog
    @cloudogu
    @jschnatterer
    6 . 4
    

    View Slide