GitOps K8s 自動化佈署：處理依賴關係的圖表佈署

實際應用中，單一服務往往需要依賴其他服務，如資料函式庫elm提供了優雅的方式來管理這些依賴關係。

建立帶有依賴的圖表

以下是一個實際案例，建立一個依賴PostgreSQL資料函式庫樂服務應用。

首先，建立基本的圖表結構：

mkdir music
mkdir music/templates
cd music

然後建立佈署範本，這裡是templates/deployment.yaml的內容：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .圖表.Name}}
  labels:
    app.kubernetes.io/name: {{ .圖表.Name}}
    {{- if .圖表.AppVersion }}
    app.kubernetes.io/version: {{ .圖表.AppVersion | quote }}
    {{- end }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .圖表.Name}}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .圖表.Name}}
    spec:
      containers:
      - image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .圖表.AppVersion}}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        name: {{ .圖表.Name}}
        ports:
        - containerPort: {{ .Values.image.containerPort }}
          name: http
          protocol: TCP
        env:
        - name: QUARKUS_DATASOURCE_JDBC_URL
          value: {{ .Values.postgresql.server | default (printf "%s-postgresql" ( .Release.Name )) | quote }}
        - name: QUARKUS_DATASOURCE_USERNAME
          value: {{ .Values.postgresql.postgresqlUsername | default (printf "postgres" ) | quote }}
        - name: QUARKUS_DATASOURCE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: {{ .Values.postgresql.secretName | default (printf "%s-postgresql" ( .Release.Name )) | quote }}
              key: {{ .Values.postgresql.secretKey }}

這個佈署範本定義了音樂服務的Kubernetes Deployment。關鍵部分是環境變數的設定，它們將應用連線到PostgreSQL資料函式庫- QUARKUS_DATASOURCE_JDBC_URL：設定資料函式庫URL

QUARKUS_DATASOURCE_USERNAME：設定資料函式庫者名
QUARKUS_DATASOURCE_PASSWORD：從Kubernetes Secret中取得資料函式庫

範本使用了Helm的條件判斷和預設值功能，確保即使用者沒有提供所有設定引數，佈署仍然能夠正常進行。

接著，建立服務範本templates/service.yaml：

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: {{ .圖表.Name }}
  name: {{ .圖表.Name }}
spec:
  ports:
  - name: http
    port: {{ .Values.image.containerPort }}
    targetPort: {{ .Values.image.containerPort }}
  selector:
    app.kubernetes.io/name: {{ .圖表.Name }}

這個服務範本建立了一個Kubernetes Service，將流量導向我們的音樂應用。它使用應用容器的連線埠作為伺服器連線埠，並透過標籤選擇器將流量正確路由到應用Pod。

定義圖表的依賴關係

最重要的部分是在圖表.yaml中定義依賴關係：

apiVersion: v2
name: music
description: A Helm chart for Music service
type: application
version: 0.1.0
appVersion: "1.0.0"
dependencies:
- name: postgresql
  version: 10.16.2
  repository: "https://charts.bitnami.com/bitnami"

這個圖表.yaml檔案定義了音樂服務圖表的基本訊息，並在dependencies部分宣告瞭對PostgreSQL 圖表的依賴。這意味著當我們佈署音樂服務時，Helm會自動確保PostgreSQL資料函式庫正確佈署。

依賴定義包括三個關鍵元素：

name：依賴圖表的名稱
version：所需的圖表版本
repository：圖表的來源儲存函式庫### 設定預設值

最後，建立values.yaml檔案，設定預設設定：

image:
  repository: quay.io/gitops-cookbook/music
  tag: "1.0.0"
  pullPolicy: Always
  containerPort: 8080
replicaCount: 1
postgresql:
  server: jdbc:postgresql://music-db-postgresql:5432/mydb
  postgresqlUsername: my-default
  secretName: music-db-postgresql
  secretKey: postgresql-password

這個設定檔設定了兩個主要部分：

音樂服務的容器設定（映像倉函式庫籤、提取策略等）
PostgreSQL的連線引數（連線URL、使用者名、密碼Secret等）

