技術分享與學習資源

Kubernetes 簡單學 : 領進 kustomize 修行在個人

在現在的開發過程中，常常需要使用差不多的程式碼部署到各種環境上。e.g. develop, staging, production 但在部署到不同的環境時，常常會有不同的設定檔需要維護，而 kustomize 就是希望能提供一個簡單清楚的方式，讓開發者可以將各個環境的設定檔都使用同一種規範並集中在一個資料夾中。

kustomize 提供了類似於 sed 功能，將各個設定值藉由 replace 的方式，改寫到 yaml 中，達到同樣的 base yaml 卻能夠在不同的環境中，產生不同的設定。

也可以藉由 envsubst 的方式，將 env 相關變數直接轉換到 YAML 中

Installation

1. 使用 homebrew 安裝 kustomize (mac限定)

				
					brew install kustomize

2. 使用 binary 安裝
https://kubectl.docs.kubernetes.io/installation/kustomize/binaries/

Introduction to Kustomize

1. 建立k ustomization 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 -

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
這個為新設定的 deploymen t資訊，在 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

https://github.com/kubernetes-sigs/kustomizehttps://kubectl.docs.kubernetes.io/guides/introduction/kustomize/

AWS Advanced Consulting Partner┃ Netron網創資訊

Netron網創資訊為擁有豐富上雲經驗的 AWS 代理商，更是 AWS 進階合作夥伴，並取得AWS MSP、MSSP、Migration、Generative AI Competency 認證資格。擁有兩百多張平台認證的技術維運團隊也深受 AWS 原廠信賴，Netorn網創資訊結合自身多雲平台、資安防護、AI、Big Data 等關鍵技術，都能為企業提供全方位的 AWS 雲端服務，可給予企業最專業的 AWS 雲端架構規劃與設計諮詢。

如需進一步了解我們的公部門雲端服務解決方案，歡迎聯絡我們。

返回頂端