Kubernetes 原生 CI/CD：Tekton 核心架構與實務應用完全解析

– 18 分鐘閱讀

理解 Tekton 的核心概念對於有效運用這個雲原生 CI/CD 平台至關重要。作為 Kubernetes 生態系統中的原生持續整合與持續交付解決方案,Tekton 以其宣告式設計、模組化架構與強大的擴展性,重新定義了雲原生環境中的自動化流程。本文將深入探討 Tekton 的工作原理,以及它與傳統 CI/CD 系統的本質差異。

Tekton 的宣告式設計理念

Kubernetes 原生架構優勢

Tekton 的核心特點體現在其宣告式配置方法上。不同於傳統 CI/CD 系統採用的指令式腳本,Tekton 使用 Kubernetes 自定義資源來定義整個 Pipeline 流程。這意味著可以像管理其他 Kubernetes 資源一樣管理 CI/CD Pipeline,透過 YAML 檔案進行定義、版本控制,甚至採用 GitOps 方法進行管理。

這種設計帶來的優勢在實務應用中非常明顯。首先是一致性,使用相同的工具與模式管理應用程式與 CI/CD Pipeline,降低了學習成本與維運複雜度。其次是可移植性,Pipeline 定義可以在任何 Kubernetes 叢集上執行,不受特定 CI/CD 平台的限制。再者是可擴展性,充分利用 Kubernetes 的彈性資源管理能力,根據負載動態調整執行資源。最後是版本控制能力,Pipeline 定義可以像程式碼一樣進行版本管理與審查,實現基礎設施即程式碼的理念。

從架構設計角度來看,Tekton 完全融入 Kubernetes 生態系統。它使用 Custom Resource Definitions 擴展 Kubernetes API,透過 Controller 模式實現自動化管理。這種深度整合讓 Tekton 能夠無縫利用 Kubernetes 的核心功能,包括 Pod 排程、資源配額、命名空間隔離與 RBAC 權限控制等。

宣告式與指令式的本質差異

宣告式設計的核心理念是描述期望的最終狀態,而非執行步驟的細節。在 Tekton 中,定義一個 Task 時,描述的是這個 Task 需要完成什麼工作、需要哪些資源、產生什麼輸出,而不是詳細的執行邏輯。Controller 負責確保系統狀態與宣告的期望狀態一致。

這種方法帶來了更好的容錯性與可預測性。當執行環境發生變化時,Controller 會自動調整以達成期望狀態。同時,宣告式定義更容易理解與維護,團隊成員可以快速掌握 Pipeline 的整體結構與目的。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Tekton 宣告式架構" {
  component "YAML 定義" as yaml {
    [Task 定義]
    [Pipeline 定義]
    [參數配置]
  }
  
  component "Kubernetes API" as api {
    [CRD 註冊]
    [資源驗證]
  }
  
  component "Controller" as ctrl {
    [狀態監控]
    [資源協調]
    [事件處理]
  }
  
  component "執行層" as exec {
    [Pod 建立]
    [容器執行]
    [結果收集]
  }
}

yaml --> api : 提交定義
api --> ctrl : 觸發協調
ctrl --> exec : 建立資源
exec --> ctrl : 回報狀態

note right of yaml
  描述期望狀態
  而非執行步驟
end note

note right of ctrl
  確保實際狀態
  符合期望狀態
end note

@enduml

Task 與 Step 的設計模式

Task 的組成結構

Tekton 的 Task 由一系列 Step 組成,每個 Step 在獨立的容器中執行。這種設計提供了極大的靈活性,因為每個 Step 可以使用不同的基礎映像與工具集,同時仍能透過共享的 Workspace 與 Results 機制進行資料交換。

在設計 Task 時,遵循單一職責原則特別重要。每個 Task 應該專注於一個明確的功能,例如編譯程式碼、執行測試或建立容器映像。這種方法使 Task 更容易重用與維護,也便於在不同 Pipeline 中組合使用。