這種方式使得設定集中與易於修改，使用者可以在佈署時覆寫這些預設值。

更新依賴

定義好依賴關係後，需要下載依賴的

helm dependency update

這個命令會下載所有在圖表.yaml中定義的依賴圖表，並將它們儲存在charts/目錄中。這樣，當佈署主圖表時，所有依賴都會一起被佈署。

深入思考：Helm相依性管理的優勢

處理依賴關係是微服務架構中的一大挑戰。透過Helm的相依性管理機制，我們獲得了幾個關鍵優勢：

版本鎖定：可以指定依賴圖表的確切版本，確保環境一致性
簡化佈署：單一命令即可佈署完整應用及其所有依賴
設定覆寫：可以從主圖表覆寫依賴圖表的設定
生命週期管理：依賴服務的升級、回復與主應用同步

在大規模微服務架構中，這種相依性管理方式極大地簡化了佈署流程，減少了人為錯誤，並提高了系統的可維護性。

當我在設計複雜系統的佈署策略時，總是優先考慮利用Helm的依賴機制，將相互關聯的服務組織成層次化的圖表結構，使整個系統的佈署變得更加可控和可靠。

Helm的圖表相依性管理為Kubernetes應用提供了一種模組化、可重用的佈署方式。透過合理組織圖表和依賴關係，我們可以構建出既靈活又可靠的應用佈署流程，大提高了團隊的效率和系統的穩定性。在雲原生時代，掌握這些技能對於構建和管理現代應用至關重要。

Helm 應用相依性管理與佈署實戰

在 Kubernetes 的世界中，應用程式管理可能變得相當複雜，特別是當應用需要依賴其他服務（如資料函式庫。Helm 作為 Kubernetes 的包管理工具，為我們提供了優雅的解決方案。在這篇文章中，我將分享如何使用 Helm 管理應用程式依賴關係，以及如何透過 ConfigMap 的變更自動觸發應用程式的滾動更新。

理解 Helm 圖表的相依性管理

Helm 的強大之處在於它能夠管理應用程式之間的複雜依賴關係。當我們開發一個需要資料函式庫務時，不必手動佈署和設定資料函式庫可以透過 Helm 的依賴機制輕鬆實作。

以下是一個包含 PostgreSQL 依賴的圖表目錄結構：

music
├── 圖表.lock
├── 圖表.yaml
├── charts
│ └── postgresql-10.16.2.tgz
├── templates
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml

這個目錄結構顯示了一個音樂服務的 Helm 圖表，其中包含了 PostgreSQL 作為依賴。當我們使用 Helm 佈署這個應用時，PostgreSQL 會自動一同佈署。

這個目錄結構展示了 Helm 的相依性管理機制。圖表.lock 檔案記錄了確切的依賴版本，確保佈署的一致性。charts 目錄下的 postgresql-10.16.2.tgz 是封裝好的 PostgreSQL 圖表，將作為依賴一起佈署。templates 目錄包含了主應用的 Kubernetes 資源定義，而 values.yaml 則包含了可設定的引數值。

佈署帶有資料函式庫的應用

當我們準備好圖表後，就可以使用 Helm 命令進行佈署。下面是佈署音樂服務及其 PostgreSQL 依賴的方式：

helm install music-db --set postgresql.postgresqlPassword=postgres,postgresql.postgresqlDatabase=mydb,postgresql.persistence.enabled=false .

這條命令使用了 helm install 來佈署應用，命名為 music-db。--set 引數用於覆寫預設設定，這裡我們：

設定了 PostgreSQL 的密碼為 postgres
建立了一個名為 mydb 的資料函式庫. 停用了持久化儲存（適合測試環境，生產環境應啟用）

最後的 . 表示使用當前目錄作為圖表來源。

佈署完成後，我們可以檢查 Kubernetes 資源的狀態：

kubectl get pods
NAME                    READY   STATUS    RESTARTS        AGE
music-67dbf986b7-5xkqm  1/1     Running   1 (32s ago)    39s
music-db-postgresql-0   1/1     Running   0               39s

