kubernetes kustomize 初體驗

07-08

來自專欄 Kubernetes指南

kustomize是sig-cli的一個子項目，它的設計目的是給kubernetes的用戶提供一種可以重複使用同一套配置的聲明式應用管理，從而在配置工作中用戶只需要管理和維護kubernetes的API對象，而不需要學習或安裝其它的配置管理工具，也不需要通過複製粘貼來得到新的環境的配置。

當我們運行一個kubernetes環境的時候，我們需要一些含有API對象的YAML文件，這些文件中規定了要部署什麼樣的應用，需要多少份副本，開闢多大的存儲空間，分配多少內存和CPU等信息。通過修改這些YAML文件的內容我們可以對這些信息進行相應的改動，比如我們需要增加一個副本，就需要修改對應YAML文件的replica數值；如果我們需要部署最新版本的docker鏡像，就需要修改對應YAML文件中的docker鏡像的版本或標籤。我們可以把所有這些為了滿足需求而進行的修改成為自定義kubernetes的配置。

在我們開發一個微服務架構的應用的過程中，我們會創建一些YAML文件來部署一個開發的環境，在這個環境下，我們需要進行各種測試。一旦所有的測試達到了我們的預期，我們就會把這個應用部署到生產環境。因為我們已經有了一套開發環境的配置，我們可以通過複製這些配置，再進行生產環境下的自定義，就可以得倒一套用於生產環境的配置。

然而這種方法的可擴展性並不好，當我們的微服務數量很多或者環境數量很多時，我們就有許多套的配置，這些配置只有細微的差別，而在很大程度上都一樣。當我們對配置進行改動或者升級的時候，就非常容易漏掉一些改動或者實施了額外的甚至是錯誤的改動。我們來看兩個簡單的例子。

假如我們有一個應用，我們已經把它部署在十個不同的環境中，每一個環境的配置都是通過複製,粘貼和修改得到的。每個環境中所運行的應用版本號都是1.0，現在我們想把所有環境中的版本號升級到2.0。我們就需要修改對應每一個環境下該應用的版本號。這不是一個複雜的改動，我們可以對每一個環境依次進行修改，所有的改動很快就可以完成。但是在這個過程中我們很有可能只修改了其中的九個環境而漏掉了一個；我們也很有可能把其中一個版本號改成2,0。

我們再來看另外一個例子。在小王通過複製，粘貼和修改所得到的一個配置中，小李是沒有辦法區分哪些值是保持不變，而哪些值是被修改過的。當小李想要修改這個新的配置時，他不知道哪些可以安全地改動而那些可能會影響的當前環境的正確運行。

kustomize允許用戶將不同環境所共享的配置放在一個文件目錄下，而將其他不同的配置放在另外的目錄下。這樣用戶就可以很容易的區分那些值是當前環境所特有的，從而在修改的時候會額外關注。kustomize可以非常好地解決這些問題。

重要概念

kustomization：kustomization.yaml文件，一個含有kustomization.yaml的目錄可以運行 kustomize build。kustomization.yaml的一個例子如下

bases:- /config/myapp1/base- /config/myapp2/baseresources:- service.yaml- deployment.yamlpatches:- patch.yamlnamePrefix: my-

base：含有一個kustomization.yaml文件的目錄，可以被其他的kustomization.yaml來引用

resource：文件路徑，指向一個聲明了kubernetes API對象的YAML文件

patch: 文件路徑，指向一個聲明了kubernetes API patch的YAML文件

variant: 含有同一組bases的不同kustomization

安裝

你可以通過如下兩種不同方式來安裝kustomize, kustomize只包含有一個二進位可執行文件，所以可以非常容易地安裝和使用。

下載壓縮包，kustomize提供Linux，Darwin，和windows三個版本的壓縮包。

如果你的Go的版本在1.10.1以上，你可以通過 go get來直接安裝

go get github.com/kubernetes-sigs/kustomize

使用

Kustomize 命令行包含build， diff， edit， version，help等子命令，其中最常使用的是build子命令。

kustomize --helpkustomize manages declarative configuration of Kubernetes.See https://github.com/kubernetes-sigs/kustomizeUsage: kustomize [command]Available Commands: build Print current configuration per contents of kustomization.yaml diff diff between customized resources and uncustomized resources edit Edits a kustomization file help Help about any command version Prints the kustomize vers

