Kubernetes follows a declarative approach to application management where users specify the desired state and an asynchronous control loop takes action if the current state does not match the desired state. This is a distinct difference to the more common imperative approaches of manual operations or the scripted approach of configuration management. Most importantly, it is the key design that enables Kuberenetes' rolling-updates, self-healing, auto-scaling and more.
To make declarative application management work, the desired state should be tracked in version control. As such, working with Kubernetes involves writing and maintaining a large number of manifests.
To do so sustainably requires consistent guidelines where manifests are maintained and how they are applied. Hint, our tools of choice are repositories and automation. No surprises there.
As the attentive reader notices, this is an opportunity to track and change deployment configuration the same way you track code changes and gain the same benefits of reviewability.
The rules of manifest maintenance
The first step is to clearly categorize manifests to make it intuitive to understand where to make a change to get a desired result.
Kubestack differentiates between two categories:
- Cluster service manifests
- Application manifests
Cluster Service Manifests
Because cluster service manifests are maintained and applied as part of the infrastructure automation repository and pipeline and are described there.
For the same reason that cluster service manifests are handled as part of the infrastructure automation, application manifests should be maintained in the same repository as the code of the application. If your application is composed of a set of microservices and you have separate repositories for each microservice, the manifests for each microservice go into that repository. If you manage all microservices in subdirectories of the same repository, the manifests go into the respective subdirectories.
Follow these best practices:
- have code, pipeline and desired state in the same repository
- make production settings the default, adapt development and stage environments, not the other way around
- pipeline runs triggered by a commit to master apply changes to the dev environment
- to apply changes to staging and production use tags
- to assemble apps from different repositories, consider a deployment repository that tracks the individual versions per environment