目錄

一、Kustomize 概述

1.1 Kustomize 簡介?

1.2?Kustomize 與 Helm 技術(shù)詳細(xì)對比

1.2.1 區(qū)別

1.2.2 優(yōu)缺點

1.2.3 適用場景

1.3 總結(jié)

二、Kustomize 入門

2.1 安裝 Kustomize

2.2 Kustomize 項目目錄結(jié)構(gòu)及介紹

2.2.1 Kustomize 基本概念

2.2.2 personal-web 項目結(jié)構(gòu)詳細(xì)介紹

2.3 創(chuàng)建基礎(chǔ)資源

2.3.1 deploy.yaml?

2.3.2 service.yaml

2.3.3?ingress.yaml

2.4 創(chuàng)建 kustomization.yaml

2.5 生成定制資源

一、Kustomize 概述

1.1 Kustomize 簡介?

????????Kustomize 是一款 Kubernetes 原生的配置管理工具，其核心理念是允許用戶自定義 Kubernetes 資源配置，而無需直接修改原始的 YAML 文件。這在很大程度上提高了配置的可維護(hù)性和可重用性。Kustomize 使用聲明式的方式來定制資源，通過一系列預(yù)定義的指令和規(guī)則，用戶可以對基礎(chǔ)資源進(jìn)行修改、添加或刪除。Kustomize 與其他模板技術(shù)相比，具有以下優(yōu)勢：

1. 易于理解：Kustomize 使用簡單的 YAML 語法，與 Kubernetes 資源本身的定義方式保持一致，易于學(xué)習(xí)和理解。

2. 原子性：Kustomize 的覆蓋策略允許用戶精確地修改特定部分的配置，而不會影響其他部分。這樣可以確保修改的原子性，避免出現(xiàn)意外的副作用。

3. 可組合性：Kustomize 支持將多個覆蓋層疊加在一起，從而形成一個完整的定制資源。這使得用戶可以在多個環(huán)境和場景之間復(fù)用同一套基礎(chǔ)配置，降低了維護(hù)成本。

4. 集成 Kubernetes：Kustomize 自 Kubernetes v1.14 起已經(jīng)被集成在 kubectl 中，用戶無需安裝額外的工具即可使用 Kustomize。

????????總之，Kustomize 提供了一種更為靈活且高效的方式來管理 Kubernetes 資源配置。通過使用 Kustomize，開發(fā)者和運(yùn)維人員可以輕松地為不同環(huán)境和場景創(chuàng)建定制的配置，提高了工作效率和配置的可維護(hù)性。

Kustomize 官方文檔：配置定制（Bespoke configuration） | SIG CLI?

Kustomize 在 k8s 中的介紹：使用 Kustomize 對 Kubernetes 對象進(jìn)行聲明式管理 | Kubernetes?

1.2?Kustomize 與 Helm 技術(shù)詳細(xì)對比

????????Kustomize 和 Helm 都是 Kubernetes 生態(tài)中流行的配置管理工具，雖然它們有許多相似之處，但在實現(xiàn)方式和適用場景上有所不同。接下來，我們將從區(qū)別、優(yōu)缺點和適用場景等方面詳細(xì)對比 Kustomize 和 Helm。

Helm 的教程：【Kubernetes 企業(yè)項目實戰(zhàn)】08、簡化 K8s 應(yīng)用部署工具 Helm V3 入門到企業(yè)實戰(zhàn)_Stars.Sky的博客-CSDN博客

1.2.1 區(qū)別

1. 實現(xiàn)方式：Kustomize 采用基于覆蓋的策略，通過在原始資源上應(yīng)用一系列覆蓋來實現(xiàn)資源定制。而 Helm 使用 Go 模板語言，將變量嵌入到 YAML 文件中，通過替換變量的方式生成定制資源。

2. 配置管理：Kustomize 使用 kustomization.yaml 文件進(jìn)行配置管理，而 Helm 使用名為 Chart.yaml 和 values.yaml 的文件。

3. 依賴管理：Helm 支持依賴管理，允許用戶將一個 Helm Chart 依賴于其他 Helm Chart。而 Kustomize 不具備依賴管理功能。

4. 發(fā)布管理：Helm 支持版本控制和回滾功能，可以管理應(yīng)用的發(fā)布?xì)v史。Kustomize 不具備類似功能。

