How to Flux

How Flux Works

1. You've got a config repo where you keep your HelmReleases for a given cluster. Flux polls this periodically for manifest changes (based on the git-path you specify) and applies them.

2. developer adds annotations to HelmRelease to tell flux to watch their upstream docker images.

3. developer merges code to main in app-specific repo

4. CI tool builds, tags and pushes image

5. Flux detects the changed image because of the annotation on the HelmRelease file, triggers an upgrade

6. Flux writes new tag back to HelmRelease file in config repo using ci-skip

A quote from the flux maintainers

In order to apply the GitOps pipeline model to Kubernetes you need three things:
* a Git repository with your workloads definitions in YAML format, Helm charts and any other Kubernetes custom resource that defines your cluster desired state (I will refer to this as the config repository)

* a container registry where your CI system pushes immutable images (no latest tags, use semantic versioning or git commit sha)

* an operator that runs in your cluster and does a two-way synchronization:
  * watches the registry for new image releases and based on deployment policies updates the workload definitions with the new image tag and commits the changes to the config repository
  * watches for changes in the config repository and applies them to your cluster

Notes

1. So how does kustomize and .flux.yaml fit into all this? kustomize is a templating ("manifest factorization") thing that uses a yaml patching strategy for overriding values in manifests. You'd use it to maintain staging vs prod stuff. To implement it you include a .flux.yaml file in your repo which points to the kustomize command, and set manifest-generation=true in fluxd.

2. How many fluxii should I run per cluster? No more than one flux per cluster; flux runs memcached and redis with it, it's a cluster-wide service.

Configuring the cluster

1. Prerequisites:

• Kubernetes cluster
• Helm v3

curl -L https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

• Helm Operator

helm upgrade -i helm-operator fluxcd/helm-operator --namespace default --set helm.versions=v3

• A config repo. Directory structure:

* itse-apps-prod-1-infra
  - terraform
    * main.tf
  - k8s
    * workloads
    * releases
      - mozalert-controller.yaml
    * namespaces
      - mozalert.yaml
      - flux.yaml
      - prometheus.yaml

2. Create flux namespace

kubectl create ns flux

3. Install Flux via Helm

# git.user and git.email set the committer Flux uses
# for the post-upgrade push to the config repo

# git.url, git.branch and git.path define the config
# repo location and which directories to watch for manifest
# changes
helm upgrade -i flux fluxcd/flux \
        --set git.user=mozafrank \
        --set git.email=mozafrank@users.noreply.github.com \
        --set git.url=git@github.com:mozafrank/afrank-dev-infra \
        --set git.path="namespaces\,releases" \
        --set git.branch=main \
        --namespace=flux

git.user and git.email are used as the committer for the push flux does after an upgrade.

Flux polls git.url every few minutes for changes and applies them. It applies any kubernetes manifests it finds. If the manifests have the flux annotations, Flux will also start watching the resource's images in the image registry.

4. Get the ssh pubkey flux created for itself

fluxctl identity --k8s-fwd-ns flux

5. Add that key as a deploy key with write access to the git repo you set as git.url

Configuring an app

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: mozalert-controller
  namespace: mozalert
  annotations:
    fluxcd.io/automated: "true"
    fluxcd.io/tag.chart-image: glob:stg-*
spec:
  releaseName: mozalert-controller
  chart:
    git: https://github.com/mozafrank/helm-charts
    ref: main
    path: charts/mozalert-controller
  values:
    image:
      repository: afrank/mozalert-controller
      tag: latest
      pullPolicy: Always
    secretRef: mozalert-dev-secrets