下面我們來用kustomize連建立一個LDAP的base和用於開發環境與生產環境的兩個不同的variants。

首先我們來創建一個工作空間，用來存儲base和兩個不同的variants。

DEMO_HOME=$(mktemp -d)BASE=$DEMO_HOME/basemkdir -p $BASEOVERLAYS=$DEMO_HOME/overlaysmkdir -p $OVERLAYS/devmkdir -p $OVERLAYS/production

創建base

我們從kustomize的repo中下載一些YAML文件到base目錄

CONTENT="https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/examples/ldap"curl -s -o "$BASE/#1" "$CONTENT/base/{deployment.yaml,kustomization.yaml,service.yaml,env.startup.txt}"

現在base目錄包含如下的文件

/tmp/tmp.IyYQQlHaJP└── base ├── deployment.yaml ├── env.startup.txt ├── kustomization.yaml └── service.yaml

其中的自定義文件kustomization.yaml包含如下內容

resources：-deployment.yaml-service.yamlconfigmapGenerator：-name: ldap-configmap files: -env.startup.txt

從這個內容上可以看出這個配置包含一個deployment的對象，一個service對象和一個configmap的對象，configmap的數據是從文件env.startup.txt中讀取。我們可以運行如下kustomize命令來看完整的配置

Kustomize build $BASE

我們還可以通過如下命令來部署這個base環境到kubernertes集群上

Kustomize build $BASE | kubectl apply -f -

下面我們將兩個適用於不同環境的自定義，這兩個自定義都是基於同一個base。

創建開發環境的自定義

下載開發環境對應的補丁及文件

curl -s -o 「$OVERLAYS/dev/#1」「$CONTENT/overlays/staging/{config.env,deployment.yaml,kustomization.yaml}」

開發環境的dev目錄包含如下文件

/tmp/tmp.IyYQQlHaJP└── overlays └── dev ├── config.env ├── deployment.yaml └── kustomization.yaml

這裡的kustomization.yaml文件包含如下內容

bases：- ../../basepatches:- deployment.yamlnameprefix: dev-configmapGenerator:- name: env-config files: config.env

這個自定義是在base的基礎上添加一個名字前綴，添加了一個configmap，並且還通過補丁修改了deployment對象，這裡進行的改動是將副本增加到2個

apiVersion: apps/v1beta2kind: Deploymentmetadata: name: ldapspec: replicas: 2

我們可以運行如下kustomize命令來看完整的開發環境的配置

kustomize build $OVERLAYS/dev

我們還可以通過如下命令來將這個開發環境部署到kubernertes集群上

kustomize build $OVERLAYS/dev | kubectl apply -f -

創建生產環境的自定義

下載生產環境對應的補丁及文件

curl -s -o "$OVERLAYS/production/#1" "$CONTENT/overlays/production/{deployment.yaml,kustomization.yaml}"

生產環境的production目錄包含如下文件

/tmp/tmp.IyYQQlHaJP1└── overlays ├── production ├── deployment.yaml └── kustomization.yaml

這裡的kustomization.yaml文件包含如下內容

bases：- ../../basepatches:- deployment.yamlnamePrefix: production-

這裡的自定義是在base的基礎上添加一個名字前綴，並且通過補丁修改了deployment對象，所進行的改動有兩個：將副本增加到6個；添加了一個持久存儲

apiVersion: apps/v1beta2kind: Deploymentmetadata: name: ldapspec: replicas: 6 template: spec: volumes: - name: ldap-data emptyDir: null gcePersistentDisk: pdName: ldap-persistent-storage

類似的，我們可以運行如下kustomize命令來看完整的生產環境的配置

kustomize build $OVERLAYS/production

我們還可以通過如下命令來將這個生產環境部署到kubernertes集群上

kustomize build $OVERLAYS/production | kubectl apply -f -

比較不同環境

我們還可以通過 kustomize build 來比較不同環境下的配置，命令如下

diff <(kustomize build $OVERLAYS/dev) <(kustomize build $OVERLAYS/production) | more

我們將看到如下輸出

(...truncated)< name: dev-ldap-configmap-kftftt474h---> name: production-ldap-configmap-k27f7hkg4f85c75< name: dev-ldap-service---> name: production-ldap-service97c87< name: dev-ldap---> name: production-ldap99c89< replicas: 2---

參考資料

introducing-kustomize-template-free-configuration-customization-for-kubernetes

github.com/kubernetes-sigs/kustomize