5. 安裝方式：Kustomize 自 Kubernetes v1.14 起已經(jīng)集成在 kubectl 中，而 Helm 需要單獨安裝。

1.2.2 優(yōu)缺點

Kustomize

優(yōu)點：

• 易于學(xué)習(xí)和理解，與 Kubernetes 資源本身的定義方式保持一致。
• 使用聲明式方式進(jìn)行資源定制，避免了模板語言帶來的復(fù)雜性。
• 支持多層覆蓋，有利于組織和管理復(fù)雜的配置。
• 無需安裝額外工具，與 kubectl 無縫集成。

缺點：

• 不支持依賴管理和發(fā)布管理。
• 在處理復(fù)雜邏輯和動態(tài)生成內(nèi)容時，相較于 Helm 的模板語言，Kustomize 的能力有限。

Helm

優(yōu)點：

• 支持依賴管理和發(fā)布管理，提供了完整的應(yīng)用生命周期管理功能。
• 使用 Go 模板語言，可以處理復(fù)雜的邏輯和動態(tài)生成內(nèi)容。
• 擁有豐富的社區(qū)資源，如 Helm Chart 倉庫等。

缺點：

• 需要單獨安裝，并學(xué)習(xí) Go 模板語言。
• 模板語言可能導(dǎo)致配置的復(fù)雜性增加。

1.2.3 適用場景

Kustomize

• 適用于簡單到中等復(fù)雜度的 Kubernetes 資源配置管理。
• 更適合那些需要在多個環(huán)境和場景下復(fù)用基礎(chǔ)配置的場景。
• 當(dāng)對模板語言的需求較低時，Kustomize 是一個更簡潔的選擇。

Helm

• 適用于具有復(fù)雜依賴關(guān)系和發(fā)布管理需求的應(yīng)用。
• 當(dāng)需要處理復(fù)雜邏輯和動態(tài)生成內(nèi)容時，Helm 的模板語言更具優(yōu)勢。
• 如果需要使用豐富的社區(qū)資源，例如 Helm Chart 倉庫，Helm 是一個更好的選擇。

1.3 總結(jié)

????????Kustomize 和 Helm 都是優(yōu)秀的 Kubernetes 配置管理工具，它們各自具有獨特的優(yōu)勢和不同的適用場景。在選擇 Kustomize 還是 Helm 時，需要根據(jù)實際需求和場景來權(quán)衡。

????????Kustomize 以其簡單易用、聲明式的方式在 Kubernetes 生態(tài)中脫穎而出，特別適合那些需要在多個環(huán)境和場景下復(fù)用基礎(chǔ)配置的場景。

????????而 Helm 則作為一個功能更為完善的應(yīng)用生命周期管理工具，更適合具有復(fù)雜依賴關(guān)系和發(fā)布管理需求的應(yīng)用。在處理復(fù)雜邏輯和動態(tài)生成內(nèi)容時，Helm 的模板語言具有顯著優(yōu)勢。同時，Helm 也擁有豐富的社區(qū)資源，如 Helm Chart 倉庫等，為用戶提供了更多的便利。

????????最終，你可以根據(jù)實際項目需求、團(tuán)隊技能和個人喜好來選擇 Kustomize 或 Helm。無論選擇哪種工具，都能在 Kubernetes 配置管理方面為你帶來很大的幫助。

二、Kustomize 入門

kustomize API 介紹：kustomization.yaml | SIG CLI

2.1 安裝 Kustomize

????????Kustomize 自 Kubernetes v1.14 起已經(jīng)被集成在 kubectl 中，因此無需額外安裝。只需確保你的 kubectl 版本在 v1.14 以上即可使用 Kustomize。

root@jenkins:/data/kustomize# kubectl version

root@jenkins:/data/kustomize# kubectl kustomize 

2.2 Kustomize 項目目錄結(jié)構(gòu)及介紹

此次教程以 personal-web 前端項目作為講解例子：