Task 的關鍵元素包括 params 定義輸入參數,提供執行時的配置能力。workspaces 定義需要的儲存空間,用於與其他 Task 共享資料。steps 定義執行的步驟序列,每個步驟在獨立容器中運行。results 定義輸出結果,供後續 Task 使用。這些元素協同工作,形成完整的任務執行單元。

Step 的容器化執行

每個 Step 本質上是一個容器,可以指定使用的映像、執行的命令與環境變數。這種容器化執行模式帶來多重優勢。首先是環境隔離,每個 Step 擁有獨立的執行環境,避免工具版本衝突。其次是工具選擇自由,可以為不同 Step 選擇最適合的基礎映像。再者是資源控制,可以為個別 Step 設定資源限制與請求。

在實務應用中,Step 的設計應該考慮可重複性與冪等性。每次執行應該產生相同的結果,不受執行順序或環境差異影響。同時,Step 之間應該透過明確的介面進行資料傳遞,避免隱含的依賴關係。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Task 執行結構" {
  rectangle "Task Pod" {
    component "Step 1" as s1 {
      [容器映像 A]
      [執行命令]
      [環境變數]
    }
    
    component "Step 2" as s2 {
      [容器映像 B]
      [執行命令]
      [環境變數]
    }
    
    component "Step 3" as s3 {
      [容器映像 C]
      [執行命令]
      [環境變數]
    }
    
    component "Workspace" as ws
  }
}

s1 --> s2 : 順序執行
s2 --> s3 : 順序執行
s1 ..> ws : 共享儲存
s2 ..> ws : 共享儲存
s3 ..> ws : 共享儲存

note right of s1
  獨立容器執行
  可使用不同映像
end note

note bottom of ws
  提供跨 Step
  的資料共享
end note

@enduml

Workspace 資源共享機制

Workspace 的設計目的

Tekton 中的資源共享透過 Workspace 機制實現。Workspace 可以視為 Task 之間的共享儲存空間,用於傳遞建置產物、配置檔案或其他資料。這種抽象層讓 Task 定義與實際儲存實作分離,提升了 Task 的可重用性。

Workspace 支援多種儲存後端。PersistentVolumeClaim 提供持久化儲存,適合需要長期保存的資料。ConfigMap 適用於小型配置檔案的共享。Secret 用於敏感資訊的安全傳遞。emptyDir 提供臨時儲存,Task 執行完成後會被清理。這種多樣化的支援讓開發者可以根據實際需求選擇最適合的儲存方案。

Workspace 的最佳實踐

在實務應用中,Workspace 的使用策略需要仔細考量。對於需要在多個 Task 間共享大量資料的場景,PersistentVolumeClaim 是最佳選擇,可以確保資料持久性與可靠性。對於只在單個 Task 執行期間需要的臨時儲存,emptyDir 更為經濟實惠,執行完成後自動清理也減少了管理負擔。對於配置資訊的共享,ConfigMap 提供了清晰的配置管理方式,便於版本控制與審計。

Workspace 的命名應該遵循清晰的規範,反映其用途與內容。例如使用 source 表示原始碼儲存,build-output 表示建置產物,maven-settings 表示 Maven 配置等。這種語意化的命名讓 Pipeline 定義更容易理解與維護。

在設計 Pipeline 時,應該明確規劃 Workspace 的使用策略。哪些資料需要持久化、哪些只需要臨時儲存、哪些需要在整個 Pipeline 中共享、哪些只在特定 Task 間傳遞。清晰的資料流設計是構建高效 Pipeline 的基礎。

Tekton 擴展元件生態

Triggers 事件驅動機制

Tekton Triggers 元件實現了事件驅動的工作流程,允許根據外部事件自動啟動 Pipeline。當 Git 伺服器發送 webhook、Pull Request 被建立或其他系統產生事件時,Triggers 可以自動觸發對應的 Pipeline 執行。這使得 Tekton 成為實現 GitOps 工作流程的理想選擇。

