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.
.kubes/resources/basefolder is treated as a base layer. It gets processed as pre-layers by Kubes.
- Then Kubes will process your
- Lastly, Kubes processes any post-layers in the
Note, both YAML and DSL forms support layering.
Layering only combines resources definitions with the same form. For example, the DSL form
base/all.rb will not be combined with YAML form
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 an example of the structure:
.kubes/resources/ ├── base │ ├── all.yaml │ └── deployment.yaml └── web ├── deployment │ ├── dev.yaml │ └── prod.yaml ├── deployment.yaml └── service.yaml