kubectl get statefulset
NAME                 READY   AGE
music-db-postgresql  1/1     53s

kubectl get services
NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes                    ClusterIP   10.96.0.1       <none>        443/TCP    40d
music                         ClusterIP   10.104.110.34   <none>        8080/TCP   82s
music-db-postgresql           ClusterIP   10.110.71.13    <none>        5432/TCP   82s
music-db-postgresql-headless  ClusterIP   None            <none>        5432/TCP   82s

這些命令顯示了佈署的結果：

music-67dbf986b7-5xkqm 是主應用的 Pod
music-db-postgresql-0 是 PostgreSQL 資料函式庫Pod，使用有狀態集合佈署
服務列表顯示了四個服務，包括 Kubernetes API 服務、音樂應用服務、PostgreSQL 服務和 PostgreSQL 的 headless 服務

驗證應用功能

佈署完成後，我們可以使用連線埠轉發來存取服務並驗證功能：

kubectl port-forward service/music 8080:8080

在另一個終端中，我們可以傳送請求：

curl localhost:8080/song

這將回傳儲存在資料函式庫歌曲列表：

[
  {
    "id": 1,
    "artist": "DT",
    "name": "Quiero Munchies"
  },
  {
    "id": 2,
    "artist": "Lin-Manuel Miranda",
    "name": "We Don't Talk About Bruno"
  },
  {
    "id": 3,
    "artist": "Imagination",
    "name": "Just An Illusion"
  },
  {
    "id": 4,
    "artist": "Txarango",
    "name": "Tanca Els Ulls"
  },
  {
    "id": 5,
    "artist": "Halsey",
    "name": "Could Have Been Me"
  }
]

這個流程展示瞭如何驗證佈署的應用：

kubectl port-forward 命令建立了一個從本地連線埠到 Kubernetes 服務的轉發
curl 命令傳送 HTTP 請求到轉發的連線埠
應用回傳了儲存在 PostgreSQL 資料函式庫歌曲列表，證明整個系統正常工作

透過 ConfigMap 變更自動觸發滾動更新

在 Kubernetes 中，當設定更新時，我們通常希望應用能自動重啟以應用新的設定。然而，僅更新 ConfigMap 並不會自動觸發 Deployment 的滾動更新。下面我將介紹一個實用技巧，使用 Helm 的 sha256sum 範本函式來實作這一功能。

問題背景

假設我們有一個問候服務，它從 ConfigMap 中讀取問候語。當我們更新 ConfigMap 中的問候語時，我們希望應用自動重啟以使用新的問候語。

問候服務的 Helm 圖表

首先，讓我們看一下這個問候服務的佈署範本：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .圖表.Name}}
  labels:
    app.kubernetes.io/name: {{ .圖表.Name}}
    {{- if .圖表.AppVersion }}
    app.kubernetes.io/version: {{ .圖表.AppVersion | quote }}
    {{- end }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .圖表.Name}}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .圖表.Name}}
    spec:
      containers:
      - image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .圖表.AppVersion}}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        name: {{ .圖表.Name}}
        ports:
        - containerPort: {{ .Values.image.containerPort }}
          name: http
          protocol: TCP
        env:
        - name: GREETING
          valueFrom:
            configMapKeyRef:
              name: {{ .Values.configmap.name}}
              key: greeting

這個佈署範本定義了一個應用，它使用環境變數從 ConfigMap 中取得問候語：

佈署名稱和標籤使用圖表名稱
容器映像來自 values.yaml 定義的倉函式庫籤
環境變數 GREETING 從指定的 ConfigMap 和鍵取得值

ConfigMap 定義如下：

apiVersion: v1
kind: ConfigMap
metadata:
  name: greeting-config
data:
  greeting: Aloha

這個 ConfigMap 名為 greeting-config，包含一個鍵 greeting，值為 Aloha。應用將使用這個值作為問候語。

服務定義如下：

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/name: {{ .圖表.Name }}
  name: {{ .圖表.Name }}
