Kubes Layering in it’s full form allows you to keep your resource definitions DRY and create different environments with the same code.
Here’s an example structure, so we can understand how layering works.
.kubes/resources/ ├── base │ ├── all.yaml │ └── deployment.yaml ├── clock │ └── deployment.yaml └── web ├── deployment │ ├── dev.yaml │ └── prod.yaml ├── deployment.yaml └── service.yaml
To explain the layering, here’s the general processing order that Kubes takes.
- Pre Layers: The
.kubes/resources/basefolder is treated as a base layer. It gets processed as pre-layers by Kubes.
- Main Layer: Then Kubes will process your
- Post Layers: Lastly, Kubes processes any post-layers in the
- Both YAML and DSL forms support layering. They can be mixed together.
- In the Main Layer you can define single or multiple resource definitions.
Here’s a table showing the the full layering.
- With Kubes layering you can define common fields in
base/all.yaml. Examples: namespace, labels, annotations. If you have additional common base-level fields, but are specific to a Kind. Then you can defined them in
- Then you can define the core of your resource definition in the
- Finally, you can provide environment-specific overrides in the
Here’s a concrete example of layering with the deployment resource kind:
.kubes/resources/base/all.yaml .kubes/resources/base/deployment.yaml .kubes/resources/web/deployment.yaml .kubes/resources/web/deployment/dev.yaml
All of these files get layered and merged together to produce a resulting deployment.yaml