Presented at: Config Management Camp, Ghent, 2020-02
Kubernetes provides a declarative API, so you can describe the desired state of the system. And then it is the role of the control plane to operate the cluster (make the actual state match the desired state).
But we still need config mgmt for API objects to the point when they are applied to the cluster.
Helm helps to organize these configs into charts, template them, and manage releases. And GitOps lets you use a git repo as a single source of truth for the desired state of the whole system. Then all changes to this state are delivered as git commits instead of using kubectl apply or helm upgrade.
In this talk I will introduce the GitOps model for operating cloud native environments and give a short demo.
In this talk I show two CNCF projects:
- Flux CD: https://fluxcd.io/
- Helm: https://helm.sh/
4. Puppet
@ttarczynski
● Declarative: describe the desired state
● Modules: public and private
● Templates: ERB
● DSL: a simple and constrained language
● Code / data separation: Hiera
5. Kubernetes
@ttarczynski
● Control plane provides a Declarative API
● Declare the desired state
● Control plane makes sure that the actual
state converges to the desired state
9. Kubernetes: Why GitOps
@ttarczynski
● Can we declare all the state in GIT?
And expect the system to converge.
○ Track history
○ Easy rollback
○ Disaster Recovery
12. GitOps: How
@ttarczynski
● Flux CD: a GitOps operator
○ Runs in the cluster
○ Synchronizes the cluster state with a GIT repo
○ CNCF sandbox project
21. GitOps: Why Helm
@ttarczynski
● Manage complexity: describe complex apps
● Easy updates: in-place upgrades and custom hooks
● Simple sharing: public / private repo
● Rollbacks: roll back to an older version with ease
27. GitOps
@ttarczynski
● The entire system is described declaratively
● The canonical desired system state is
versioned (with Git)
● Approved changes to the desired state are
automatically applied to the system
● Software agents ensure correctness