root@jenkins:/data/kustomize# tree personal-web
personal-web
├── base
│?? ├── deploy.yaml
│?? ├── ingress.yaml
│?? ├── kustomization.yaml
│?? ├── nginx.conf
│?? └── service.yaml
└── overlays
    ├── pre
    │?? ├── deploy-patch.yaml
    │?? ├── ing-patch.yaml
    │?? └── kustomization.yaml
    ├── prod
    │?? ├── deploy-patch.yaml
    │?? ├── ing-patch.yaml
    │?? ├── kustomization.yaml
    │?? └── set_volumeMounts.yaml
    ├── test1
    │?? ├── deploy-patch.yaml
    │?? ├── ing-patch.yaml
    │?? └── kustomization.yaml
    └── test2
        ├── deploy-patch.yaml
        ├── ing-patch.yaml
        └── kustomization.yaml

2.2.1 Kustomize 基本概念

1. 基礎(chǔ)資源（Base）：基礎(chǔ)資源是原始的 Kubernetes YAML 文件，用于描述 Kubernetes 對象。

2. 覆蓋（Overlay）：覆蓋是對基礎(chǔ)資源的定制，用于為特定環(huán)境或場景提供額外的配置信息。

3. kustomization.yaml：Kustomize 的配置文件，用于描述如何生成定制的資源。

2.2.2 personal-web 項目結(jié)構(gòu)詳細(xì)介紹

????????上面是一個使用 Kustomize 的項目目錄結(jié)構(gòu)，用于管理一個名為 personal-web 的 Kubernetes 應(yīng)用。該項目包含一個基礎(chǔ)配置目錄（base）和一個覆蓋層配置目錄（overlays）。我們來詳細(xì)了解這個項目結(jié)構(gòu)：

• base 目錄：包含該應(yīng)用的基本 Kubernetes 資源配置文件，如 deploy.yaml（Deployment 配置）、ingress.yaml（Ingress 配置）和 service.yaml（Service 配置）。此外，還包含一個名為 nginx.conf 的 Nginx 配置文件。這些文件定義了應(yīng)用的基本架構(gòu)和行為。

  • kustomization.yaml：這是 Kustomize 的核心配置文件，用于聲明基本資源，以及如何修改這些資源。在這個例子中，kustomization.yaml 將其他 YAML 文件（如 deploy.yaml、ingress.yaml 和 service.yaml）視為基礎(chǔ)資源。

• overlays 目錄：包含用于不同環(huán)境（如預(yù)生產(chǎn)、生產(chǎn)和兩個測試環(huán)境）的覆蓋層配置。每個子目錄（pre、prod、test1 和 test2）代表一個環(huán)境，包含針對該環(huán)境的特定修改。

  • 每個子目錄中的 kustomization.yaml 文件指定了要應(yīng)用的基礎(chǔ)配置（在本例中為 base 目錄）以及覆蓋層資源（如 deploy-patch.yaml 和 ing-patch.yaml），這些資源用于修改基本配置以滿足特定環(huán)境的需求。

  • deploy-patch.yaml 和 ing-patch.yaml 文件包含針對 Deployment 和 Ingress 的定制修改。例如，可以更改副本數(shù)量、鏡像標(biāo)簽或 Ingress 的主機(jī)名。

  • prod 目錄下的 set_volumeMounts.yaml 文件是一個專門針對生產(chǎn)環(huán)境的額外配置，用于設(shè)置特定的 VolumeMounts。這表明生產(chǎn)環(huán)境與其他環(huán)境可能有不同的存儲配置。

????????總之，這個 Kustomize 項目目錄結(jié)構(gòu)允許您在不同環(huán)境之間復(fù)用基礎(chǔ)配置，同時提供了覆蓋層來實現(xiàn)針對特定環(huán)境的定制修改。這有助于提高配置的可維護(hù)性和可重用性。

2.3 創(chuàng)建基礎(chǔ)資源

2.3.1 deploy.yaml?

????????首先，我們創(chuàng)建一個項目目錄（personal-web），在該項目下創(chuàng)建 base 目錄用于存放基礎(chǔ)資源。例如，創(chuàng)建一個名為 deploy.yaml 的文件，內(nèi)容如下：

