昨天我們認識了 Kustomize 這個 Kubernetes 原生的配置管理工具。從實際的痛點出發,了解到當需要在多個環境部署相同應用時,複製和維護多份 YAML 檔案會造成管理上的困難。Kustomize 透過 Base 和 Overlays 的概念解決了這個問題,讓我們能夠重複使用基礎配置,只針對不同環境修改需要變更的部分。
昨天我們只看了 Kustomize 的基礎功能。今天我們將深入研究 Kustomize 真正強大的地方:Transformers 和 Patches。這些進階功能讓我們能夠精確地修改資源配置、管理不同環境的映像檔版本、建立可重用的配置片段,真正發揮 Kustomize 在多環境部署管理上的威力。
Transformers 是 Kustomize 提供的統一修改機制,讓我們能夠對多個資源進行批次性的配置調整,而不需要逐一修改每個 YAML 檔案。這種批次修改的能力在管理大量資源時特別有用,能大幅減少重複工作並降低人為錯誤的機率。
當我們需要對所有 Kubernetes 資源進行統一的配置修改時,Common Transformers 就是最佳選擇。比如說,我們想為所有資源加上公司的標籤、統一 Namespace、或是添加共同的前綴後綴,這些都可以透過 Transformers 輕鬆完成。
Kustomize 提供了幾種常用的 Transformers:
這些 Transformers 的強大之處在於作用範圍的靈活性。如果在根目錄的 kustomization.yaml
中定義時,它會影響所有被引入的資源;而如果在子目錄中定義時,則只會影響該目錄下的資源。這種階層式的設計讓配置管理變得非常靈活,可以在全域層級設定共通規則,同時在特定子系統中套用額外的規則。
讓我們透過實際操作來理解 Common Transformers 的威力。首先看看我們的資料夾結構:
k8s/
├── kustomization.yaml
├── db/
│ ├── kustomization.yaml
│ ├── nosql/
│ ├── sql/
│ └── db-config.yaml
├── monitoring/
│ ├── kustomization.yaml
│ ├── grafana-depl.yaml
│ └── grafana-service.yaml
└── nginx/
├── kustomization.yaml
├── nginx-depl.yaml
└── nginx-service.yaml
情境 1:全域標籤設定
假設我們希望所有子目錄的資源都帶有 sandbox: dev
標籤,只需要在根目錄的 kustomization.yaml
中定義:
# k8s/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- db/
- monitoring/
- nginx/
labels:
- includeSelectors: true
pairs:
sandbox: dev
注意:我在實戰中有遇到 Warning 訊息,表示新版本中
commonLabels
已被labels
取代。
這樣一來,db、monitoring、nginx 三個子系統的所有資源都會自動加上這個標籤,不需要在每個 YAML 檔案中重複定義。
情境 2:特定子系統的名稱前綴
現在我們希望所有資料庫相關的資源名稱都以 data-
開頭,這樣可以一眼辨識出這些是資料層的元件:
# k8s/db/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nosql/
- sql/
- db-config.yaml
namePrefix: data-
執行 kubectl build k8s/
後,會看到所有 db 目錄下的資源名稱都被加上了 data-
前綴,例如原本的 postgres-deployment
會變成 data-postgres-deployment
。這種做法的好處是保持了原始 YAML 的乾淨,同時又能在部署時自動套用命名規則。
情境 3:隔離命名空間
監控工具通常會獨立部署在專屬的 namespace 中,方便管理和權限控制。我們可以透過 namespace
transformer 來實現:
# k8s/monitoring/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- grafana-depl.yaml
- grafana-service.yaml
namespace: logging
這樣 monitoring 資料夾下的所有資源都會被部署到 logging
這個 namespace,而不會影響其他子系統。這種隔離不僅有助於資源管理,也能提供更好的安全邊界。
情境 4:批次添加註釋
如果我們想在 nginx 和 monitoring 的所有資源上標註負責人資訊,可以使用 commonAnnotations
:
# k8s/monitoring/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- grafana-depl.yaml
- grafana-service.yaml
namespace: logging
commonAnnotations:
owner: bob@gmail.com
# k8s/nginx/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nginx-depl.yaml
- nginx-service.yaml
commonAnnotations:
owner: bob@gmail.com
這樣做的好處是,當團隊成員看到這些資源時,能立即知道該聯繫誰。對於 GitOps 工具來說,annotations 也常被用來觸發特定的自動化流程。
Image Transformers 專門用來管理容器映像檔的版本和來源,這是多環境部署中最常需要調整的配置之一。在不同環境中,我們經常需要使用不同版本的映像檔,或是從不同的 Registry 拉取映像檔。傳統做法需要在每個環境的 YAML 中手動修改 image 欄位,但 Image Transformer 讓這個過程變得優雅且可控。
透過指定 name
和 newName
,可以替換所有使用特定映像檔的容器。如果只想更新標籤,可以使用 newTag
屬性。這在升級應用版本或是回滾時特別有用,不需要修改任何 YAML 檔配置,只要在 kustomization.yaml
中調整映像檔設定即可。更重要的是,這種方式讓版本管理變得集中化,我們可以在一個地方控制所有環境使用的映像檔版本。
值得注意的是,Image Transformer 是根據映像檔名稱來匹配的,而不是容器名稱。它會掃描所有資源,找出使用指定映像檔的容器並進行替換,因此在根目錄使用時需要特別注意影響範圍,避免誤改到不該改的映像檔。
情境 1:全域映像檔替換
假設我們的資料庫原本使用 PostgreSQL,但現在要全面改用 MySQL。透過 Image Transformer,我們可以在根目錄一次性替換所有 PostgreSQL 映像檔:
# k8s/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- db/
- monitoring/
- nginx/
labels:
- includeSelectors: true
pairs:
sandbox: dev
images:
- name: postgres
newName: mysql
執行後,所有原本使用 postgres
映像檔的容器都會自動改用 mysql
。這種做法避免了在多個 YAML 檔中逐一修改,大幅降低了出錯的機率。
情境 2:特定子系統的版本控制
如果我們只想針對 nginx 子系統指定特定版本,可以在該子系統的 kustomization.yaml
中定義:
# k8s/nginx/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- nginx-depl.yaml
- nginx-service.yaml
commonAnnotations:
owner: bob@gmail.com
images:
- name: nginx
newTag: "1.23"
這樣只有 nginx 資料夾下的 nginx 映像檔會被指定為 1.23 版本,其他地方的 nginx 映像檔(如果有的話)不會受影響。這種細緻的控制能力讓我們可以針對不同子系統採用不同的版本策略,例如讓前端服務使用最新版本,而讓核心服務保持在穩定版本。
Patches 提供了更精確的修改方式,讓我們能針對特定資源的特定欄位進行修改。不同於 Common Transformers 的全域修改,Patches 允許我們只改變需要改變的部分,其他配置保持原樣。這種精準控制在處理複雜配置時特別重要,因為有些修改只應該影響特定的資源。
Kustomize 提供兩種 Patch 方式:JSON 6902 Patch
和 Strategic Merge Patch
,各有其適用場景和優勢。
JSON 6902 Patch 遵循 RFC 6902 標準,使用操作指令來修改資源。這種方式的特點是明確和精確,每一個修改動作都清楚地定義了要做什麼。每個 Patch 需要三個要素:
add
(新增)、remove
(刪除)、replace
(替換)remove
操作不需要此欄位)路徑的指定是使用 JSON 6902 Patch 的關鍵。路徑使用 JSON Pointer 語法,以 /
分隔各層級。例如要修改 Deployment 的 replicas,路徑是 /spec/replicas
;對於列表類型的資源,需要使用索引來指定位置,例如 /spec/template/spec/containers/0
代表第一個容器。
# 修改 replicas
patches:
- target:
kind: Deployment
name: api-deployment
patch: |-
- op: replace
path: /spec/replicas
value: 5
# 修改 Container Image
patches:
- target:
kind: Deployment
name: api-deployment
patch: |-
- op: replace
path: /spec/template/spec/containers/0
value:
name: haproxy
image: haproxy
JSON 6902 Patch 的優勢在於明確性和可預測性,清楚知道每個操作會造成什麼影響。但缺點是需要精確知道資源的結構和路徑,對於列表類型的資源,索引的維護也可能成為負擔。
Strategic Merge Patch 的方式更直觀和符合 Kubernetes 使用者的習慣。我們只需要寫出想要修改的部分 YAML,Kustomize 會智慧地將它與原始配置合併。這種方式的最大好處是可讀性高,因為它就是標準的 Kubernetes YAML,不需要學習特殊的語法或記住複雜的路徑。
# 修改 replicas
patches:
- patch: |-
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
replicas: 5
# 修改 Container Image
patches:
- patch: |-
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- name: haproxy
image: haproxy
對於字典類型的資源,Strategic Merge Patch 會智慧地合併鍵值對。如果要刪除某個鍵,需要將值設為 null
。對於列表類型的資源,Kubernetes 會根據特定的合併策略來處理,例如容器列表會根據容器名稱來匹配和合併。
如果要從列表中刪除某個項目,需要使用特殊的 $patch: delete
指令。這是 Strategic Merge Patch 處理列表刪除的標準方式。
讓我們看看實際場景中如何運用這兩種 Patch 方式。先看看專案結構:
k8s/
├── kustomization.yaml
├── mongo-depl.yaml
├── nginx-depl.yaml
├── api-depl.yaml
├── mongo-service.yaml
└── mongo-label-patch.yaml
情境 1:使用 JSON 6902 Patch 進行多項修改
在 kustomization.yaml
中,我們可以針對不同資源進行不同的修改:
resources:
- mongo-depl.yaml
- nginx-depl.yaml
- mongo-service.yaml
patches:
# 修改 nginx 的副本數
- target:
kind: Deployment
name: nginx-deployment
patch: |-
- op: replace
path: /spec/replicas
value: 3
# 從外部檔案載入 mongo 的 patch 規則
- target:
kind: Deployment
name: mongo-deployment
path: mongo-label-patch.yaml
# 同時修改 Service 的多個欄位
- target:
kind: Service
name: mongo-cluster-ip-service
patch: |-
- op: replace
path: /spec/ports/0/port
value: 30000
- op: replace
path: /spec/ports/0/targetPort
value: 30000
注意到 mongo-deployment
的 patch 規則被寫在獨立檔案中。當 patch 內容較多時,將其拆分到獨立檔案能提高可讀性:
# mongo-label-patch.yaml
- op: add
path: /spec/template/metadata/labels/cluster
value: staging
- op: add
path: /spec/template/metadata/labels/feature
value: db
這個實戰展示了如何為 Deployment 的 Pod template 添加新的標籤。路徑 /spec/template/metadata/labels/cluster
精確指定了要在哪裡添加新標籤。
情境 2:使用 Strategic Merge Patch 新增資源
現在讓我們改用更直觀的 Strategic Merge Patch。假設我們要為 mongo 添加持久化儲存,為 api 添加快取容器:
# mongo-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mongo-deployment
spec:
template:
spec:
containers:
- name: mongo
volumeMounts:
- mountPath: /data/db
name: mongo-volume
volumes:
- name: mongo-volume
persistentVolumeClaim:
claimName: host-pvc
這個 patch 為 mongo 容器添加了 volume mount 和 PVC。Strategic Merge Patch 會智慧地將這些配置合併到原始的 Deployment 中,不需要重複寫整個 Deployment 定義。
# api-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- name: memcached
image: memcached
這個 patch 在 api-deployment 中新增了一個 memcached
容器。讓我們看看原始的 api-depl.yaml
:
# api-depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
replicas: 1
selector:
matchLabels:
component: api
template:
metadata:
labels:
component: api
spec:
containers:
- name: nginx
image: nginx
- name: memcached
image: memcached
情境 3:Strategic Merge Patch 刪除容器
如果我們後來決定不需要 memcached 快取了,可以使用 $patch: delete
指令來移除它:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- $patch: delete
name: memcached
這個特殊的 $patch: delete
指令告訴 Kustomize 要刪除名為 memcached 的容器。Kubernetes 會根據容器的 name
欄位來識別並刪除對應的容器。
情境 4:使用 JSON 6902 Patch 刪除標籤
現在讓我們用 JSON 6902 Patch 來移除 mongo-deployment
的標籤。先看看原始的配置:
# mongo-depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mongo-deployment
spec:
replicas: 1
selector:
matchLabels:
component: mongo
template:
metadata:
labels:
component: mongo
org: IThome
spec:
containers:
- name: mongo
image: mongo
要刪除 org: IThome
標籤,在 kustomization.yaml
中使用 remove
操作:
resources:
- mongo-depl.yaml
- api-depl.yaml
- mongo-service.yaml
patches:
- target:
kind: Deployment
name: mongo-deployment
patch: |-
- op: remove
path: /spec/template/metadata/labels/org
這個實戰看到 JSON 6902 Patch 在刪除特定欄位時的精確性。路徑明確指向要刪除的標籤鍵,不會影響其他標籤。
兩種 Patch 方式的選擇建議:
Overlays 是 Kustomize 實現多環境管理的核心機制,也是它最能展現價值的地方。透過在不同的 overlay 目錄中定義環境特定的 patches 和額外資源,我們可以從同一個 base 配置衍生出適合開發、測試、預發布、生產等不同環境的配置。這種方式完美實踐了 DRY(Don't Repeat Yourself)原則,讓我們能夠維護單一來源的真實配置,同時又能靈活地為每個環境客製化。
每個 overlay 都有自己的 kustomization.yaml
,其中透過 resources
屬性(舊版使用 bases
)引用 base 配置,然後定義該環境特有的修改。這不僅限於 patches,也可以在 overlay 中加入該環境獨有的資源,比如只在生產環境中啟用的監控元件、只在開發環境需要的除錯工具等。
resources:
- ../../base
resources:
- redis-depl.yaml
patch: |-
- op: replace
path: /spec/replicas
value: 5
這種設計讓環境之間的差異變得明確且易於管理。當我們需要了解生產環境和開發環境有什麼不同時,只需要查看對應的 overlay 目錄即可,不需要逐一比對完整的 YAML 檔案。
讓我們透過一個完整的多環境專案來理解 Overlays 的實際應用。這是我們的專案結構:
k8s/
├── base/
│ ├── kustomization.yaml
│ ├── api-deployment.yaml
│ ├── db-configMap.yaml
│ ├── mongo-depl.yaml
│ └── mysql-depl.yaml
└── overlays/
├── dev/
│ └── kustomization.yaml
├── staging/
│ ├── kustomization.yaml
│ └── configMap-patch.yaml
├── QA/
│ └── kustomization.yaml
└── prod/
├── kustomization.yaml
├── api-patch.yaml
└── redis-depl.yaml
注意:我有遇到 Warning 訊息表示新版本中
bases
欄位已被resources
取代。
情境 1:生產環境的映像檔選擇
首先來看 base 中的 API deployment 基礎配置:
# /k8s/base/api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
replicas: 2
selector:
matchLabels:
component: api
template:
metadata:
labels:
component: api
spec:
containers:
- name: api
image: nginx
env:
- name: DB_CONNECTION
value: db.kodekloud.com
基礎配置中使用的是 nginx。但在生產環境,我們想使用效能更好的 memcached 作為快取層:
# /k8s/overlays/prod/kustomization.yaml
resources:
- ../../base
- redis-depl.yaml # 生產環境獨有的 Redis
patches:
- api-patch.yaml
# /k8s/overlays/prod/api-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- name: api
image: memcached
這個實戰展示了幾個重要概念:
resources: - ../../base
繼承了所有基礎配置redis-depl.yaml
只在生產環境部署,開發和測試環境不需要情境 2:預發布環境的密碼管理
在 staging 環境,我們需要使用不同的資料庫憑證。先看 base 中的 ConfigMap:
# /k8s/base/db-configMap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: db-creds
data:
username: admin
password: default123
在 staging overlay 中覆寫這些憑證:
# /k8s/overlays/staging/kustomization.yaml
resources:
- ../../base
patches:
- configMap-patch.yaml
# /k8s/overlays/staging/configMap-patch.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: db-creds
data:
username: mongo
password: superp@ssword123
這個 Strategic Merge Patch 會覆寫 base 中的 username 和 password,但保留 ConfigMap 的其他屬性(如果有的話)。這種做法確保每個環境使用正確的憑證,而不會在 base 中暴露敏感資訊。
情境 3:QA 環境使用不同的 Web Server
QA 團隊想測試新的 Caddy web server,但不想影響其他環境。我們可以針對 QA 環境進行映像檔替換:
# /k8s/overlays/QA/kustomization.yaml
resources:
- ../../base
labels:
- includeSelectors: true
pairs:
environment: QA
patches:
- target:
kind: Deployment
name: api-deployment
patch: |-
- op: replace
path: /spec/template/spec/containers/0/image
value: caddy
這裡同時展示了兩個功能:
environment: QA
標籤,方便追蹤和管理部署到 QA 環境:
kubectl apply -k /k8s/overlays/QA
情境 4:Staging 環境的專屬資料庫
假設 staging 環境需要獨立的 MySQL 資料庫進行整合測試。我們可以在 staging overlay 中添加這個資源:
首先建立 MySQL deployment 配置:
# /k8s/base/mysql-depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 1
selector:
matchLabels:
component: mysql
template:
metadata:
labels:
component: mysql
org: Ithome
spec:
containers:
- name: mysql
image: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: mypassword
然後在 base 的 kustomization.yaml 中註冊這個資源:
# /k8s/base/kustomization.yaml
resources:
- api-deployment.yaml
- db-configMap.yaml
- mongo-depl.yaml
- mysql-depl.yaml
現在當我們部署 staging 環境時,它就會包含 MySQL:
kubectl apply -k /k8s/overlays/staging
這個實戰展示了 Overlays 的靈活性:我們在 base 中定義了 MySQL 配置,但可以選擇性地在不同環境中部署或不部署它。如果某個環境不需要 MySQL,只要在其 overlay 的 kustomization.yaml 中不引用即可。
Overlays 的最佳實踐:
Components 是 Kustomize 中較新但極為實用的功能,它解決了「某些功能只在部分環境中啟用」的問題。這是一個在實務中經常遇到的場景:比如快取功能只在生產和預發布環境啟用,而開發環境不需要;或是日誌收集系統只在特定環境部署。
如果把這些可選功能放在 base 中,所有環境都會有,這不是我們想要的。如果複製到各個需要的 overlay 中,又違反了 DRY(Don't Repeat Yourself)原則,造成維護上的困擾。每次修改這些功能時,都需要在多個地方同步更新。
Components 提供了第三種更優雅的選擇:將這些可選功能打包成獨立的元件,然後在需要的 overlay 中引用。一個 Component 可以包含資源定義、patches、secrets、ConfigMaps 等所有相關配置,形成一個完整的功能模組。透過在 overlay 的 kustomization.yaml
中列出需要的 components,就能像組裝樂高積木一樣靈活地組合功能。
這種模組化的設計不僅提高了配置的可重用性,也讓環境配置變得更加語義化。當看到某個 overlay 引用了 auth、logging、caching 這些 components,就能立即理解該環境包含哪些功能。
一個典型的 Component 包含自己的 kustomization.yaml
,但 kind 設定為 Component
而非 Kustomization
:
# components/db/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
resources:
- postgres-depl.yaml
secretGenerator:
- name: postgres-cred
literals:
- password=postgres123
patches:
- deployment-patch.yaml
這個資料庫 Component 包含了:
對應的 patch 檔案:
# components/db/deployment-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- name: api
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: postgres-cred
key: password
在需要資料庫的環境中引用這個 Component:
# overlays/prod/kustomization.yaml
resources:
- ../../base
components:
- ../../components/db
這樣 production 環境就會自動包含 PostgreSQL 及其相關配置,而開發環境如果不需要資料庫,完全不用引用這個 Component。
現在讓我們透過一個實際專案來深入理解 Components 的威力。這是我們的專案結構:
project_mercury/
├── base/
│ ├── kustomization.yaml
│ └── api-deployment.yaml
├── components/
│ ├── auth/
│ │ ├── kustomization.yaml
│ │ ├── keycloak-depl.yaml
│ │ └── api-patch.yaml
│ ├── logging/
│ │ ├── kustomization.yaml
│ │ ├── fluentd-depl.yaml
│ │ └── api-patch.yaml
│ └── caching/
│ ├── kustomization.yaml
│ ├── redis-depl.yaml
│ ├── redis-service.yaml
│ └── api-patch.yaml
└── overlays/
├── community/
│ └── kustomization.yaml
├── enterprise/
│ └── kustomization.yaml
└── premium/
└── kustomization.yaml
情境 1:社群版只需基本功能
社群版(community)是免費版本,只提供基本功能和身份驗證:
# /overlays/community/kustomization.yaml
resources:
- ../../base
components:
- ../../components/auth
這個配置清楚表達:社群版 = 基礎功能 + 身份驗證,不包含日誌收集和快取等進階功能。
情境 2:為社群版增加日誌功能
假設我們決定讓社群版也能收集日誌以改善用戶支援。只需要在 kustomization.yaml 中添加 logging component:
# /overlays/community/kustomization.yaml
resources:
- ../../base
components:
- ../../components/auth
- ../../components/logging
部署這個更新:
kubectl apply -k /root/code/project_mercury/overlays/community
執行後會看到:
這就是 Components 的美妙之處:新增功能就像打開開關一樣簡單,不需要修改任何現有配置,也不會影響其他環境。
情境 3:建立新的 Caching Component
現在讓我們實際建立一個新的 Component。企業版需要 Redis 快取來提升效能,我們來為它建立 caching component。
首先建立 Redis 相關的資源:
# components/caching/redis-depl.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-deployment
spec:
replicas: 1
selector:
matchLabels:
component: redis
template:
metadata:
labels:
component: redis
spec:
containers:
- name: redis
image: redis:7-alpine
ports:
- containerPort: 6379
# components/caching/redis-service.yaml
apiVersion: v1
kind: Service
metadata:
name: redis-service
spec:
type: ClusterIP
selector:
component: redis
ports:
- port: 6379
targetPort: 6379
關鍵的部分是 API patch,讓 API 能夠連接到 Redis:
# components/caching/api-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-deployment
spec:
template:
spec:
containers:
- name: api
env:
- name: REDIS_CONNECTION
value: redis-service
這個 patch 為 API 容器注入了 REDIS_CONNECTION
環境變數,指向 Redis service。這是 Component 設計的精髓:不僅部署新資源,還要確保現有應用能正確使用這些新資源。
最後建立 Component 的 kustomization.yaml:
# components/caching/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
resources:
- redis-depl.yaml
- redis-service.yaml
patches:
- path: api-patch.yaml
現在可以在企業版中使用這個 Component:
# overlays/enterprise/kustomization.yaml
resources:
- ../../base
components:
- ../../components/auth
- ../../components/logging
- ../../components/caching
部署企業版:
kubectl apply -k /root/code/project_mercury/overlays/enterprise
檢查部署結果,會看到 API deployment 的環境變數中包含了來自不同 Components 的配置:
Components 的設計原則:
Components vs Overlays 的區別:
這種分層設計讓配置管理變得極為靈活:
在這兩天的 Kustomize 學習中,我們從基礎的 Base 和 Overlays 概念,一路深入到 Transformers、Patches 和 Components 的進階應用。Kustomize 真正的強大之處在於它的「組合式」設計哲學:
這些機制相互配合,形成了一個強大而靈活的配置管理系統。更重要的是,Kustomize 是 Kubernetes 原生的工具,不需要學習額外的模板語法,所有配置都是標準的 Kubernetes YAML,這大大降低了學習曲線。
到今天的內容是我爬文觀察到 2025 年版本的 CKAD 考試,接下來就是去練習報名後的官方模擬考,希望能有好的結果。明天要繼續探索更進階的主題,像是 Istio 服務網格,這些內容雖然不在 CKAD 考試範圍內,但對於實際的 Kubernetes 運維工作非常有價值。