A Kubernetes manifest is a declarative configuration document describing resources and their desired state. For a service, it defines how its container is deployed into a Kubernetes cluster. Keep the manifest with the service source and Dockerfile so a service pipeline can verify and version the deployment configuration alongside the image it builds. section 3.4 section 3.4.2
Choose how to distribute the configuration according to who needs to install the service:
- For a few teams and environments, distribute the YAML files without a packaging tool. section 3.4
- When many installations need a versioned package, use a Helm Chart. The pipeline can version it with the binary and container image and publish it to a repository. section 3.4 section 3.4.2
Deployment is a separate concern. An environment repository records which services should be present; an environment pipeline reads that configuration and applies it to the target cluster. The service pipeline produces deployable artifacts but does not choose a specific environment for them. section 3.4 section 4.1.4
From YAML files to an environment
A simple environment repository holds Kubernetes YAML files, and its pipeline runs `kubectl apply -f *` against the configured cluster. If those files also live in service repositories, the copies can drift apart across environments. Alternatives include a parent Helm Chart with service dependencies or a helmfile whose declared releases are created with `helmfile sync`. section 4.1.4
Figure 3.6 The service source code repository needs to have all the configurations for the service pipeline to work.
The service repository layout places source, Dockerfile, and Helm Chart configuration together, showing what a pipeline needs to build and package a deployable service. section 3.4.2
Do not add Helm packaging merely because the pipeline can support it. Add that step when distributing manifests as packages solves a real installation or release problem. section 3.4.3