root@jenkins:/data/kustomize# cat personal-web/base/deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: -app 
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      imagePullSecrets:
      - name: registry
      containers:
      - name: personal-web
        image: 
        imagePullPolicy: Always
        env:
        - name: CONTAINER_APP_NAME
          value: personal-web
        - name: CONTAINER_PODIP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: CONTAINER_PODPORT
          value: "80"
        - name: CONTAINER_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        ports:
        - name: http
          containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            scheme: HTTP
            port: 80
          initialDelaySeconds: 3
          periodSeconds: 3
          timeoutSeconds: 2
          successThreshold: 2
          failureThreshold: 3
        resources:
          limits:
            cpu: 500m
            memory: 2000Mi
          requests:
            cpu: 200m
            memory: 500Mi
        volumeMounts:
        - name: conf
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
      volumes:
      - name: conf
        configMap:
          name: -cm

????????這個 deploy.yaml 文件定義了一個 Kubernetes Deployment 資源。Deployment 資源用于描述應(yīng)用程序的部署，確保特定數(shù)量的副本始終處于運(yùn)行狀態(tài)。以下是詳細(xì)的字段解釋：

• apiVersion: apps/v1：指定 Kubernetes API 的版本，本例中使用的是 apps/v1。

• kind: Deployment：指定資源類型為 Deployment。

• metadata：資源元數(shù)據(jù)，包括資源名稱等信息。

  • name: -app：Deployment 資源的名稱。這里的是個伏筆，后面會介紹，會自動生成?name: personal-web-app。

• spec：Deployment 資源的詳細(xì)規(guī)格。

  • replicas: 1：指定運(yùn)行的副本數(shù)量為 1。

  • strategy：定義升級策略。

    • rollingUpdate：指定滾動更新策略。

      • maxSurge: 1：在更新過程中允許的最大超出副本數(shù)。

      • maxUnavailable: 0：在更新過程中允許的最大不可用副本數(shù)。

  • selector：定義用于匹配 Pod 的標(biāo)簽選擇器。

    • matchLabels：指定要匹配的標(biāo)簽。這里的值缺失，應(yīng)該添加一個鍵值對，例如 app: personal-web。

  • template：定義 Pod 模板。

    • metadata：Pod 元數(shù)據(jù)。

      • labels：指定 Pod 標(biāo)簽。這里的值缺失，應(yīng)該添加一個鍵值對，例如 app: personal-web。

    • spec：Pod 詳細(xì)規(guī)格。

      • imagePullSecrets：指定用于拉取鏡像的 Secret。在這個例子中，Secret 名稱為 registry。

      • containers：定義容器列表。

        • name: personal-web：容器名稱。

        • image：容器使用的鏡像。這里的值缺失，應(yīng)該添加一個有效的鏡像，例如 image: myrepo/personal-web:latest。

        • imagePullPolicy: Always：鏡像拉取策略，始終拉取新的鏡像。

        • env：定義容器的環(huán)境變量。

        • ports：定義容器的端口映射。

        • readinessProbe：定義容器的就緒探針，用于檢查容器是否已經(jīng)準(zhǔn)備好接收流量。

        • resources：定義容器的資源限制和請求。

        • volumeMounts：定義容器的卷掛載。

      • volumes：定義 Pod 的卷。

        • name: conf：卷的名稱。

        • configMap：使用 ConfigMap 作為卷的數(shù)據(jù)來源。

          • name: -cm：指定 ConfigMap 的名稱。后續(xù)會自動生成，例如 name: personal-web-cm。

????????這個 deploy.yaml?文件定義了一個名為?personal-web?的容器，它會使用指定的鏡像并將其部署為一個 Kubernetes Deployment。這個 Deployment 包含了一個 Pod，其中包括環(huán)境變量、端口映射、就緒探針和資源限制等配置信息。

????????容器將使用名為 registry 的 Secret 來拉取鏡像，并始終拉取最新的鏡像。容器的環(huán)境變量包括 CONTAINER_APP_NAME、CONTAINER_PODIP、CONTAINER_PODPORT 和 CONTAINER_NAMESPACE，它們分別表示應(yīng)用名稱、Pod IP 地址、Pod 端口和命名空間。

????????容器的端口映射將內(nèi)部的 80 端口映射為名稱為 http 的端口。就緒探針將檢查容器的根路徑（/），使用 HTTP 協(xié)議和 80 端口，以確保容器已經(jīng)準(zhǔn)備好接收流量。容器的資源限制和請求分別定義了 CPU 和內(nèi)存的最大使用量以及基本需求。