spec:
  ports:
  - name: http
    port: {{ .Values.image.containerPort }}
    targetPort: {{ .Values.image.containerPort }}
  selector:
    app.kubernetes.io/name: {{ .圖表.Name }}

這個服務定義建立了一個與佈署同名的服務，選擇具有相同標籤的 Pod，並將指定連線埠暴露出來。

values.yaml 檔案包含設定引數：

image:
  repository: quay.io/gitops-cookbook/greetings
  tag: "1.0.0"
  pullPolicy: Always
  containerPort: 8080
replicaCount: 1
configmap:
  name: greeting-config

這個 values.yaml 檔案定義了：

容器映像的倉函式庫和標籤
映像提取策略為 Always（總是提取最新映像）
容器連線埠為 8080
佈署副本數為 1
ConfigMap 名稱為 greeting-config

佈署與測試

安裝

helm install greetings .

使用連線埠轉發存取服務：

kubectl port-forward service/greetings 8080:8080

測試服務：

curl localhost:8080
Aloha Ada

這個測試顯示服務正常工作，回傳了 ConfigMap 中設定的問候語 “Aloha”，後面跟著一個隨機名字。

設定更新問題

現在，讓我們嘗試更新 ConfigMap 中的問候語：

apiVersion: v1
kind: ConfigMap
metadata:
  name: greeting-config
data:
  greeting: Hola

更新

helm upgrade greetings .

再次測試服務：

curl localhost:8080
Aloha Alexandra

注意到問題了嗎？儘管我們更新了 ConfigMap，但服務仍然回傳舊的問候語 “Aloha”。這是因為更新 ConfigMap 不會自動觸發 Pod 的重啟，除非 Pod 的定義（如佈署範本）發生了變化。

解決方案：使用 SHA-256 雜湊觸發滾動更新

我們可以使用 Helm 的 sha256sum 函式運算 ConfigMap 的雜湊值，並將其作為 Pod 的註解。這樣，當 ConfigMap 更改時，雜湊值也會改變，從而導致 Pod 的定義發生變化，觸發滾動更新。

修改佈署範本：

spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ .圖表.Name}}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ .圖表.Name}}
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}

這裡關鍵的變化是增加了一個 annotations 部分，其中包含一個名為 checksum/config 的註解。這個註解的值是使用 include 函式讀取 ConfigMap 檔案內容，然後使用 sha256sum 計算雜湊值。當 ConfigMap 內容變化時，雜湊值也會變化，從而觸發 Pod 的重新建立。

再次測試設定更新

更新 ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: greeting-config
data:
  greeting: Namaste

升級

helm upgrade greetings .

檢查 Pod：

kubectl get pods
NAME                        READY   STATUS              RESTARTS   AGE
greetings-5c6b86dbbd-2p9bd  0/1     ContainerCreating  0          3s
greetings-64ddfcb649-m5pml  1/1     Running            0          2m21s

這次我們可以看到滾動更新正在進行中，一個新的 Pod 正在建立，這表明我們的解決方案生效了。

測試服務：

curl localhost:8080
Namaste Alexandra

現在服務回傳了新的問候語 “Namaste”，證明設定更新已成功應用。

我們可以檢查 Pod 的註解來確認雜湊值：

kubectl describe pod greetings-5c6b86dbbd-s4n7b

輸出中顯示了註解：

Annotations: checksum/config: 59e9100616a11d65b691a914cd429dc6011a34e02465173f5f53584b4aa7cba8

雲原生CI/CD的崛起與Tekton的角色

在現代雲原生架構中，自動化佈署流程已成為提升開發效率的關鍵。在前面我們探討了Helm這個強大的Kubernetes範本系統，現在讓我們將視角轉向自動化佈署方面—雲原生持續整合/持續佈署(CI/CD)。

雲原生CI/CD與傳統CI/CD有著根本的區別。在雲原生模型中，整個流程都在雲環境中執行，充分利用雲端服務的彈性與可擴充套件性。這種模式不僅使工作負載能夠在不同雲平台間保持一致性，還為高度可擴充套件的按需使用場景提供了基礎架構。更重要的是，它為GitOps工作流程提供了根本，實作了透過Git操作驅動的自動化佈署。