Triggers 由三個核心元件組成。EventListener 作為 webhook 接收端點,監聽外部事件。TriggerBinding 從事件負載中提取關鍵資訊,轉換為參數格式。TriggerTemplate 使用這些參數建立實際的 Pipeline 執行實例。這三個元件協同工作,形成完整的事件處理鏈路。

安裝 Tekton Triggers 擴展了 Tekton 的自動化能力。

kubectl apply -f https://storage.googleapis.com/tekton-releases/triggers/previous/v0.20.1/release.yaml

安裝過程會建立多個 Kubernetes 資源,包括 RBAC 角色與角色綁定用於權限控制,CRD 定義 EventListener、TriggerBinding、TriggerTemplate 等資源類型,Controller 與 Webhook 部署管理 Triggers 功能,以及 Interceptor 處理來自不同來源的事件格式。

驗證安裝狀態可以透過監控 Pod 的啟動情況。

kubectl get pods -w -n tekton-pipelines

成功安裝後,會看到三個新的 Pod 運行。tekton-triggers-controller 管理 Triggers 資源的生命週期。tekton-triggers-core-interceptors 處理各種來源事件的核心攔截器,支援 GitHub、GitLab 等平台的 webhook 格式。tekton-triggers-webhook 處理 API 驗證與轉換,確保資源定義的正確性。

Dashboard 視覺化管理介面

雖然命令列工具提供了強大的控制能力,但圖形化介面能夠帶來更直觀的操作體驗。Tekton Dashboard 提供了簡潔的 Web 介面,讓管理 Task、Pipeline 以及檢視執行日誌變得更加容易。

安裝 Dashboard 擴展了 Tekton 的可用性。

kubectl apply -f https://storage.googleapis.com/tekton-releases/dashboard/previous/v0.28.0/tekton-dashboard-release.yaml

安裝完成後,Dashboard 服務預設只能從叢集內部存取。使用 port-forward 功能可以從本地機器存取 Dashboard。

kubectl port-forward svc/tekton-dashboard 9097:9097 -n tekton-pipelines

這個命令在本地 9097 連接埠與叢集中的 Dashboard 服務之間建立通道。隨後可以透過瀏覽器存取 http://localhost:9097 開啟 Dashboard 介面。在生產環境中,通常會透過 Ingress 或 LoadBalancer 暴露服務,並配置適當的認證與授權機制。

Dashboard 提供了豐富的功能。可以檢視所有 Task、Pipeline 與執行歷史,即時監控執行狀態與進度,檢視詳細的執行日誌與錯誤訊息,觸發新的 Pipeline 執行,管理 Workspace、Secret 等資源。這些功能讓團隊成員即使不熟悉 kubectl 命令,也能有效管理 CI/CD 流程。

CLI 工具的強大功能

Tekton CLI 工具提供了靈活且高效的命令列操作介面。安裝後可以透過簡潔的命令管理 Tekton 資源。

tkn version

這個命令顯示 CLI 工具本身的版本,以及叢集中安裝的各個 Tekton 元件版本,包括 Pipeline、Triggers、Dashboard 等。版本資訊對於問題排查與相容性確認非常重要。

tkn 命令提供了豐富的子命令與選項。tkn task start 啟動 Task 執行,支援互動式參數輸入或使用預設值。tkn pipeline start 啟動 Pipeline 執行,可以指定參數與 Workspace 配置。tkn taskrun logs 檢視 TaskRun 的執行日誌,支援即時追蹤。tkn pipelinerun list 列出 Pipeline 執行歷史,顯示狀態與時間資訊。

這些命令大幅簡化了日常操作,特別是在開發與除錯階段。相比直接操作 YAML 檔案與 kubectl 命令,tkn 提供了更高層次的抽象,讓開發者能夠專注於業務邏輯而非底層細節。

