Kubernetes 中模板化的正確方式 - Kustomize

作者：陽明 2023-03-10 22:14:49

開發開發工具

Kustomize 不是一個新工具，它自 2017 年以來一直在建設中，并在 1.14 版本中作為原生 kubectl 子命令引入。是的，你沒聽錯，它現在直接嵌入到你日常使用的工具中，所以你可以扔掉 Helm 命令。

我們總是需要使用 Kubernetes 自定義我們的部署，我不知道為什么，但現在主要的工具是 HELM，它拋棄了我們在 docker 和 Kubernetes 上學到的所有邏輯。在這里給大家介紹一個替代品，叫做 Kustomize。

Kustomize 不是一個新工具，它自 2017 年以來一直在建設中，并在 1.14 版本中作為原生 kubectl 子命令引入。是的，你沒聽錯，它現在直接嵌入到你日常使用的工具中，所以你可以扔掉 helm 命令。

哲學

當使用 Git 作為 VCS、創建 Docker 鏡像或在 Kubernetes 中聲明資源時，Kustomize 試圖遵循你在日常工作中使用的理念。

所以，首先，Kustomize 就像 Kubernetes，它是完全聲明式的！你說你想要什么，系統就會提供給你，你不必遵循命令式的方式并描述希望它如何構建事物。

其次，它像 Docker 一樣工作。你有很多層，每一層都在修改之前的層。多虧了這一點，你可以不斷地寫出高于他人的東西，而不會在你的配置中增加復雜性。構建的結果將是添加基礎和你在其上應用的不同層。

最后，與 Git 一樣，你可以使用遠程庫作為你工作的開始，并在其上添加一些定制。

使用

基礎

要開始使用 Kustomize，你需要有原始的 yaml 文件來描述你要部署到集群中的任何資源。我們這里的示例將這些文件將存儲在文件夾 ./k8s/base/ 中。

這些文件將永遠不會被修改，我們將在它們上面應用自定義來創建新的資源定義。

注意：你可以隨時使用命令 kubectl apply -f ./k8s/base/ 構建基礎模板（例如，用于開發環境）。在此示例中，我們將使用一個 Service 和一個 Deployment 資源：

apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
    - name: http
      port: 8080
  selector:
    app: sl-demo-app

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  selector:
    matchLabels:
      app: sl-demo-app
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
        - name: app
          image: foo/bar:latest
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

我們將在該文件夾中添加一個名為 kustomization.yaml 的新文件：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - service.yaml
  - deployment.yaml

該文件將是你核心文件，它描述了你使用的資源，這些資源文件是相對于當前文件的路徑。

注意：這個 kustomization.yaml 文件在運行 kubectl apply -f ./k8s/base/ 時可能會導致錯誤，你可以使用參數 --validate=false 運行它，或者干脆不對整個文件夾運行命令。

要將該 base 基礎模板應用到集群，你只需執行以下命令：

$ kubectl apply -k k8s/base

但是這樣會直接將我們的模板應用到集群中，有時候我們可能希望將模板渲染出來看下結果是否正確，這個時候我們可以去直接使用 kustomize 的命令 kustomize build 來實現，所以我們需要單獨安裝下 kustomize，對于 Mac 用戶可以直接使用 brew 命令一鍵安裝，其他系統可以直接前往 Release 頁面下載二進制文件，然后放入 PATH 路徑即可。

$ brew install kustomize

要查看將在你的集群中應用了什么，我們將在本文中主要使用命令 kustomize build 而不是 kubectl apply -k。

kustomize build k8s/base 命令的結果如下，會直接將兩個文件連接在一起：

$ kustomize build k8s/base
apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
  - name: http
    port: 8080
  selector:
    app: sl-demo-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  selector:
    matchLabels:
      app: sl-demo-app
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
      - image: foo/bar:latest
        name: app
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

定制

