gistfile1.md

Introducing Conduit

In progress thoughts about introducing Conduit into our clusters.

CD pipelines

All our Kubernetes manifests are defined in Git and applied to the cluster via automated deployment pipelines. The standard procedure to deploy is to introduce a change to this git repo (these changes are themselves automated), which is then applied to the k8s cluster.

Conduit is a departure from this because it encourages an injection process which relies on an out of repo dependency (other than kubernetes itself). The objects that end up in Kubernetes are NOT defined in Git, and are a function of our own manifests plus the version of Conduit that happens to be installed locally (in the CD environment). This makes people nervous.

NB: It is possible to store the results of conduit inject in Git but this isn't encouraged, in the name of "transparency" (if I understand correctly). I understand the sentiment, although my initial thoughts is that this makes things less transparent, because I have no clear view of what is being pushed into our clusters. Nor is it stored in our git repos, so reproducability becomes more complex.

Infrastructure as code

Our configurations contain a higher level configuration file that describes how to apply k8s manifests to a cluster. This is an example.

kubectlApply:
  - api/deployment.yaml
  - api/service.yaml

We have introduced an experimental change that supports the following...

conduitInject:
  - api/deployment.yaml

Deployment objects listed in the conduitInject block are run through the conduit inject command before being applied to the cluster. This works as an experiment, but raises the following questions.\

• Is conduit install | kubectl apply -f - expected to be idempotent?

• What happens when different Deployments are injected by different versions of Conduit? Are these compatible between services? i.e a v0.3.0 injected Deployment is communicating with a v0.3.1 injected Deployment? Given the long-running nature of a k8s Deployment upgrade it seems like there has to be backwards compatibility, or we can't do no-downtime Deployments (unless we uninject/reinject?)

• More generally, what is expected backwards compatibility between different versions of the dashboard/api/data/cli components?

• Will conduit install | kubectl apply -f - provide clean upgrades between versions?