Tekton作為Kubernetes原生的CI/CD解決方案，完美體現了雲原生CI/CD的精神。它作為Kubernetes的擴充套件執行，提供了一系列自定義資源，讓開發者能夠建構可重用的佈署管道。在接下來的內容中，我將探討Tekton的核心元件，以及如何利用它在Kubernetes環境中實作高效的自動化佈署。

Kustomize與Helm：選擇的考量

在深入Tekton之前，讓我簡單回顧一下關於Kustomize和Helm的選擇問題。根據我的實務經驗，這兩個工具各有所長：

對於簡單專案，特別是隻需要在新佈署間做小幅度修改的情況，Kustomize是更理想的選擇
而對於複雜專案，特別是有外部依賴和多種佈署引數的情況，Helm則提供了更完整的解決方案

選擇合適的工具應該根據專案的具體需求和複雜度，而非盲目追隨技術潮流。接下來，讓我們看如何將這些工具與雲原生CI/CD結合起來。

Tekton：Kubernetes原生CI/CD系統

Tekton是一套建立在Kubernetes之上的開放原始碼雲原生CI/CD系統。它不僅是一個獨立工具，而是作為Kubernetes的擴充套件執行，透過一系列自定義資源定義了可用於建構佈署管道的基本元件。

Tekton引擎位於Kubernetes叢集內部，透過其API物件提供了一種宣告式方法來定義需要執行的操作。其核心元件如Tasks和Pipelines可用於建立管道，從Git儲存函式庫構件和/或容器。

Tekton還支援透過Triggers自動啟動Pipeline的機制，允許從各種來源（如webhook）檢測和提取事件訊息，並相應地啟動Tasks或Pipelines。它還支援處理私有Git儲存函式庫見使用案例，並可以透過多種方式構建構件和建立容器，如使用Buildah或我們在第3章討論的Shipwright。

此外，Tekton可以整合Kustomize和Helm，使CI部分更加動態，並從Kubernetes工具的豐富生態系統中獲益。雖然Tekton是Kubernetes原生解決方案，但它並不是市場上唯一的雲原生CI/CD解決方案。其他適合GitOps工作流程的解決方案還包括Drone和GitHub Actions。

安裝Tekton：建立雲原生CI/CD基礎

要在Kubernetes叢集上實作雲原生CI/CD，首先需要安裝Tekton。這個過程會為你的叢集帶來一系列可用於組合管道的Kubernetes自定義資源(CRDs)。

Tekton的核心元件包括：

Task

一組可重用、鬆耦合的步驟，執行特定功能（如構建容器映像）。Tasks作為Kubernetes pods執行，而Task中的步驟對映到容器。

Pipeline

構建和/或佈署應用所需的Tasks列表，形成完整的工作流程。

TaskRun

執行Task例項的結果和記錄，代表實際的執行過程。

PipelineRun

執行Pipeline例項的結果和記錄，包含多個TaskRuns的集合。

Trigger

偵測事件並連線到其他CRDs，指定當這類別事件發生時應該執行什麼操作。

Tekton管道

Tekton的模組化架構

Tekton具有模組化結構，你可以單獨安裝所有元件，或一次性安裝所有元件（例如使用Operator）：

Tekton Pipelines：包含Tasks和Pipelines
Tekton Triggers：包含Triggers和EventListeners
Tekton Dashboard：方便視覺化Pipelines和日誌的儀錶板
Tekton CLI：用於管理Tekton物件（啟動/停止Pipelines和Tasks，檢視日誌）

你也可以使用Kubernetes Operator來安裝和管理叢集上的Tekton元件。更多詳情可參考OperatorHub。

安裝Tekton Pipelines元件

首先需要安裝Tekton Pipelines元件。以下是使用v0.37.0版本的安裝命令：

kubectl apply \
-f https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.37.0/release.yaml

安裝過程會建立一個名為tekton-pipelines的新Kubernetes名稱空間，你應該會看到類別似以下的輸出：