????????卷掛載部分將名為 conf 的卷掛載到容器的 /etc/nginx/nginx.conf 路徑上。此卷使用名為 personal-web-cm 的 ConfigMap 作為數(shù)據(jù)來源。這樣，您可以在 ConfigMap 中存儲和管理 Nginx 配置，并自動將其應(yīng)用到容器中。

????????這個 deploy.yaml 文件為 personal-web 應(yīng)用提供了一個基礎(chǔ)的 Kubernetes Deployment 配置。通過 Kustomize 的覆蓋層，您可以根據(jù)不同環(huán)境的需求對其進(jìn)行修改。

2.3.2 service.yaml

root@jenkins:/data/kustomize# cat personal-web/base/service.yaml 
apiVersion: v1
kind: Service
metadata:
  name: -svc
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 300
  type: ClusterIP
  ports:
  - name: http-nginx
    port: 80
    targetPort: 80
  selector:
    app:

????????這個 service.yaml 文件定義了一個 Kubernetes Service 資源。Service 資源用于為一組運(yùn)行的 Pod 提供一個穩(wěn)定的 IP 地址和 DNS 名稱，實現(xiàn)負(fù)載均衡和網(wǎng)絡(luò)流量分發(fā)。以下是詳細(xì)的字段解釋：

• apiVersion: v1：指定 Kubernetes API 的版本，本例中使用的是 v1。

• kind: Service：指定資源類型為 Service。

• metadata：資源元數(shù)據(jù)，包括資源名稱等信息。

  • name: -svc：Service 資源的名稱。這里的名稱似乎有誤，應(yīng)該是一個有效的名稱，例如 name: personal-web-svc。

• spec：Service 資源的詳細(xì)規(guī)格。

  • sessionAffinity: ClientIP：設(shè)置會話親和性（session affinity）為 ClientIP。這意味著來自同一客戶端 IP 的請求會被發(fā)送到同一個 Pod。

  • sessionAffinityConfig：會話親和性配置。

    • clientIP：針對客戶端 IP 的會話親和性配置。

      • timeoutSeconds: 300：設(shè)置客戶端 IP 會話親和性的超時時間為 300 秒。

  • type: ClusterIP：設(shè)置 Service 類型為 ClusterIP。這意味著 Service 會分配一個內(nèi)部集群 IP 地址，僅在集群內(nèi)部可訪問。

  • ports：定義 Service 的端口映射。

    • name: http-nginx：端口名稱。

    • port: 80：Service 的端口。

    • targetPort: 80：Pod 中的目標(biāo)端口。

  • selector：定義用于匹配 Pod 的標(biāo)簽選擇器。

    • app：指定要匹配的標(biāo)簽。這里的值缺失，應(yīng)該添加一個鍵值對，例如 app: personal-web。

????????這個 service.yaml 文件為 personal-web 應(yīng)用提供了一個基礎(chǔ)的 Kubernetes Service 配置。Service 資源將在集群內(nèi)部將流量分發(fā)到具有 app: personal-web 標(biāo)簽的 Pod，并確保來自同一客戶端 IP 的請求會被發(fā)送到同一個 Pod。通過 Kustomize 的覆蓋層，您可以根據(jù)不同環(huán)境的需求對其進(jìn)行修改。

2.3.3?ingress.yaml

root@jenkins:/data/kustomize# cat personal-web/base/ingress.yaml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/service-weight: ""
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
  name: -ingress
spec:
  tls:
  - hosts:
    - 
    secretName: 
  ingressClassName: nginx
  rules:
  - host: 
    http:
      paths:
      - backend:
          service:
            name: 
            port:
              number: 80
        path: /
        pathType: Prefix

????????這個 ingress.yaml 文件定義了一個 Kubernetes Ingress 資源。Ingress 資源用于管理外部訪問集群內(nèi)部服務(wù)的規(guī)則，允許您通過一個或多個 HTTP 或 HTTPS 路徑將流量路由到集群內(nèi)部的 Service。以下是詳細(xì)的字段解釋：

• apiVersion: networking.k8s.io/v1：指定 Kubernetes API 的版本，本例中使用的是 networking.k8s.io/v1。

• kind: Ingress：指定資源類型為 Ingress。

