Difference between revisions of "Kubernetes/Kustomize"

From Ever changing code
Jump to navigation Jump to search
Line 81: Line 81:
        └── virtual-service_patch.yaml
        └── virtual-service_patch.yaml


# Run
# Build kuctomized output
kustomize version --short # -> {kustomize/v3.8.2  2020-08-29T17:44:01Z  }
kustomize version --short # -> {kustomize/v3.8.2  2020-08-29T17:44:01Z  }
kustomize build overlays/dev  
kustomize build overlays/dev # apply patches
kustomize build base        # run common functions (as described in base/kustomize.yaml) against the whole code base
</source>
</source>


Line 89: Line 90:
What happens?
What happens?
# <code>kustomize build overlays/dev</code> finds <code>kustomization.yaml</code>, that describes:
# <code>kustomize build overlays/dev</code> finds <code>kustomization.yaml</code>, that describes:
* <code>patches: [gateway_patch.yaml, virtual-service_patch.yaml]</code> to be used over the base <code>resources: [../../base]</code>. There are 3 type of patches: patches, patchesStrategicMerge, [https://skryvets.com/blog/2019/05/15/kubernetes-kustomize-json-patches-6902 patchesJson6902] to choose from
## <code>patches: [gateway_patch.yaml, virtual-service_patch.yaml]</code> to be used over the base <code>resources: [../../base]</code>. There are 3 type of patches: patches, patchesStrategicMerge, [https://skryvets.com/blog/2019/05/15/kubernetes-kustomize-json-patches-6902 patchesJson6902] to choose from
# <code>overlays/dev/kustomization.yaml</code> cascades to the base (source of manifests to be changed) via directive <code>resources: ["../../base"]</code>
# <code>overlays/dev/kustomization.yaml</code> cascades to the base (source of manifests to be changed) via directive <code>resources: ["../../base"]</code>
# The base directory contains and runs its own <code>kustomization.yaml</code> file.
# The base directory contains and runs its own <code>kustomization.yaml</code> file.
# The <code>base/kustomization.yaml</code> contains common operations, eg. <code>commonLabels, namePrefix<code> functions to be applied to whole code base.
# The <code>base/kustomization.yaml</code> contains common operations, eg. <code>commonLabels, namePrefix</code> functions to be applied to whole code base.
# Then patch file(s) are applied eg. <code>gateway_patch.yaml</code> contains enough information to identify a resource/object and apply changes.
# Then patch file(s) are applied eg. <code>gateway_patch.yaml</code> contains enough information to identify a resource/object and apply changes.



Revision as of 01:38, 10 September 2020

Kustomize

kustomize lets you customize raw, template-free YAML files for multiple purposes, leaving the original YAML untouched and usable as is.

Install

# Detects your OS and downloads kustomize binary to cwd
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash

# Install on Linux - option2
VERSION=v3.8.2
curl -L https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize%2F${VERSION}/kustomize_${VERSION}_linux_amd64.tar.gz -o kustomize_${VERSION}_linux_amd64.tar.gz
tar xzvf kustomize_${VERSION}_linux_amd64.tar.gz
sudo install ./kustomize /usr/local/bin/kustomize

$ kustomize version --short
{kustomize/v3.8.2  2020-08-29T17:44:01Z  }


Kustomize build workflow

$ kustomize build ~/target
  1. load universal k8s object descriptions
  2. read kustomization.yaml from target
  3. kustomize bases (recurse 2-5)
  4. load and/or generate resources
  5. apply target's kustomization operations
  6. fix name references
  7. emit yaml

Example 101

TableHeadline
base/kustomization.yaml overlays/dev/kustomization.yaml overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
commonLabels:
  app: sonarqube
resources:
- gateway.yaml
- virtual-service.yaml
apiVersion: ...
kind: Kustomization
patches:
- gateway_patch.yaml
- virtual-service_patch.yaml
resources:
- ../../base
apiVersion: ...
kind: Kustomization
patches:
- gateway_patch.yaml
- virtual-service_patch.yaml
resources:
- ../../base
.
├── base
│   ├── gateway.yaml
│   ├── kustomization.yaml
│   └── virtual-service.yaml
└── overlays
    ├── dev
    │   ├── gateway_patch.yaml
    │   ├── kustomization.yaml
    │   └── virtual-service_patch.yaml
    └── prod
        ├── gateway_patch.yaml
        ├── kustomization.yaml
        └── virtual-service_patch.yaml

# Build kuctomized output
kustomize version --short # -> {kustomize/v3.8.2  2020-08-29T17:44:01Z  }
kustomize build overlays/dev # apply patches
kustomize build base         # run common functions (as described in base/kustomize.yaml) against the whole code base


What happens?

  1. kustomize build overlays/dev finds kustomization.yaml, that describes:
    1. patches: [gateway_patch.yaml, virtual-service_patch.yaml] to be used over the base resources: [../../base]. There are 3 type of patches: patches, patchesStrategicMerge, patchesJson6902 to choose from
  2. overlays/dev/kustomization.yaml cascades to the base (source of manifests to be changed) via directive resources: ["../../base"]
  3. The base directory contains and runs its own kustomization.yaml file.
  4. The base/kustomization.yaml contains common operations, eg. commonLabels, namePrefix functions to be applied to whole code base.
  5. Then patch file(s) are applied eg. gateway_patch.yaml contains enough information to identify a resource/object and apply changes.


So, what happens

# Applying path, overlays/dev/gateway_patch.yaml 
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: sonarqube 
spec:
  servers:
  - port:
      number: 443
      name: http
      protocol: HTTP
    hosts:
     - sonarqube-dev.acme.com # <- override
# | 
# | over the base
# v 
# base/gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: sonarqube
  labels:
    app: sonarqube
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - sonarqube-prod.acme.com
    port:
      number: 443
      name: http
      protocol: HTTP
# | 
# | results with
# v 
kustomize build overlays/dev
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  labels:
    app: sonarqube # <- labels added
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - sonarqube-dev.acme.com # <- what has been changed
    port:
      name: http
      number: 443
      protocol: HTTP

Known issues

In some settings it makes sense for commonLabels to be included in selectors, and in some settings it doers not make sense to include them in selectors. Kustomize includes by default, and there is no way to opt out. As workaround, you can convert matchLabels to matchExpressions and Kustomize won't touch them. API docs

- podSelector:
      matchLabels:
        app: mongodb-backup


is equivalent with

- podSelector:
      matchExpressions:
        - key: app
        operator: In
        values:
          - mongodb-backup

and Kustomize will keep its hands off.


Resources