October 2020

The goal of this training is to demonstrate how to configure and deploy an application into Kubernetes in EKS.

By the end of this training, everyone should have a general understanding of:

• GitOps
• Helm

Training Agenda:

1. A very quick overview of the demo app
2. A practical example

Topics To Cover:

• The eks-gitops repo
• GitOps
• Helm
• More Kubernetes concepts
  • Operators
  • Custom Resource Definitions (CRD)
  • Annotations
  • CronJobs

This repo holds the app we'll be deploying to Kubernetes. There's really nothing special here.

$ docker build --tag demo .
$ docker run --itd --name demo --rm --publish 8080:8080 demo:latest

I'll walk through a practical example where we deploy the demo app to EKS. I prefer learning by doing, so rather than read through the following material, we'll use it as a reference as we come across new concepts in the example we'll be working.

What is GitOps?

GitOps is a way of implementing Continuous Deployment for cloud native applications. It focuses on a developer-centric experience when operating infrastructure, by using tools developers are already familiar with, including Git and Continuous Deployment tools (gitops.tech).

In other words, we describe the state of our K8s cluster (e.g., the "cloud native application") in a Git repository, then GitOps uses automated processes to make the cluster match the desired state described in the repository.

GitOps is more like a philosophy -- it's a description of how a GitOps implementation should behave.

See Why should I use GitOps?

Flux is a Kubernetes operator you install on a cluster to implement GitOps.

A Kubernetes Operator lets you extend the cluster's behavior without modifying the code of Kubernetes itself (kubernetes.io/docs/concepts/extend-kubernetes/operator).

Flux is the operator that makes GitOps happen in your cluster. It ensures that the cluster config matches the one in git and automates your deployments (weave.works/oss/flux).

Helm is the "package manager for Kubernetes". Why does Kubernetes need a package manager, you might ask? A good example is installing flux. Rather than writing a bunch of manifest files to declare a deployment, services, service accounts, roles, cluster roles, role bindings, cluster role bindings, etc., we can simply use helm to install the flux operator.

$ helm repo add fluxcd https://charts.fluxcd.io
"fluxcd" has been added to your repositories
$ helm install flux fluxcd/flux \
  --set git.url="git@$GIT_HOST:$GIT_USER/$GIT_REPO" \
  --set git.path="k8s/common\,k8s/$CLUSTER_NAME" \
  --namespace flux

With Helm, you package your manifest files together into a Chart. A Chart is simply a collection of files laid out in a specific directory structure. Click the link to see more.

Helm comes with a templating language, making it easy to create re-usable charts. See Chart Template Guide: Getting Started.

There are other top-level folders in the project, but these are the most important:

.
├── charts
│   └── demo
│       ├── Chart.yaml
│       ├── values.yaml
│       └── templates
│           ├── _helpers.tpl
│           ├── aws-cron.yaml
│           ├── deployment.yaml
│           ├── hpa.yaml
│           └── service.yaml
└── k8s
    ├── common   # k8s manifest files common to all clusters (e.g., k8s-dashboard)
    │   ├── cluster-autoscaler-autodiscover.yaml
    │   └── kubernetes-dashboard
    │       ├── kubernetes-dashboard.yaml
    │       └── metrics-server.yaml
    ├── dev      # dev cluster manifest files
    │   └── demo.yaml
    ├── stage    # stage cluster manifest files
    │   └── demo.yaml
    └── prod     # prod cluster manifest files
        └── demo.yaml

The Helm Operator is a Kubernetes operator, allowing one to declaratively manage Helm chart releases. Combined with Flux this can be utilized to automate releases in a GitOps manner.

The desired state of a Helm release is described through a Kubernetes Custom Resource named HelmRelease. Based on the creation, mutation or removal of a HelmRelease resource in the cluster, Helm actions are performed by the operator (source).

A HelmRelease is a CRD (Custom Resource Definition). In Kubernetes, A Custom Resource is "an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation".

A side note on annotations: The HelmRelease objects in eks-gitops has an annotations block in the metadata section. Annotations are used pretty widely in Kubernetes and act like decorators in OO. Annotations "attach arbitrary non-identifying metadata to objects". Annotations can be used to create a desired side-effect.