In lesson W1.2 you described the Kladde as manifests under k8s/: a deployment for kladde-web, one for kladde-worker, a service, a ConfigMap.
That is enough for one cluster. As soon as there are two, one for dev and one for prod, the copying begins: a different image, a different
number of replicas, different limits, a different Service Bus namespace. Two folders with almost identical files drift apart, and nobody can
tell any more what is different on purpose and what was simply forgotten.
This lesson answers one question: How do the manifests of an application stay a single source, even when they run in several environments with different values? In the Kubernetes world, the answer is usually Helm. You build the Kladde's chart, install it, go back after an error, and learn to check a chart from other people before it is allowed into your cluster.
The problem with copies
An example from the Kladde. The web app's deployment differs between dev and prod in a few places:
| What | dev |
prod |
|---|---|---|
| Replicas | 1 | 3 |
| CPU and memory limits | small | larger |
| Log level | Debug |
Warning |
| Address of the Service Bus namespace | sb-kladde-dev |
a namespace of its own |
Everything else, the probes, the port, the labels, the service, the identity, is the same. Maintaining one copy per environment means keeping the same forty lines correct twice. There are two ways out: templates into which you insert values (Helm), and patches that you lay over a common base (Kustomize, at the end of this lesson). Both do away with the copies.