Providing Feedback

Provide feedback at the survey

Experimental

Content in this chapter is experimental and will evolve based on user feedback.

Leave feedback on the conventions by creating an issue in the kubectl GitHub repository.

Also provide feedback on new kubectl docs at the survey

TL;DR
  • Use directory hierarchy to structure Resource Config
    • Separate directories for separate Environment and Cluster Config Variants

Directory Structure Based Layout

Motivation

Which is right for my organization?

While this chapter is focused on conventions when using Directories, Branches and Repositories should be used with Directories as needed.

Config Repo or Mono Repo?

The techniques and conventions in this Chapter work regardless of whether or not the Resource Config exists in the same Repository as the source code that is being deployed.

Directory Structure

Dir Type Deployed to a Cluster Contains Example Names
Base No - Used as base Shared Config. base/
Env No - Contains other dirs Base and Cluster dirs. test/, staging/, prod/
Cluster Yes - Manually or Continuously Deployable Config. us-west1, us-east1, us-central1

Bases

A Kustomize Base (e.g. bases:) provides shared Config that is customized by some consuming kustomization.yaml.

The directory structure outlined in this chapter organizes Bases into a hierarchy as: app-bases/environment-bases/cluster

Workflow Example

  • Changes made to env/cluster/ roll out to only that specific env-cluster
  • Changes made to env>/bases/ roll out to all clusters for that env
  • Changes made to bases/ roll out to all clusters in all envs

Diagram

graph TD; B("bases/ ")---|base|P("prod/bases/ "); B("bases/ ")---|base|S("staging/bases/ "); B("bases/ ")---|base|T("test/bases/ "); P("prod/bases/ ")---|base|PUW("prod/us-west/ "); P("prod/bases/ ")---|base|PUE("prod/us-east/ "); P("prod/bases/ ")---|base|PUC("prod/us-central/ "); S("staging/bases/ ")---|base|SUW("staging/us-west/ "); T("test/bases/ ")---|base|TUW("test/us-west/ ");

Scenario

  1. Alice modifies prod/us-west1 with change A
    • Change gets pushed to prod us-west1 cluster by continuous deployment
  2. Alice modifies prod/bases with change B
    • Change gets pushed to all prod clusters by continuous deployment
  3. Alice modifies bases with change C
    • Change gets pushed to all clusters by continuous deployment

Created with Raphaël 2.1.4

Techniques:

Structure:

  • Put reusable bases under */bases/
    • <project-name>/bases/
    • <project-name>/<environment>/bases/
  • Put deployable targets under <project-name>/<environment>/<cluster>/
tree
.
├── bases # Used as a Base only
│   ├── kustomization.yaml
│   ├── backend
│   │   ├── deployment.yaml
│   │   └── service.yaml
│   ├── frontend
│   │   ├── deployment.yaml
│   │   ├── ingress.yaml
│   │   └── service.yaml
│   └── storage
│       ├── service.yaml
│       └── statefulset.yaml
├── prod # Production
│   ├── bases 
│   │   ├── kustomization.yaml # Uses bases: ["../../bases"]
│   │   ├── backend
│   │   │   └── deployment-patch.yaml # Production Env specific backend overrides
│   │   ├── frontend
│   │   │   └── deployment-patch.yaml # Production Env specific frontend overrides
│   │   └── storage
│   │       └── statefulset-patch.yaml # Production Env specific storage overrides
│   ├── us-central
│   │   ├── kustomization.yaml # Uses bases: ["../bases"]
│   │   └── backend
│   │       └── deployment-patch.yaml # us-central cluster specific backend overrides
│   ├── us-east 
│   │   └── kustomization.yaml # Uses bases: ["../bases"]
│   └── us-west 
│       └── kustomization.yaml # Uses bases: ["../bases"]
├── staging # Staging
│   ├── bases 
│   │   ├── kustomization.yaml # Uses bases: ["../../bases"]
│   └── us-west 
│       └── kustomization.yaml # Uses bases: ["../bases"]
└── test # Test
    ├── bases 
    │   ├── kustomization.yaml # Uses bases: ["../../bases"]
    └── us-west 
        └── kustomization.yaml # Uses bases: ["../bases"]

Applying Environment + Cluster

Though the directory structure contains the cluster in the path, this won't be used by Apply to determine the cluster context. To Apply a specific cluster, add that cluster to the kubectl config`, and specify the corresponding context when running Apply.

For more information see Multi-Cluster.

Code Owners

Some git hosting services provide the concept of Code Owners for providing a finer grain permissions model. Code Owners may be used to provide separate permissions for separate environments - e.g. dev, test, prod.

Rollback Diagram

Created with Raphaël 2.1.4

results matching ""

    No results matching ""