• metadata：資源元數(shù)據(jù)，包括資源名稱、注解等信息。

  • annotations：為 Ingress 添加注解，用于配置 Ingress 控制器的行為。本例中使用了 nginx Ingress 控制器。

    • nginx.ingress.kubernetes.io/service-weight：為后端服務(wù)設(shè)置權(quán)重，用于流量分發(fā)。這里的值為空，表示使用默認(rèn)權(quán)重。

    • nginx.ingress.kubernetes.io/rewrite-target：重寫目標(biāo)路徑，將客戶端請求的路徑重寫為指定值。本例中，所有請求的路徑都被重寫為 /。

    • nginx.ingress.kubernetes.io/ssl-redirect：設(shè)置為 'true' 以啟用 SSL 重定向。這意味著非 SSL 請求將被重定向到 SSL 端點。

  • name: -ingress：Ingress 資源的名稱。這里的名稱似乎有誤，應(yīng)該是一個有效的名稱，例如 name: personal-web-ingress。

• spec：Ingress 資源的詳細(xì)規(guī)格。

  • tls：配置 Ingress 的 TLS 設(shè)置。

    • hosts：指定 TLS 證書適用的域名。這里的值缺失，應(yīng)該添加一個有效的域名，例如 - example.com。

    • secretName：指定包含 TLS 證書和密鑰的 Kubernetes Secret。這里的值缺失，應(yīng)該添加一個有效的 Secret 名稱，例如 secretName: example-tls-secret。

  • ingressClassName: nginx：指定 Ingress 類名為 nginx，用于選擇正確的 Ingress 控制器。

  • rules：定義 Ingress 規(guī)則。

    • host：指定規(guī)則適用的域名。這里的值缺失，應(yīng)該添加一個有效的域名，例如 host: example.com。

    • http：配置 HTTP 規(guī)則。

      • paths：定義 HTTP 路徑列表。

        • backend：配置后端服務(wù)。

          • service：指定后端服務(wù)。

            • name：后端服務(wù)的名稱。這里的值缺失，應(yīng)該添加一個有效的名稱，例如 name: personal-web-svc。

            • port：指定后端服務(wù)的端口。

              • number: 80：后端服務(wù)的端口號。

        • path: /：指定匹配的路徑。

        • pathType: Prefix：指定路徑類型為 Prefix，表示匹配請求路徑的前綴

2.4 創(chuàng)建 kustomization.yaml

接下來，我們創(chuàng)建一個名為 kustomization.yaml 的文件，內(nèi)容如下：

root@jenkins:/data/kustomize# cat personal-web/base/kustomization.yaml 
resources:
- deploy.yaml
- service.yaml
- ingress.yaml

configMapGenerator:
- name: -cm
  files:
  - nginx.conf

? ?kustomization.yaml 文件是 Kustomize 的核心配置文件，用于描述資源的基本配置和修改。在這個例子中，kustomization.yaml 文件位于 base 目錄下，包含以下內(nèi)容：

• resources：列出了本層次結(jié)構(gòu)中包含的 Kubernetes 資源文件。在這個例子中，包括 deploy.yaml（Deployment），service.yaml（Service）和 ingress.yaml（Ingress）。

• configMapGenerator：指定 ConfigMap 生成器，用于從文件或字面值創(chuàng)建 ConfigMap。在這個例子中，生成器用于創(chuàng)建一個名為 -cm 的 ConfigMap。這個名稱似乎有誤，應(yīng)該是一個有效的名稱，例如 name: personal-web-cm。

  • files：指定用于生成 ConfigMap 的文件列表。在這個例子中，生成器將 nginx.conf 文件內(nèi)容添加到 ConfigMap 中。

????????通過 kustomization.yaml 文件，您可以定義和組織 Kubernetes 資源的基本結(jié)構(gòu)。在其他覆蓋層中，您可以根據(jù)不同環(huán)境的需求對這些資源進(jìn)行修改。這使得您能夠更輕松地管理和維護(hù)多個環(huán)境的 Kubernetes 配置。

? ? configMapGenerator 是 Kustomize 中的一個功能，用于動態(tài)生成 Kubernetes ConfigMap。它允許您將配置數(shù)據(jù)與應(yīng)用程序資源分離，從而更好地管理和維護(hù)配置信息。下面詳細(xì)介紹 configMapGenerator 的優(yōu)勢和作用：

