iT邦幫忙

2025 iThome 鐵人賽

DAY 19
0
Cloud Native

從 Docker 到 K8s:我的 30 天雲原生筆記系列 第 19

Day 19: 設定 GitLab Runner on K8s

  • 分享至 

  • xImage
  •  

哈囉,大家好,歡迎來到我們 CI/CD 的第二天!

在昨天的 Day 18 中,我們介紹了 GitLab CI/CD 的核心觀念,知道了整個自動化流程是透過一份 .gitlab-ci.yml 設定檔來描述流程,而實際執行這些流程的就是 GitLab Runner

今天,我們就要動手做一件非常關鍵的事:在 Kubernetes (K8s) 叢集裡安裝並設定 GitLab Runner。這個 Runner 會是我們未來跑自動化工作的主要執行者。

Part 1:為什麼要在 Kubernetes 上運行 GitLab Runner?

你可能會想:「我可以直接在某台 VM 上裝 GitLab Runner,為什麼還要搞 Kubernetes?」

答案是:這樣做可以帶來更好的彈性、效率和隔離性

當你把 Runner 裝在 K8s 裡,而且使用 Kubernetes Executor 模式,它的運作方式會變得很聰明:

  1. Runner 自己是一個 Pod:它會靜靜地待在叢集中,等候 GitLab 發來任務。
  2. 每個任務都開一個新的 Pod:Runner 不會自己跑任務,而是為每一個 Job 動態建立一個新的 Pod 來執行。
  3. 任務跑完就刪掉 Pod:這些臨時 Pod 任務結束後會自動刪除,不佔資源,也不會留下髒東西。

https://ithelp.ithome.com.tw/upload/images/20250927/201786562GttCtjKSI.png

這樣的方式帶來不少好處:

  • 自動擴展:如果同時有很多任務,Runner 會自己開多個 Pod 並行處理,不會互相卡住。
  • 乾淨的環境:每個任務都在獨立的 Pod 裡執行,彼此不影響,也不會有殘留資料。
  • 資源集中管理:Kubernetes 會幫我們統一管理這些資源,不用手動處理任務排程或資源清理。

Part 2:實戰操作:使用 Helm 安裝 GitLab Runner

在 K8s 裡安裝 GitLab Runner,最推薦的方式是透過 官方 Helm Chart

步驟一:取得註冊權杖 (Registration Token)

Runner 需要一個 Token 才能註冊到 GitLab 專案中。

  1. 開啟 GitLab 專案頁面
  2. 點選左側選單的 Settings > CI/CD
  3. 展開 Runners 區塊
  4. 找到「Register a runner」的區域,把那組註冊 Token 複製下來,等等會用到

步驟二:準備 values.yaml 設定檔

Helm 會透過這個檔案來設定 GitLab Runner 的各項參數。

建立一個名為 gitlab-runner-values.yaml 的檔案:

# gitlab-runner-values.yaml

# GitLab 實例 URL
gitlabUrl: https://gitlab.com/

# 剛剛複製的註冊權杖
runnerRegistrationToken: "YOUR_REGISTRATION_TOKEN"

# RBAC 權限設定
rbac:
  create: true

# Runner 主要設定
runners:
  tags: "kubernetes,ota-project"
  executor: kubernetes
  kubernetes:
    namespace: project-space
    helper_image: "gitlab/gitlab-runner-helper:alpine-x86_64-latest"

步驟三:使用 Helm 安裝 Runner

  1. 加入 GitLab 的 Helm 倉庫:
helm repo add gitlab https://charts.gitlab.com
helm repo update
  1. 執行安裝指令:
helm install gitlab-runner gitlab/gitlab-runner \
  -n gitlab-runner-system \
  --create-namespace \
  -f gitlab-runner-values.yaml
  • gitlab-runner 是這次安裝的名稱
  • gitlab/gitlab-runner 是 Helm Chart 名稱
  • n gitlab-runner-system:將它安裝到一個專屬的 Namespace 中
  • -create-namespace:如果 Namespace 不存在,會自動建立
  • f 載入我們剛剛寫的設定檔

Part 3:確認 Runner 是否安裝成功

從 Kubernetes 檢查:

kubectl get pods -n gitlab-runner-system

你應該會看到類似 gitlab-runner-xxxxxxxxxx-xxxxx 的 Pod,狀態是 Running

從 GitLab UI 確認:

  1. 回到 GitLab 專案的 Settings > CI/CD > Runners
  2. 重新整理頁面
  3. 在「Assigned project runners」那一欄,你會看到一個新的 Runner 出現,狀態是綠色,表示已經連線成功

結語

完成了把 GitLab Runner 安裝到 Kubernetes 上!

  • 為什麼選擇在 K8s 上部署 Runner(彈性、效率、資源管理好)
  • Kubernetes Executor 的運作模式
  • 如何使用 Helm Chart 安裝 GitLab Runner,包括設定與驗證

明天我們會進一步學習怎麼寫 .gitlab-ci.yml,讓這個 Runner 開始真正執行自動化工作流程。明天見!


上一篇
Day 18: CI/CD 是什麼?為什麼它是現代開發的標準配備?
下一篇
Day 20: 撰寫 .gitlab-ci.yml:打造第一條 Pipeline
系列文
從 Docker 到 K8s:我的 30 天雲原生筆記21
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言