在現在的開發過程中,常常需要使用差不多的程式碼部署到各種環境上。e.g. develop, staging, production
但在部署到不同的環境時,常常會有不同的設定檔需要維護,而kustomize就是希望能提供一個簡單清楚的方式,讓開發者可以將各個環境的設定檔都使用同一種規範並集中在一個資料夾中。
kustomize提供了類似於sed功能,將各個設定值藉由replace的方式,改寫到yaml中,達到同樣的base yaml卻能夠在不同的環境中,產生不同的設定。
也可以藉由 envsubst的方式,將env相關變數直接轉換到YAML中
Installation
- 使用homebrew安裝kustomize (mac限定)
brew install kustomize
- 使用binary安裝
https://kubectl.docs.kubernetes.io/installation/kustomize/binaries/
Introduction to Kustomize
1. 建立kustomization file
在原本資料夾中包含著你的YAML檔案 e.g. deployment, service, configmap, etc
先建立一個 kustomization
檔案,這個檔案會包含你要定義的resource與你想客製化的資訊,概念上是整個流程上的controller。
此時的檔案結構會像這樣~
~/example
├── kustomization.yaml
├── deployment.yaml
└── service.yaml
這個resource資料夾可以交給其他人直接使用,若是需要進行設定,也能夠藉由修改 kustomization.yaml
的方法,不必直接修改resource。
這時就可以使用 kustomize
build出簡單的成果了,使用方法如下
kustomize build ~/example
使用kustomize build後,只會將YAML用stdout的方式印出,再搭配kubectl就能夠直接建立資源了。
kustomize build ~/example | kubectl apply -f -
也可以很單純的直接使用kubectl apply -k的方式來達成
e.g. kubectl apply -k ~/example
2. 使用overlays資料夾建立多個環境
當今天我們有多個環境需要配置不同的設定時,kustomize
也能夠幫我們達成。
先建立出 base
與overlays
的資料夾,將剛剛的YAML檔案放進去base
,再根據需要的環境在overlays下分別建立出資料夾。要修改不同環境時,只需要在各別的環境資料夾中修改,減少可能影響到其他的環境的情況。
此時你的檔案結構可能會像這樣
~/example
├── base
│ ├── kustomization.yaml
│ ├── deployment.yaml
│ └── service.yaml
└── overlays
├── development
│ ├── cpu_count.yaml
│ ├── kustomization.yaml
│ └── replica_count.yaml
└── production
├── cpu_count.yaml
├── kustomization.yaml
└── replica_count.yaml
此時若是我們要在不同的環境build
kustomize build ~/example/overlays/production
要部署到k8s上,與base的方式相同,搭配著kubectl
kustomize build ~/example/overlays/production | kubectl apply -f -
Example
看完前面的介紹,我相信大家對kustomize想達到的功能都有一定了解,但是對於設定實際上要怎麼撰寫還是霧煞煞。
別擔心~
這邊提供給大家一個Hello world等級的範例,看完讓你頓時茅塞頓開。
檔案結構會像這樣,我們單純一點,環境分成develop與production,目前base資料夾下的設定,就是develop的設定,讓我們可以直接聚焦在怎麼進行base與overlays層面的設定。
~/example
├── base
│ ├── kustomization.yaml
│ └── deployment.yaml
└── overlays
└── production
├── kustomization.yaml
└── deployment.yaml
以下為base中的YAML檔案
kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
metadata:
name: arbitrary
commonLabels:
app: hello # 所有的resource都會被打上這個label
resources: # 設定有哪些yaml檔案
- deployment.yaml
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 1
selector:
matchLabels:
deployment: hello
template:
metadata:
labels:
deployment: hello
spec:
containers:q
- name: the-container
image: nginx
以下為overlays中的YAML檔案
kustomization.yaml
namePrefix: production- # 設定各個resource name的前綴
commonLabels: # 所有的resource都會被打上這個label
variant: production
org: acmeCorporation
commonAnnotations: # 所有的resource都會被打上這個Annotations
note: Hello, I am production!
resources: # resources YAML的存放位置
- ../../base
patchesStrategicMerge: # 要被讀取進來的新設定檔
- deployment.yaml
deployment.yaml
這個為新設定的deployment資訊,在base中的replicas為1,經過下面這樣的設定後,就會將base中的replicas更改為3。
apiVersion: apps/v1
kind: Deployment
metadata:
name: the-deployment
spec:
replicas: 3
我們來使用這樣的設定跑一次build看看結果
$ kustomize build overlays/production
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
note: Hello, I am production!
labels:
app: hello
org: acmeCorporation
variant: production
name: production-the-deployment
spec:
replicas: 3
selector:
matchLabels:
app: hello
deployment: hello
org: acmeCorporation
variant: production
template:
metadata:
annotations:
note: Hello, I am production!
labels:
app: hello
deployment: hello
org: acmeCorporation
variant: production
spec:
containers:
- image: monopole/hello:1
name: the-container
結果跟你預期的是一樣的嗎?
當然kustomize 可以做到更複雜的操作,但我們今天的學習就先到這邊就好。
可以去想想如果要套入CI/CD pipline怎麼自動更換掉image tag
那我們下次見~
Reference
在現在的開發過程中,常常需要使用差不多的程式碼部署到各種環境上。e.g. develop, staging, production
但在部署到不同的環境時,常常會有不同的設定檔需要維護,而kustomize就是希望能提供一個簡單清楚的方式,讓開發者可以將各個環境的設定檔都使用同一種規範並集中在一個資料夾中。
kustomize提供了類似於sed功能,將各個設定值藉由replace的方式,改寫到yaml中,達到同樣的base yaml卻能夠在不同的環境中,產生不同的設定。
Installation
https://kubectl.docs.kubernetes.io/installation/kustomize/binaries/
Introduction to Kustomize
1. 建立kustomization file
在原本資料夾中包含著你的YAML檔案 e.g. deployment, service, configmap, etc
先建立一個
kustomization
檔案,這個檔案會包含你要定義的resource與你想客製化的資訊,概念上是整個流程上的controller。此時的檔案結構會像這樣~
這個resource資料夾可以交給其他人直接使用,若是需要進行設定,也能夠藉由修改
kustomization.yaml
的方法,不必直接修改resource。這時就可以使用
kustomize
build出簡單的成果了,使用方法如下使用kustomize build後,只會將YAML用stdout的方式印出,再搭配kubectl就能夠直接建立資源了。
2. 使用overlays資料夾建立多個環境
當今天我們有多個環境需要配置不同的設定時,
kustomize
也能夠幫我們達成。先建立出
base
與overlays
的資料夾,將剛剛的YAML檔案放進去base
,再根據需要的環境在overlays下分別建立出資料夾。要修改不同環境時,只需要在各別的環境資料夾中修改,減少可能影響到其他的環境的情況。此時你的檔案結構可能會像這樣
此時若是我們要在不同的環境build
要部署到k8s上,與base的方式相同,搭配著kubectl
Example
看完前面的介紹,我相信大家對kustomize想達到的功能都有一定了解,但是對於設定實際上要怎麼撰寫還是霧煞煞。
別擔心~
這邊提供給大家一個Hello world等級的範例,看完讓你頓時茅塞頓開。
檔案結構會像這樣,我們單純一點,環境分成develop與production,目前base資料夾下的設定,就是develop的設定,讓我們可以直接聚焦在怎麼進行base與overlays層面的設定。
以下為base中的YAML檔案
kustomization.yaml
deployment.yaml
以下為overlays中的YAML檔案
kustomization.yaml
deployment.yaml
這個為新設定的deployment資訊,在base中的replicas為1,經過下面這樣的設定後,就會將base中的replicas更改為3。
我們來使用這樣的設定跑一次build看看結果
結果跟你預期的是一樣的嗎?
當然kustomize 可以做到更複雜的操作,但我們今天的學習就先到這邊就好。
可以去想想如果要套入CI/CD pipline怎麼自動更換掉image tag
那我們下次見~
Reference