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

Managing Helm Deployments with GitOPS at CERN

Ricardo Rocha
November 19, 2019

Managing Helm Deployments with GitOPS at CERN

Tuesday, November 19 • 2:25pm - 3:00pm
Managing Helm Deployments with Gitops at CERN - Ricardo Rocha, CERN
Click here to remove from My Sched.
https://sched.co/UabD
TweetShare
WHAT DID YOU THINK?

Please share details here.
Kubernetes has taken a key role at CERN both for physics analysis and core IT services, simplifying and accelerating deployments and allowing a much higher rate of updates and upgrades.

This session will describe how helm is used for managing the description and configuration of the services. How CERN uses chartmuseum to maintain its private chart repositories, and how a custom plugin is used to manage secrets in the configuration, safely pushing encrypted payloads into git repositories. How a well defined structure of umbrella charts (sometimes referred to as meta charts) is used to define high level applications with complex dependencies, and how the notion of service variants and environments is exposed.

A demo will show the full gitops lifecycle for both production and canary deployments, relying on weave flux to quickly propagate changes to clusters.

Ricardo Rocha

November 19, 2019
Tweet

More Decks by Ricardo Rocha

Other Decks in Technology

Transcript

  1. Provisioning Deployment Update Physical Infrastructure Days or Weeks Minutes or

    Hours Minutes or Hours Utilization Poor Maintenance Highly Intrusive
  2. Provisioning Deployment Update Physical Infrastructure Days or Weeks Minutes or

    Hours Minutes or Hours Utilization Poor Maintenance Highly Intrusive Cloud API Virtualization Minutes Minutes or Hours Minutes or Hours Good Potentially Less Intrusive
  3. Provisioning Deployment Update Physical Infrastructure Days or Weeks Minutes or

    Hours Minutes or Hours Utilization Poor Maintenance Highly Intrusive Cloud API Virtualization Minutes Minutes or Hours Minutes or Hours Good Potentially Less Intrusive Containers Seconds Seconds Seconds Very Good Less Intrusive
  4. “ Where is my machine hosted? “ “ What is

    the state of the hypervisor? “ “ Could you check for noisy neighbors? “ But similar automation tools, ssh, systemd, syslog, etc Physical to Virtualization and Cloud
  5. “ How do i retrieve my application’s logs? And how

    to log rotate? “ “ How do i access the node running container X ? “ “ How do i install package X on the nodes? “ “ Seems like one of the cluster node’s filesystem went read-only... “ “ Docker, Kubernetes, Ingress … now Helm … this is a lot of new stuff! “ Significant change in mindset and a steeper learning curve And then to containers ...
  6. Container Use Cases Experiment Trigger farms Spark as a Service,

    on demand Spark clusters on Kubernetes KubeFlow and distributed ML training Batch on Kubernetes, Native and HTCondor WebLogic and other internal services
  7. Making it easier... Container Trainings, Workshops, Office Hours One thing

    is similar … what is now called GitOps We’ve used git for years to store and manage configuration Maybe that can help onboarding more service managers Puppet to Helm Manifests vs Golang, YAML config for both Much faster turn-around
  8. Charts Repository Initially package charts stored in plain S3 Moved

    to chartmuseum to have a management API, with S3 as backend Mirrored and home grown chart repositories All triggered by GitLab CI Versions include commit hash (x.y.z-cern-x.y.z) CERN STABLE INCUB. OPENST ACK TUNGST EN ... git push helm lint helm test helm package git tag helm lint helm test helm package helm push
  9. Umbrella Charts Meta charts wrapping the different charts required per

    application Units of deployment with all dependencies and any additional manifests Stored separately as they manage cluster state ( permissions and visibility ) First go relied on branches for environments and a custom structure $ cat requirements.yaml dependencies: - name: binderhub version: 0.2.0-575fb2a repository: https://charts.cern.ch/jupyterhub $ ls templates ds-gpu.yaml psp.yaml $ ls Chart.yaml requirements.yaml secrets.yaml templates/ values.yaml
  10. Managing Secrets Option 1: Building on Kubernetes Secrets or similar

    CRDs No easy or obvious way to plug external secrets Bitnami SealedSecrets: works well, but hard with existing charts Vault an option to fully delegate secret management Option 2: Take (part of) the helm values as secret data, not the resources Versioning of secrets along the rest of the configuration Futuresimple helm-secrets (existing plugin) with sops
  11. A Barbican Secret Plugin for Helm Similar interface to futuresimple

    helm-secrets Builds on existing identity scheme to access and manage encryption keys $ helm --name <release> secrets view secrets.yaml edit secrets.yaml install stable/nginx --values secrets.yaml upgrade stable/nginx --values secrets.yaml lint --values secrets.yaml Similar wrapper for kubectl https://github.com/cernops/helm-barbican
  12. Our end goal from the start Relying on chart updates

    only Flux and GitOps Meta Chart Registry git push docker push FluxCD git pull Helm Release CRD $ helm install fluxcd/flux \ --namespace flux --name flux --values flux-values.yaml --set git.pollInterval=1m --set git.url=https://gitlab.cern.ch/.../hub $ cat flux-values.yaml rbac: create: true helmOperator: create: true chartsSyncInterval: 5m configureRepositories: enable: true repositories: - name: jupyterhub url: https://charts.cern.ch/jupyterhub ... Helm Operator
  13. Flux and GitOps What’s in a Helm Release? apiVersion: flux.weave.works/v1beta1

    kind: HelmRelease metadata: name: hub namespace: prod spec: releaseName: hub chart: git: https://gitlab.cern.ch/.../hub.git path: charts/hub ref: master valuesFrom: - secretKeyRef: name: hub-secrets key: values.yaml values: binderhub: ... This is how we plug our encrypted values data |-- charts |-- hub Chart.yaml requirements.yaml values.yaml |-- templates custom-manifest.yaml |-- namespaces prod.yaml stg.yaml |-- releases |-- prod hub.yaml |-- stg hub.yaml |-- secrets |-- prod secrets.yaml |-- stg secrets.yaml
  14. Ongoing: GitOps for Cluster Lifecycle Currently validating this solution to

    centrally manage upgrades Reduce the scope of the cluster orchestration tool to base components Let a single Flux HelmRelease manage all add-ons (staging, prod) dependencies: - name: eosxd version: 0.3.1-cern-0.1.0-7+ba5e81 repository: http://charts.cern.ch/cern - name: fluentd version: 2.2.1-cern-0.1.0-3+1c551a1 repository: http://charts.cern.ch/ stable - name: prometheus version: 9.3.1-cern-0.1.0-3+1c551a1 repository: http://charts.cern.ch/stable - name: traefik version: 1.79.0-cern-0.1.0-3+1c551a1 repository: http://charts.cern.ch/stable ...
  15. Conclusion & Next Steps Helm and (Argo) Flux give us

    a familiar toolset for containerized applications Git as the source of truth Helm v3 and goodbye Tiller Helm Hub, Signed Helm Charts (re) Consider automation of charts and container image updates Cattle clusters, Blue / Green, Canary with Service Mesh
  16. Questions? LHC is in a long shutdown for the next

    year, underground visits possible https://visit.cern Follow our tech blog https://techblog.web.cern.ch @ahcorporto , [email protected]