現在，我們想要針對特定場景來定制我們的應用程序，例如，針對我們的生產環境，接下來我們將看到如何通過一些修改來增強我們的基礎。本文的主要目標不是涵蓋 Kustomize 的全部功能，而是作為一個標準示例向你展示此工具背后的理念。

首先，我們將創建文件夾 k8s/overlays/prod，其中包含一個 kustomization.yaml 文件，包含以下內容：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
  - ../../base

如果我們構建它，我們將看到與之前構建 base 時相同的結果。

$ kustomize build k8s/overlays/prod

為 Deployment 定義環境變量

在 base 中，我們沒有定義任何環境變量，現在我們將添加 env 變量到 base 中去，要做到這一點，非常簡單，我們只需要創建我們想要在 base 之上應用的 yaml 塊，并在 kustomization.yaml 中引用它。

custom-env.yaml 包含的環境變量如下所示：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  template:
    spec:
      containers:
        - name: app # (1)
          env:
            - name: CUSTOM_ENV_VARIABLE
              value: Value defined by Kustomize ??

注意：這里的 name (1) 非常重要，可以讓 Kustomize 找到需要修改的正確容器。

你可以看到這個 yaml 文件本身是無效的，但它只描述了我們想在之前的 base 上添加的內容。

我們只需將此文件添加到 k8s/overlays/prod/kustomization.yaml 中的 patches 屬性下面即可：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: custom-env.yaml

如果現在我們來構建，將會得到下面的結果:

$ kustomize build k8s/overlays/prod
apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
  - name: http
    port: 8080
  selector:
    app: sl-demo-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  selector:
    matchLabels:
      app: sl-demo-app
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
      - env:
        - name: CUSTOM_ENV_VARIABLE
          value: Value defined by Kustomize ??
        image: foo/bar:latest
        name: app
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

可以看到我們上面定義的 env 塊已應用在我們的 base 之上了，現在 CUSTOM_ENV_VARIABLE 將出現在我們的 deployment.yaml 中。

patches 屬性中可以直接指定一個 yaml 文件，也可以直接在該屬性這里修改資源，補丁可以包括容器鏡像、端口、環境變量等。比如可以在 kustomization.yaml 文件中添加以下內容：

patches:
  - target:
      kind: Deployment
      name: sl-demo-app
    patch: |-
      - op: replace
        path: /spec/template/spec/containers/0/image
        value: my-image:latest

上述內容將基礎資源中名為 sl-demo-app 的 Deployment 的容器鏡像修改為 my-image:latest。

更改副本數量

接下來我們想添加有關副本數量的信息，像之前一樣，僅包含定義副本所需的額外信息的塊或 yaml 就足夠了：

# replica-and-rollout-strategy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  replicas: 10
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate

和以前一樣，我們將它添加到 kustomization.yaml 中的 patches 列表中：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: custom-env.yaml
  - path: replica-and-rollout-strategy.yaml

同樣執行命令 kustomize build k8s/overlays/prod 后會得到如下結果：

$ kustomize build k8s/overlays/prod
apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
  - name: http
    port: 8080
  selector:
    app: sl-demo-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: sl-demo-app
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
      - env:
        - name: CUSTOM_ENV_VARIABLE
          value: Value defined by Kustomize ??
        image: foo/bar:latest
        name: app
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

可以看到副本數和 rollingUpdate 策略已經應用在 base 之上了。

通過命令行使用 Secret 定義

我們經常會從命令行將一些變量設置為 Secret 數據，這里我們使用 kustomize 的一個子命令來編輯 kustomization.yaml 并為創建一個 Secret，如下所示：

$ cd k8s/overlays/prod
$ kustomize edit add secret sl-demo-app --from-literal=db-password=12345

上面的命令會修改 kustomization.yaml 文件并在其中添加一個 SecretGenerator，內容如下所示：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: custom-env.yaml
  - path: replica-and-rollout-strategy.yaml
secretGenerator:
  - literals:
      - db-password=12345
    name: sl-demo-app
    type: Opaque

同樣如果從示例項目的根文件夾運行 kustomize build k8s/overlays/prod 命令將獲得以下輸出。