@startuml
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

package "Tekton 擴展元件" {
  component "Triggers" as triggers {
    [EventListener]
    [TriggerBinding]
    [TriggerTemplate]
  }
  
  component "Dashboard" as dashboard {
    [Web 介面]
    [資源管理]
    [日誌檢視]
  }
  
  component "CLI" as cli {
    [task 命令]
    [pipeline 命令]
    [資源操作]
  }
}

component "外部事件" as event
component "使用者" as user
component "Tekton Core" as core

event --> triggers : webhook
triggers --> core : 建立 PipelineRun
user --> dashboard : 視覺化管理
user --> cli : 命令列操作
dashboard --> core : API 呼叫
cli --> core : API 呼叫

note right of triggers
  事件驅動自動化
  支援多種 webhook
end note

note right of dashboard
  圖形化管理介面
  降低使用門檻
end note

@enduml

建立第一個 Tekton Task

Task 的基本結構

Task 是 Tekton 中最基本的執行單元,定義了一系列按順序執行的 Step。每個 Task 在 Kubernetes 叢集中以 Pod 的形式執行,Task 中的每個 Step 則在 Pod 內的不同容器中執行。雖然 Task 內部的 Step 按順序執行,但多個 Task 可以在 Pipeline 中平行執行,實現高效的工作流程協調。

建立一個簡單的 Hello World Task 可以幫助理解 Tekton 的基本運作原理。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: hello
spec:
  steps:
  - name: say-hello
    image: registry.access.redhat.com/ubi8/ubi
    command:
    - /bin/bash
    args:
    - -c
    - echo Hello GitOps Cookbook reader!

這個 Task 定義展示了 Tekton 資源的基本結構。apiVersion 與 kind 宣告這是一個 Tekton Task 資源,遵循 Kubernetes API 的標準格式。metadata.name 定義 Task 的名稱為 hello,這個名稱在命名空間內必須唯一。spec.steps 包含 Task 要執行的步驟清單,這裡只有一個步驟。

步驟定義指定了執行細節。name 欄位為步驟命名,便於日誌追蹤與問題定位。image 指定使用的容器映像,這裡使用 Red Hat Universal Base Image 作為執行環境。command 定義要執行的命令,這裡是 bash shell。args 提供命令的參數,這裡是一個簡單的 echo 命令。

部署與執行 Task

建立 Task 定義後,需要將其部署到 Kubernetes 叢集。

kubectl create -f helloworld-task.yaml

成功建立後會看到確認訊息,表示 Task 資源已經註冊到叢集中。驗證 Task 是否正確建立可以使用查詢命令。

kubectl get tasks

這會列出命名空間中所有的 Task 資源,包括剛建立的 hello Task。

執行 Task 可以使用 Tekton CLI 工具。

tkn task start --showlog hello

showlog 參數讓 tkn 直接顯示 Task 執行的日誌輸出,無需另外查詢。這對於簡單 Task 的測試與驗證非常方便。執行後可以看到 Task 的完整輸出,包括系統訊息與自訂的 echo 內容。

在底層,tkn task start 命令實際上建立了一個 TaskRun 資源。TaskRun 是 Task 的執行實例,記錄了執行狀態、開始時間、完成時間、執行結果等資訊。每次執行 Task 都會建立新的 TaskRun,這種設計確保了執行歷史的完整性與可追溯性。

建立應用建置 Task

Task 的進階設計

