GitOps

Czyli jak pożenić Git i Kubernetes do wdrażania i utrzymania

Marcin Jasion

Confitura 2019 - 29.06.2019

How we manage Kubernetes today?

Command line

kubectl create ...

kubectl apply  ...

kubectl delete  ...

Manual

Operator as a source of truth

Possible two parallel deploys at same time for same object - needed communication

No diff and changelog

CI/CD Pipeline

Automated

Notifications on failure(e.g. Slack, Email)

Often problem with reproducing the build process(e.g. build variables)

Other problems

Kubernetes objects are stored in database

Not everyone remembers to delete the objects if no longer needed

What with objects: RBAC, Namespaces, Secrets?

Hard to compare changes before apply

Hard to implement Gitflow pipeline

Race condition

Often we forget to push the code after manual apply

GitOps

The practical guide to GitOps from Weaveworks

The entire system is described declaratively

Configuration is guaranteed by a set of facts instead of by a set of instructions

Cluster can be easily reproduced(e.g. business recovery tests; site clone)

Reduced meantime to recovery (MTTR)

System state is versioned in Git

Changelog and rollbacks are easy

• git log
• git revert

Access to the repository can be restriced

Changes are applied automatically

Operator is a service

Increased Consistency and standardization of your pipelines

Information about divergence

Alerting

Metrics

Still don't understand why?

To avoid learning from this...

$ kubectl get pods,svc
NAME              READY   STATUS    RESTARTS   AGE
pod/echo-server   1/1     Running   0          2s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/echo-server   NodePort    10.100.52.115   none        8080:31480/TCP   2s

Not only UI

spec:
  source:
    repoURL: https://gitlab.com/mjasion/gitops-presentation.git
    path: gitops_example/demo_1/
    targetRevision: master
    directory:
      recurse: true
   destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  syncPolicy:
    automated: {}
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo1
  namespace: argocd

Not only UI

spec:
  source:
    repoURL: https://gitlab.com/mjasion/gitops-presentation.git
    path: gitops_example/demo_1/
    targetRevision: master
    directory:
      recurse: true
   destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  syncPolicy:
    automated: {}
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo1
  namespace: argocd

Adding new object

kind: Deployment
metadata:
  name: echo-server-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echo-server-deployment
  template:
    metadata:
      labels:
        app: echo-server-deployment
    spec:
     containers:
       - name: echoserver
         image: googlecontainer/echoserver:1.10
         ports:
           - containerPort: 8080
apiVersion: apps/v1

What if object disappear?

Synchronization policies

Manual

Automatic, but do not automatically prune resources

Automatic, but do not automatically prune resources

Object Pruning

Argo supports templating tools

• Plain directory of YAML/json manifests
• helm charts
• kustomize applications
• ksonnet applications
• jsonnet files
• Custom tools(developing own plugin is required)

Multiple applications?

Be aware

It is not possible to configure dependencies between applications

Canary Deployments?

Argo Rollouts

Extends classic Deployment object with Blue/Green and Canary deployment

Integrated with Argo CD UI

KubeCon 2019

apiVersion: argoproj.io/v1alpha1 # Changed from apps/v1
kind: Rollout # Changed from Deployment
... # Same as is in Deployment Object
 strategy:
    blueGreen: # A new field for the Blue Green strategy options
      previewService: my-service-preview # Reference to a service
      activeService: my-service-active # Reference to a service

apiVersion: argoproj.io/v1alpha1 # Changed from apps/v1
kind: Rollout # Changed from Deployment
... # Same as is in Deployment Object
  strategy:
    canary: # A new field for configurable Canary options
      maxSurge: "10%"
      maxUnavailable: 0
      steps:
      - setWeight: 10
      - pause:
          duration: 30 #seconds
      - setWeight: 50
      - pause: {}

Alternatives

Flux Operator

GitOps precursor - tool developed Weaveworks

Automatically updates container tags

Requires write access to git repository

Poor support for branching model

Support plain objects and Helm

Object pruning in alpha stage

No UI😢

github.com/weaveworks/flux

What if you will not GitOps?

See you on your failure story @ Confitura 2020😂

Who is adopting GitOps?

Intuit - Argo CD developers

Weaveworks - Flux Operator

Uber

Tesla

Mirantis

(and do not tell anyone...)

jobs.lever.co/codility

And we are looking for task creators💰!