apiVersion: v1
data:
  db-password: MTIzNDU=
kind: Secret
metadata:
  name: sl-demo-app-gkmm8tkdd7
type: Opaque
---
apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
    - name: http
      port: 8080
  selector:
    app: sl-demo-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: sl-demo-app
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
        - env:
            - name: CUSTOM_ENV_VARIABLE
              value: Value defined by Kustomize ??
          image: foo/bar:latest
          name: app
          ports:
            - containerPort: 8080
              name: http
              protocol: TCP

注意上面生成的 Secret 對象名稱是 sl-demo-app-gkmm8tkdd7 而不是 sl-demo-app，這是正常的，如果 Secret 內容發生變化，就可以觸發 Deployment 的滾動更新。

如果想在我們的 Deployment 中使用這個 Secret，我們只需要像以前一樣添加一個使用 Secret 的新層定義即可。比如我們將 db-password 值以環境變量的方式注入 pod，則可以聲明如下的層文件：

# database-secret.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  template:
    spec:
      containers:
        - name: app
          env:
            - name: "DB_PASSWORD"
              valueFrom:
                secretKeyRef:
                  name: sl-demo-app
                  key: db.password

然后在 kustomization.yaml 文件 pathes 中添加上面的層文件：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: custom-env.yaml
  - path: replica-and-rollout-strategy.yaml
  - path: database-secret.yaml

secretGenerator:
  - literals:
      - db-password=12345
    name: sl-demo-app
    type: Opaque

構建后可以得到如下的結果：

$ kustomize build k8s/overlays/prod
apiVersion: v1
data:
  db-password: MTIzNDU=
kind: Secret
metadata:
  name: sl-demo-app-gkmm8tkdd7
type: Opaque
---
apiVersion: v1
kind: Service
metadata:
  name: sl-demo-app
spec:
  ports:
  - name: http
    port: 8080
  selector:
    app: sl-demo-app
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sl-demo-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: sl-demo-app
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: sl-demo-app
    spec:
      containers:
      - env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              key: db.password
              name: sl-demo-app-gkmm8tkdd7
        - name: CUSTOM_ENV_VARIABLE
          value: Value defined by Kustomize ??
        image: foo/bar:latest
        name: app
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP

可以看到 Deployment 中新增了 DB_PASSWORD 這部分內容，使用的 secretKeyRef.name 名稱則為 Secret 的名稱。

更改鏡像

與 Secret 一樣，有一個自定義指令允許直接從命令行更改鏡像或標簽，如果你是通過 CI/CD 來發布應用這將非常有用，如下所示：

$ cd k8s/overlays/prod
$ TAG_VERSION=3.4.5 # (1)
$ kustomize edit set image foo/bar=foo/bar:$TAG_VERSION

這里的 TAG_VERSION 通常是我們的 CI/CD 系統來定義的，上面的命令執行后，kustomization.yaml 文件中會新增一個 images 的屬性，里面包括 newName 和 newTag 兩個屬性：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

patches:
  - path: custom-env.yaml
  - path: replica-and-rollout-strategy.yaml
  - path: database-secret.yaml

secretGenerator:
  - literals:
      - db-password=12345
    name: sl-demo-app
    type: Opaque
images:
  - name: foo/bar
    newName: foo/bar
    newTag: 3.4.5

同樣執行 build 命令后得到的 Deployment 中的 image 就是 foo/bar:3.4.5。

總結

通過上面的這些簡單示例我們可以了解如何利用 Kustomize 的強大功能來定義 Kubernetes 資源文件，甚至無需使用模板系統。我們所做的所有修改文件都將應用在原始文件之上，而無需使用花括號和命令式修改對其進行更改。

Kustomize 中還有很多高級用法，例如 mixins 和繼承邏輯或其他允許為每個創建的對象定義名稱、標簽或命名空間的指令，我們后續再來介紹。

責任編輯：姜華來源： k8s技術圈

Kustomize Kubernetes