在實際應用中,Task 通常需要處理更複雜的工作流程。以下展示一個從 Git 倉庫獲取原始碼並編譯的完整 Task。

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-app
spec:
  workspaces:
  - name: source
    description: Git 倉庫將被複製到此工作空間
  params:
  - name: contextDir
    description: 原始碼的上下文目錄
    default: quarkus
  - name: url
    description: Git 倉庫 URL
    default: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: revision
    description: Git 分支或標籤
    default: master
  - name: sslVerify
    description: Git SSL 驗證設定
    type: string
    default: "false"
  steps:
  - name: clone
    image: gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-init:v0.21.0
    script: |
      CHECKOUT_DIR="$(workspaces.source.path)"
      
      cleandir() {
        if [[ -d "$CHECKOUT_DIR" ]]; then
          rm -rf "$CHECKOUT_DIR"/*
          rm -rf "$CHECKOUT_DIR"/.[!.]*
          rm -rf "$CHECKOUT_DIR"/..?*
        fi
      }
      
      cleandir
      
      /ko-app/git-init \
        -url "$(params.url)" \
        -revision "$(params.revision)" \
        -path "$CHECKOUT_DIR" \
        -sslVerify="$(params.sslVerify)"
      
      cd "$CHECKOUT_DIR"
      RESULT_SHA="$(git rev-parse HEAD)"
      echo "複製完成,提交雜湊: $RESULT_SHA"
  
  - name: build-sources
    image: gcr.io/cloud-builders/mvn
    command:
    - mvn
    args:
    - -DskipTests
    - clean
    - install
    env:
    - name: user.home
      value: /home/tekton
    workingDir: /workspace/source/$(params.contextDir)

這個 Task 展示了多個進階特性。workspaces 定義了 Task 需要的儲存空間,這裡定義了一個 source 工作空間用於儲存原始碼。params 定義了多個可配置參數,每個參數都有描述與預設值,提升了 Task 的靈活性與可重用性。

clone 步驟負責從 Git 倉庫獲取原始碼。使用專門的 git-init 容器映像,這是 Tekton 官方提供的工具映像。script 欄位包含完整的 shell 腳本,處理目錄清理與 Git 操作。cleandir 函式確保工作目錄乾淨,避免殘留檔案影響建置。git-init 工具執行實際的 Git 複製操作,使用參數化的 URL 與 revision。

build-sources 步驟執行實際的建置工作。使用 Maven 容器映像,包含完整的 Java 建置環境。command 與 args 定義要執行的 Maven 命令,這裡執行清理與安裝操作,跳過測試以加速建置。env 設定必要的環境變數,Maven 需要知道使用者主目錄位置。workingDir 指定工作目錄,指向 clone 步驟輸出的原始碼位置。

這種多步驟設計充分展示了 Tekton 的靈活性。每個步驟使用最適合的工具映像,透過 Workspace 共享資料,透過參數接收配置,形成完整且可重用的建置單元。

參數化設計的價值

Task 的參數化設計讓同一個 Task 定義可以適應多種使用場景。透過修改參數值,可以建置不同的專案、不同的分支、使用不同的建置選項。這種靈活性大幅提升了 Task 的重用性,避免為每個專案建立專用的 Task 定義。

在設計參數時,應該提供合理的預設值。這讓簡單場景可以快速使用,同時保留客製化的能力。參數描述應該清晰說明用途與可能的取值,便於使用者理解與配置。參數類型應該正確宣告,確保類型安全與驗證。

TaskRun 執行管理

TaskRun 的角色定位

TaskRun 是 Task 執行時的 API 表示,記錄了執行的所有細節。當啟動一個 Task 時,Tekton 會建立對應的 TaskRun 資源。TaskRun 追蹤執行狀態,從 Pending 等待執行,到 Running 正在執行,最終到達 Succeeded 成功完成或 Failed 執行失敗。

TaskRun 儲存了完整的執行上下文,包括使用的參數值、Workspace 配置、執行開始與結束時間、每個 Step 的執行狀態、完整的執行日誌、輸出的 Results 資料。這些資訊對於問題追蹤、效能分析、審計追蹤都非常重要。

使用 CLI 啟動 TaskRun

最直接的執行方式是使用 tkn 命令列工具。

tkn task start build-app \
  --param contextDir=quarkus \
  --workspace name=source,emptyDir="" \
  --showlog

這個命令啟動 build-app Task 的執行。param 參數覆寫 Task 定義中的預設值,這裡指定 contextDir 為 quarkus。workspace 參數配置工作空間,這裡使用 emptyDir 提供臨時儲存。showlog 參數讓命令直接顯示執行日誌,方便即時追蹤。

如果希望使用 Task 定義中的所有預設值而不進行互動式提示,可以增加 use-param-defaults 選項。這在自動化腳本中特別有用,避免需要人工輸入。

宣告式 TaskRun 定義

除了使用 CLI,也可以直接建立 TaskRun YAML 定義。

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  generateName: build-app-run-
spec:
  params:
  - name: contextDir
    value: quarkus
  - name: url
    value: https://github.com/gitops-cookbook/tekton-tutorial-greeter.git
  - name: revision
    value: master
  - name: sslVerify
    value: "false"
  taskRef:
    kind: Task
    name: build-app
  workspaces:
  - name: source
    emptyDir: {}

這個 TaskRun 定義展示了宣告式管理的方式。generateName 使用名稱前綴,Kubernetes 會自動加上隨機後綴生成唯一名稱,避免重複執行時的命名衝突。params 明確列出所有參數值,覆寫 Task 的預設配置。taskRef 參照要執行的 Task,建立執行關聯。workspaces 為 Task 提供所需的儲存空間。

使用 kubectl 建立 TaskRun 會觸發實際執行。

kubectl create -f build-app-taskrun.yaml

這種方式在自動化流程中更為常用,可以將 TaskRun 定義納入版本控制,實現可重複的執行配置。

執行狀態追蹤

檢視所有 TaskRun 的狀態可以使用列表命令。

tkn taskrun ls

輸出顯示 TaskRun 名稱、對應的 Task、執行狀態、開始時間與持續時間等資訊。這提供了整體的執行概況,便於識別問題與監控進度。

檢視特定 TaskRun 的詳細日誌可以使用日誌命令。

tkn taskrun logs build-app-run-65vmh -f

f 參數啟用追蹤模式,持續顯示新的日誌輸出,類似 tail -f 的行為。日誌包含每個 Step 的完整輸出,對於問題診斷與執行驗證非常重要。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

[*] --> Pending : 建立 TaskRun

state Pending {
  [*] --> 等待資源
  等待資源 --> 排程Pod
}

Pending --> Running : Pod 啟動

state Running {
  [*] --> Step1
  Step1 --> Step2 : 完成
  Step2 --> Step3 : 完成
  Step3 --> [*]
}

Running --> Succeeded : 所有 Step 成功
Running --> Failed : 任一 Step 失敗
Succeeded --> [*]
Failed --> [*]

note right of Pending
  等待 Kubernetes
  排程執行資源
end note

note right of Running
  依序執行
  Task 中的 Step
end note

@enduml

私有 Git 倉庫整合

認證機制選擇

在企業環境中,大多數程式碼儲存在私有 Git 倉庫中,需要適當的認證機制才能存取。Tekton 支援兩種主要的 Git 認證方式,各有其適用場景與安全考量。

基本認證使用使用者名稱與密碼或個人存取權杖進行認證。這種方式設定簡單,與大多數 Git 平台相容性良好,特別是 GitHub、GitLab 等服務。在實務中,強烈建議使用個人存取權杖而非明文密碼,並設定適當的權限範圍,僅授予必要的存取權限。

SSH 認證使用 SSH 金鑰對進行認證。這種方式安全性更高,不需要在網路上傳輸密碼,支援更細緻的權限控制。SSH 金鑰應該專門為 CI/CD 用途生成,避免與個人金鑰混用。私鑰需要妥善保管,定期輪換以降低洩露風險。

兩種認證方式都需要透過 Kubernetes Secret 儲存認證資訊,並將 Secret 關聯到執行 Task 的 ServiceAccount。這種設計將認證資訊與 Task 定義分離,提升了安全性與靈活性。

設定基本認證

建立包含 GitHub 認證資訊的 Secret 是第一步。

apiVersion: v1
kind: Secret
metadata:
  name: github-secret
  annotations:
    tekton.dev/git-0: https://github.com
type: kubernetes.io/basic-auth
stringData:
  username: YOUR_USERNAME
  password: YOUR_PERSONAL_ACCESS_TOKEN

這個 Secret 定義包含關鍵元素。annotations 中的 tekton.dev/git-0 指定此 Secret 用於 GitHub 的認證,Tekton 會在存取 GitHub URL 時自動使用此憑證。type 宣告為 basic-auth 類型,符合基本認證的標準格式。stringData 包含實際的認證資訊,username 是 GitHub 使用者名稱,password 應該填入個人存取權杖而非帳號密碼。

也可以使用 kubectl 命令直接建立 Secret,避免撰寫 YAML 檔案。

kubectl create secret generic github-secret \
  --type=kubernetes.io/basic-auth \
  --from-literal=username=YOUR_USERNAME \
  --from-literal=password=YOUR_PERSONAL_ACCESS_TOKEN

kubectl annotate secret github-secret "tekton.dev/git-0=https://github.com"

第一個命令建立 Secret 並填入認證資訊。第二個命令增加註解,指定 Secret 的用途。這種方式在腳本化部署時更為便利。

配置 ServiceAccount

建立 Secret 後,需要將其關聯到 ServiceAccount,讓 Task 能夠使用認證資訊。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tekton-bot-sa
secrets:
- name: github-secret

這個 ServiceAccount 定義將 github-secret 關聯起來。當 Task 使用此 ServiceAccount 執行時,Tekton 會自動配置 Git 認證,無需在 Task 定義中明確處理。

使用 kubectl 命令可以建立 ServiceAccount 並關聯 Secret。

kubectl create serviceaccount tekton-bot-sa
kubectl patch serviceaccount tekton-bot-sa \
  -p '{"secrets": [{"name": "github-secret"}]}'

第一個命令建立 ServiceAccount。第二個命令使用 patch 操作將 Secret 關聯到 ServiceAccount。這種方式適合動態調整配置。

使用認證執行 Task

配置完成後,執行 Task 時只需指定使用對應的 ServiceAccount。

tkn task start build-app \
  --serviceaccount=tekton-bot-sa \
  --param url=https://github.com/gitops-cookbook/tekton-greeter-private.git \
  --param contextDir=quarkus \
  --workspace name=source,emptyDir="" \
  --showlog

serviceaccount 參數指定使用 tekton-bot-sa,Tekton 會自動處理 Git 認證。url 參數指向私有倉庫,無需額外的認證配置。執行成功後,日誌會顯示成功複製私有倉庫的訊息,確認認證機制正常運作。

在實務應用中,應該為不同的用途建立專用的 ServiceAccount。例如,建置應用的 ServiceAccount、部署應用的 ServiceAccount、管理基礎設施的 ServiceAccount 等。這種職責分離提升了安全性,限制了潛在的安全風險範圍。

安全性最佳實踐

Secret 管理策略

Secret 包含敏感的認證資訊,需要特別注意安全管理。首先,Secret 應該使用 Kubernetes 的 RBAC 機制進行存取控制,只有必要的 ServiceAccount 能夠讀取特定的 Secret。其次,Secret 應該定期輪換,特別是長期使用的認證資訊,降低洩露後的影響範圍。

在生產環境中,建議使用外部密鑰管理系統,例如 HashiCorp Vault、AWS Secrets Manager 或 Azure Key Vault。這些系統提供了更強大的安全功能,包括審計日誌、自動輪換、細緻的權限控制等。Tekton 可以透過 Kubernetes External Secrets Operator 等工具整合這些系統。

Secret 的備份與災難恢復策略也很重要。雖然 Secret 通常不應該直接匯出,但需要有可靠的恢復機制,確保系統故障後能夠快速重建認證配置。

ServiceAccount 權限最小化

ServiceAccount 的權限應該遵循最小權限原則,只授予執行必要操作所需的最低權限。例如,建置應用的 ServiceAccount 只需要讀取 Git 倉庫與推播容器映像的權限,不需要修改 Kubernetes 資源的權限。

使用 RBAC 精細控制 ServiceAccount 的權限範圍。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tekton-task-role
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: ["tekton.dev"]
  resources: ["taskruns", "pipelineruns"]
  verbs: ["get", "list", "create"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tekton-task-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tekton-task-role
subjects:
- kind: ServiceAccount
  name: tekton-bot-sa

這個 RBAC 配置定義了限定範圍的權限。ServiceAccount 只能讀取 Pod 與日誌,以及建立與檢視 Tekton 資源,無法修改或刪除已存在的資源。這種精細的權限控制降低了安全風險。

網路安全考量

在 Kubernetes 環境中,網路策略可以進一步限制 Task 的網路存取。例如,只允許 Task Pod 存取特定的 Git 伺服器與容器註冊表,禁止存取其他內部服務。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tekton-task-netpol
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/managed-by: tekton-pipelines
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 443

這個網路策略允許 Tekton Task Pod 進行 DNS 查詢與 HTTPS 連線,但限制了其他類型的網路存取。根據實際需求調整策略,在安全性與功能性之間取得平衡。

總結與最佳實踐建議

Tekton 的核心價值

Tekton 作為 Kubernetes 原生的 CI/CD 解決方案,透過宣告式設計、模組化架構與強大的擴展性,重新定義了雲原生環境中的自動化流程。它完全融入 Kubernetes 生態系統,充分利用 Kubernetes 的核心能力,實現了真正的雲原生 CI/CD。

宣告式設計讓 Pipeline 定義更容易理解與維護,版本控制讓變更可追溯,GitOps 方法讓基礎設施管理更加規範。模組化架構讓 Task 可以靈活組合與重用,大幅提升了開發效率。事件驅動機制實現了自動化觸發,減少了人工介入,加速了交付週期。

實務應用建議

在實際應用 Tekton 時,遵循一些最佳實踐可以提升系統的可維護性與可靠性。Task 設計應該遵循單一職責原則,每個 Task 專注於明確的功能,便於重用與組合。參數化設計提升 Task 的靈活性,合理的預設值簡化使用複雜度。

Workspace 選擇應該根據資料特性決定,持久化需求使用 PVC,臨時儲存使用 emptyDir,配置資訊使用 ConfigMap。清晰的命名規範讓資源用途一目了然,便於團隊協作。

安全性應該貫穿整個設計過程。Secret 管理遵循最小權限原則,ServiceAccount 權限精細控制,網路策略限制不必要的存取。定期審計與輪換認證資訊,降低安全風險。

監控與日誌對於生產環境至關重要。建立完善的監控體系,追蹤 Pipeline 執行狀況與資源使用情況。集中管理日誌,便於問題排查與效能分析。設定告警規則,及時發現異常並採取行動。

持續學習與演進

Tekton 生態系統持續發展,新功能與最佳實踐不斷湧現。建議定期關注官方文件與社群動態,瞭解最新的發展趨勢。參與社群討論,分享經驗與學習他人的實踐。

從簡單開始,逐步掌握 Tekton 的核心概念與使用方法。隨著經驗累積,探索更進階的功能,建構符合團隊需求的自動化系統。持續最佳化與改進,讓 CI/CD 流程更加高效與可靠。

在雲原生時代,自動化是提升競爭力的關鍵。Tekton 提供了強大的工具與靈活的架構,讓團隊能夠建構真正現代化的 CI/CD 系統,支撐業務的快速發展與創新。

玄貓 BlackCat

玄貓 BlackCat

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