1. 分離配置和應(yīng)用程序資源：configMapGenerator 允許您將配置信息（如配置文件、屬性、參數(shù)等）與應(yīng)用程序資源（如 Deployment、Service 等）分離。這樣做有助于提高配置管理的靈活性和可維護(hù)性，方便您在不同環(huán)境中使用不同的配置。

2. 簡化配置管理：通過使用 configMapGenerator，您可以直接從本地文件或字面值創(chuàng)建 ConfigMap，無需手動創(chuàng)建和更新 YAML 文件。這降低了出錯的可能性，同時簡化了配置管理過程。

3. 避免重復(fù)和冗余：當(dāng)您的應(yīng)用程序需要使用相同的配置數(shù)據(jù)時，configMapGenerator 可以避免重復(fù)和冗余。通過在 Kustomize 層次結(jié)構(gòu)中復(fù)用相同的配置文件或字面值，您可以確保配置數(shù)據(jù)在各個環(huán)境中保持一致。

4. 自動生成名稱后綴：configMapGenerator 會自動為生成的 ConfigMap 添加一個唯一的后綴。這確保了當(dāng)配置數(shù)據(jù)發(fā)生變化時，所有使用這個 ConfigMap 的資源都會得到更新。這樣可以避免因為未更新配置導(dǎo)致的應(yīng)用程序錯誤或故障。

5. 支持多種數(shù)據(jù)來源：configMapGenerator 支持從多種來源生成 ConfigMap，包括文件、目錄、字面值、環(huán)境變量文件等。這使得您可以根據(jù)實際需求選擇合適的數(shù)據(jù)來源，靈活處理不同類型的配置數(shù)據(jù)。

????????總之，按照傳統(tǒng)的部署方式，我們需要先提前創(chuàng)建 configmap 資源，再把創(chuàng)建好的資源名稱填入 deploy.yaml 文件中才能生效，而?configMapGenerator 的存在則無需提前創(chuàng)建 configmap 資源，直接生成有效的 configmap，大大提高效率。

2.5 生成定制資源

現(xiàn)在，我們可以使用 kubectl kustomize 命令生成定制資源：

root@jenkins:/data/kustomize# kubectl kustomize personal-web/base/

? ?kubectl kustomize 命令用于處理指定目錄下的 Kustomize 配置文件（kustomization.yaml），并生成最終的 Kubernetes 資源清單（manifest）。它根據(jù) kustomization.yaml 文件中定義的基礎(chǔ)資源、覆蓋層、變量替換等指令，將不同環(huán)境的配置進(jìn)行合并和修改，輸出一個最終的資源清單。

這個命令的主要作用如下：

1. 處理 Kustomize 配置：kubectl kustomize 會根據(jù) kustomization.yaml 文件的指令，處理基礎(chǔ)資源和覆蓋層，生成一個適用于特定環(huán)境的資源清單。

2. 生成最終資源清單：該命令會生成一個最終的 Kubernetes 資源清單，該清單包含所有經(jīng)過修改和合并的資源配置，可以直接應(yīng)用于 Kubernetes 集群。

3. 方便資源部署和管理：kubectl kustomize 命令簡化了在不同環(huán)境中部署和管理 Kubernetes 資源的過程。您可以輕松地在開發(fā)、測試和生產(chǎn)等不同環(huán)境中使用相應(yīng)的覆蓋層，以確保配置正確。

注意：我們前面所介紹的一些資源清單文件的字段值有些是為空的、甚至是一些名稱沒有填寫完整等，這些空缺的部分，就是我們后續(xù)手動調(diào)整的地方，也叫補(bǔ)丁，大白話就是用于 DIY。?

上一篇文章：【Kubernetes 企業(yè)項目實戰(zhàn)】09、Rancher 2.6 管理 k8s-v1.23 及以上版本高可用集群_rancher 高可用_Stars.Sky的博客-CSDN博客

下一篇文章：【Kubernetes 企業(yè)項目實戰(zhàn)】11、掌握 Kubernetes Kustomize 技術(shù)從入門到企業(yè)實戰(zhàn)（下）_Stars.Sky的博客-CSDN博客文章來源地址http://www.zghlxwxcb.cn/news/detail-405279.html

到了這里，關(guān)于【Kubernetes 企業(yè)項目實戰(zhàn)】10、掌握 Kubernetes Kustomize 技術(shù)從入門到企業(yè)實戰(zhàn)（上）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！