Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GitOps mit K8s in der Praxis – ein Erfahrungsbericht

schnatterer
November 04, 2020

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.

schnatterer

November 04, 2020
Tweet

More Decks by schnatterer

Other Decks in Technology

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