namespace/tekton-pipelines created
podsecuritypolicy.policy/tekton-pipelines created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-controller-cluster-access created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-controller-tenant-access created
clusterrole.rbac.authorization.k8s.io/tekton-pipelines-webhook-cluster-access created
role.rbac.authorization.k8s.io/tekton-pipelines-controller created
role.rbac.authorization.k8s.io/tekton-pipelines-webhook created
role.rbac.authorization.k8s.io/tekton-pipelines-leader-election created
role.rbac.authorization.k8s.io/tekton-pipelines-info created
serviceaccount/tekton-pipelines-controller created
serviceaccount/tekton-pipelines-webhook created
clusterrolebinding.rbac.authorization.k8s.io/tekton-pipelines-controller-cluster-access created
clusterrolebinding.rbac.authorization.k8s.io/tekton-pipelines-controller-tenant-access created
clusterrolebinding.rbac.authorization.k8s.io/tekton-pipelines-webhook-cluster-access created
rolebinding.rbac.authorization.k8s.io/tekton-pipelines-controller created
rolebinding.rbac.authorization.k8s.io/tekton-pipelines-webhook created
rolebinding.rbac.authorization.k8s.io/tekton-pipelines-controller-leaderelection created
rolebinding.rbac.authorization.k8s.io/tekton-pipelines-webhook-leaderelection created
rolebinding.rbac.authorization.k8s.io/tekton-pipelines-info created
customresourcedefinition.apiextensions.k8s.io/clustertasks.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/pipelines.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/pipelineruns.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/resolutionrequests.resolution.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/pipelineresources.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/runs.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/tasks.tekton.dev created
customresourcedefinition.apiextensions.k8s.io/taskruns.tekton.dev created
secret/webhook-certs created
validatingwebhookconfiguration.admissionregistration.k8s.io/validation.webhook.pipeline.tekton.dev created
mutatingwebhookconfiguration.admissionregistration.k8s.io/webhook.pipeline.tekton.dev created
validatingwebhookconfiguration.admissionregistration.k8s.io/config.webhook.pipeline.tekton.dev created
clusterrole.rbac.authorization.k8s.io/tekton-aggregate-edit created
clusterrole.rbac.authorization.k8s.io/tekton-aggregate-view created
configmap/config-artifact-bucket created
configmap/config-artifact-pvc created
configmap/config-defaults created
configmap/feature-flags created
configmap/pipelines-info created
configmap/config-leader-election created
configmap/config-logging created
configmap/config-observability created
configmap/config-registry-cert created
deployment.apps/tekton-pipelines-controller created
service/tekton-pipelines-controller created
horizontalpodautoscaler.autoscaling/tekton-pipelines-webhook created
deployment.apps/tekton-pipelines-webhook created
service/tekton-pipelines-webhook created

監控和驗證安裝

你可以使用以下命令來監控和驗證安裝：

kubectl get pods -w -n tekton-pipelines

正確安裝後，你應該會看到類別似以下的輸出：

NAME                                           READY   STATUS    RESTARTS   AGE
tekton-pipelines-controller-5fd68749f5-tz8dv   1/1     Running   0          3m4s
tekton-pipelines-webhook-58dcdbfd9b-hswpk      1/1     Running   0          3m4s

注意：上述命令會進入監視模式，因此會持續顯示輸出。當你看到所有Pod都處於Running狀態時，可以按Ctrl+C停止監視。

上面的安裝過程實際上完成了幾個關鍵步驟：

建立了tekton-pipelines名稱空間，用於隔離Tekton相關資源
設定了必要的RBAC許可權（角色和角色繫結）
建立了Tekton所需的自定義資源定義（CRDs）
佈署了Tekton控制器和webhook服務
設定了各種設定對映（ConfigMaps）用於系統設定

這些步驟共同建立了Tekton在Kubernetes叢集上執行所需的基礎設施。控制器負責管理Tekton資源的生命週期，而webhook則負責驗證和修改Tekton資源的建立和更新請求。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。