GitOps K8s 自動化佈署：自動化佈署的實戰之路

– 21 分鐘閱讀

在雲原生技術快速發展的今天，Kubernetes 已成為容器協調的標準平台，而 GitOps 則是在這個基礎上發展出的一套強大的交付方法論。作為一種以 Git 為唯一真相來源的操作模式，GitOps 徹底改變了我們佈署和管理應用程式的方式。

在實作 Kubernetes 平台上的自動化佈署時，我發現 GitOps 不僅是一種工具選擇，更是一種思維方式的轉變。透過將基礎架構與應用程式設定以程式碼形式存放在 Git 儲存函式庫我們獲得了前所未有的可追蹤性、一致性和自動化程度。

為何選擇 GitOps？

在多年的雲端技術實踐中，我觀察到許多團隊在 Kubernetes 上實作自動化佈署時遇到的挑戰：

  1. 環境一致性難以保證 - 開發、測試和生產環境之間的設定漂移導致「在我機器上可以執行」的問題
  2. 佈署過程不透明 - 難以追蹤誰在何時做了什麼更改，以及為什麼
  3. 回復困難 - 當佈署出現問題時，很難快速可靠地還原到之前的狀態
  4. 許可權控制複雜 - 在多團隊環境中管理誰可以對特定環境進行更改

GitOps 透過將 Git 作為單一真相來源，優雅地解決了這些問題。當所有更改都必須透過 Git 提交和審核流程，我們自然而然地建立了一個可審核、可回復與安全的佈署流程。

本文將涵蓋的內容

在這篇技術深度文章中，我將分享在實際專案中實施 GitOps 的經驗和最佳實踐，內容包括：

  • GitOps 的核心原則與實踐方法
  • Kubernetes 環境的基礎設施準備
  • 容器建置與管理的實用技巧
  • 使用 Kustomize 和 Helm 管理 Kubernetes 資源
  • 根據 Tekton 的雲原生 CI/CD 流程設計
  • 利用 Argo CD 實作 GitOps 風格的持續佈署
  • 進階主題：敏感資訊管理、漸進式佈署與多叢集策略

讓我們開始這段 GitOps 的實踐之旅，探索如何在 Kubernetes 上建立一個強大、可靠與高效的自動化佈署流程。

GitOps 的核心原則與實踐基礎

GitOps 作為一種操作模型，雖然概念簡單，但實踐起來需要對其核心原則有深入理解。在我看來，GitOps 的精髓可以歸納為四個關鍵原則：

宣告式系統的優勢

傳統的命令式操作方法關注「如何做」，而 GitOps 採用的宣告式方法則專注於「做什麼」。這一轉變看似微小，實則意義重大。

# 宣告式設定範例 - Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

這段 YAML 設定展示了 Kubernetes 的宣告式本質 - 我們定義了一個包含 3 個 nginx 容器副本的佈署，而不是一步指令如何建立每個容器。系統會持續比對這個「期望狀態」與「實際狀態」，並自動調整以達成一致。這種宣告式方法使得系統設定更加清晰、可維護，與能自我修復。

Git 作為唯一真相來源

在 GitOps 中，Git 儲存函式庫是程式碼的保管者，更是系統期望狀態的唯一權威來源。這帶來幾個關鍵優勢：

  1. 歷史追蹤 - 每一次變更都有完整的提交記錄
  2. 變更審核 - 透過 Pull Request/Merge Request 機制實作變更審查
  3. 回復能力 - 可以輕鬆回復到任何歷史版本
  4. 合規性 - 提供完整的稽核軌跡

在實踐中，我發現將系統設定存放在 Git 中還帶來了一個意想不到的好處：它促使團隊成員更加謹慎地考慮每一次變更，因為這些變更將被永久記錄並接受同儕審查。

自動化佈署與協調

GitOps 的核心在於自動化 - 系統會自動檢測 Git 儲存函式庫變更，並將這些變更應用到實際環境中。這一過程通常由專門的協調工具完成，如 Argo CD 或 Flux。

協調工具的工作流程通常包括：

  1. 持續監控 Git 儲存函式庫更
  2. 檢測實際環境與期望狀態之間的偏差
  3. 自動調整實際環境以比對期望狀態
  4. 報告同步狀態和任何錯誤

這種自動化不僅提高了佈署效率，還減少了人為錯誤，確保了環境的一致性。

持續驗證與偏差檢測

在 GitOps 模型中，協調器不僅負責初始佈署，還會持續監控系統狀態，確保實際環境與 Git 中定義的期望狀態保持一致。

這一機制解決了傳統佈署方法中的一個常見問題：環境漂移。當有人繞過正規流程直接修改環境時，協調器會檢測到這種偏差並自動糾正，確保系統始終反映 Git 中定義的狀態。

這種「自癒」能力在大規模多團隊環境中尤為重要，它確保了系統的可靠性和一致性，無論是面對意外變更還是惡意攻擊。

GitOps 與 DevOps 的關係

值得注意的是，GitOps 並非要取代 DevOps，而是對其的補充和延伸。DevOps 關注的是文化和協作方式，而 GitOps 則提供了在 Kubernetes 等雲原生環境中實作這些理念的具體方法。

GitOps 可以看作是 DevOps 實踐在雲原生時代的自然演化，它繼承了 DevOps 的核心價值觀 - 自動化、協作和持續改進，同時增加了更多針對容器和 Kubernetes 環境的具體實作方式。

在下一節中，我們將探討實施 GitOps 所需的基礎設施和工具準備工作，為動手實踐打下堅實基礎。

Kubernetes 環境準備與基礎設施要求

要成功實施 GitOps，首先需要準備好合適的基礎設施環境。無論您是在公有雲、私有雲還是混合環境中工作，以下是幾個關鍵元件：

Git 儲存函式庫

作為 GitOps 的核心，正確設定 Git 儲存函式庫重要。在實踐中，我通常建議採用以下儲存函式庫：

gitops-repo/
├── apps/
│   ├── app1/
│   │   ├── base/
│   │   └── overlays/
│   │       ├── dev/
│   │       ├── staging/
│   │       └── production/
│   └── app2/
│       └── ...
├── clusters/
│   ├── cluster1/
│   └── cluster2/
└── platform/
    ├── monitoring/
    ├── logging/
    └── security/

這種儲存函式庫將應用程式設定與平台級服務分開管理。「apps」目錄包含各個應用程式的 Kubernetes 資源定義，並使用「base/overlays」模式支援不同環境的設定變化。「clusters」目錄包含特定叢集的設定，而「platform」則包含跨應用程式的分享服務。這種結構提供了良好的關注點分離，使不同團隊能夠獨立工作而不會互相干擾。

對於許可權管理，我建議使用 Git 平台（如 GitHub、GitLab 或 Bitbucket）的分支保護和審核功能，確保只有授權人員才能更改關鍵環境的設定。

容器登入檔選擇與設定

容器映像是 Kubernetes 佈署的基本構建塊，因此選擇合適的容器登入檔至關重要。主要選項包括：

  1. 公共登入檔：Docker Hub、Quay.io、GitHub Container Registry
  2. 雲供應商登入檔：AWS ECR、Google Container Registry、Azure Container Registry
  3. 私有登入檔：Harbor、Nexus Repository、JFrog Artifactory

在選擇時，需考慮以下因素：

  • 安全性要求（漏洞掃描、簽名驗證）
  • 存取控制需求
  • 網路延遲和頻寬成本
  • 整合能力（與 CI/CD 系統的整合）

以下是設定私有登入檔認證的 Kubernetes Secret 範例：

apiVersion: v1
kind: Secret
metadata:
  name: registry-credentials
  namespace: my-namespace
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-docker-config>

Kubernetes 叢集需求

GitOps 可以在各種 Kubernetes 環境中實作，從單節點的 Minikube 到大型生產叢集。以下是我對不同場景的建議：

開發和測試環境：

  • K3d、Kind 或 Minikube 適合本地開發
  • 最低資源要求：2 CPU、4GB RAM

生產環境：

  • 代管 Kubernetes 服務（EKS、GKE、AKS）或自管理叢集（OpenShift、Rancher）
  • 建議至少 3 個主節點和適量的工作節點
  • 節點自動擴充套件能力
  • 網路策略支援
  • 負載平衡器整合

無論選擇何種環境，確保 Kubernetes 版本不低於 1.16，以支援最新的 API 資源和功能。

重要工具安裝

以下是實施 GitOps 所需的核心命令列工具：

  1. kubectl：Kubernetes 命令列工具
  2. git：版本控制系統
  3. helm：Kubernetes 包管理工具
  4. kustomize：Kubernetes 組態管理工具
  5. argocd CLI：Argo CD 命令列工具
  6. tekton CLI：Tekton 命令列工具

以下是安裝這些工具的簡單指令（以 Linux 為例）：

# 安裝 kubectl
curl -LO "https://dl.k8s.io/release/stable.txt"
curl -LO "https://dl.k8s.io/release/$(cat stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# 安裝 Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# 安裝 kustomize
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash
sudo mv kustomize /usr/local/bin/

這些安裝指令提供了設定 GitOps 工作環境的基礎。kubectl 是與 Kubernetes API 互動的主要工具；Helm 用於管理複雜應用的封裝和佈署；kustomize 則用於自定義 Kubernetes 資源而無需修改原始檔案。這三個工具構成了 GitOps 工作流程的基礎，讓您能夠管理、自定義和佈署應用到 Kubernetes 叢集。

網路與安全考量

在設定 GitOps 環境時，需要考慮以下網路和安全方面的因素：

  1. 叢集網路策略：限制 Pod 之間的通訊，增強安全性
  2. 入口控制器：設定適當的入口控制器以管理外部流量
  3. 證書管理：設定 cert-manager 等工具自動管理 TLS 證書

GitOps 的崛起：現代基礎設施管理的革命性方法

在現代軟體開發的演進中，我們見證了一個明顯的轉變：開發者的責任已從純粹的應用程式碼撰寫，擴充套件到了基礎設施的定義與管理。這種轉變並非偶然，而是由可程式化、API 驅動的平台如公有雲和開放原始碼基礎設施解決方案所推動。這些平台賦予了開發者前所未有的控制力，同時也實作了自動化，顯著縮短了交付週期。

在這個轉變的核心，Kubernetes 已成為容器工作負載協調的標準，而 GitOps 則進一步擴充套件了這個正規化，建立了一套以 Git 為中心的基礎設施管理方法論。在多年的技術實踐中，玄貓觀察到 GitOps 不僅是一種技術選擇，更是一種能夠徹底改變團隊交付文化的方法論。

GitOps 的本質：超越工具的方法論

GitOps 本質上是一種方法論和實踐，它使用 Git 儲存函式庫單一事實來源，實作基礎架構即程式碼的交付。它汲取了 DevOps 文化的核心支柱和方法，提供了一個實作結果的具體框架。

從技術層面看，GitOps 可以概括為三個核心支柱：

  1. Git 作為單一事實來源 - 所有系統設定、應用程式定義和基礎設施程式碼都存放在 Git 中
  2. 一切皆程式碼 - 不僅是應用程式，連基礎設施和設定都以程式碼形式表達
  3. 透過 Git 工作流程執行操作 - 變更審核、佈署和回復都透過熟悉的 Git 操作完成

GitOps 工作小組已經定義了一套 GitOps 原則（目前為 1.0.0 版），可在 OpenGitOps 找到：

  • 宣告式 - 由 GitOps 管理的系統必須以宣告式方式表達其期望狀態
  • 版本化與不可變 - 期望狀態的儲存方式強制不可變性和版本控制，並保留完整版本歷史
  • 自動提取 - 軟體代理自動從來源提取期望狀態宣告
  • 持續調和 - 軟體代理持續觀察實際系統狀態，並嘗試應用期望狀態

在我設計大規模系統架構時，這些原則已經成為指導方針，特別是在處理多環境佈署和組態管理時。

GitOps 的價值：為何值得採用？

採用 GitOps 的價值遠超過簡單的技術實作。根據開發者熟悉的 Git 工作流程，GitOps 將應用程式開發的實踐擴充套件到佈署、應用程式生命週期管理和基礎設施設定等領域。

應用程式生命週期中的每一個變更都在 Git 儲存函式庫追蹤，可供稽核。這種方法對開發和維運團隊都有益處，它增強了快速追蹤和重現問題的能力，提高了整體安全性。一個關鍵點是減少不必要變更（漂移）的風險，並在它們進入生產環境之前糾正它們。

在我帶領的多個專案中，GitOps 的採用帶來了四個關鍵方面的顯著改進：

標準工作流程

使用應用程式開發團隊熟悉的工具和 Git 工作流程，降低了新流程的學習曲線。當引入新的開發者時，他們可以立即參與到佈署流程中，因為基本操作與程式碼貢獻相似。

增強安全性

事先審核變更，檢測設定漂移，採取行動。每一次變更都經過明確的審核過程，減少了人為錯誤的可能性。在一個特別敏感的金融系統專案中，這種審核機制幫助我們在佈署前發現了多個潛在的安全問題。

可見性和稽核

透過 Git 歷史記錄捕捉並追蹤對叢集的任何變更。在需要遵守嚴格合規要求的環境中，這種內建的稽核跟蹤變得尤為重要，大幅減少了手動檔案工作。

多叢集一致性

可靠與一致地設定多個環境和多個 Kubernetes 叢集及佈署。隨著環境數量的增加，手動管理變得不切實際，而 GitOps 提供了擴充套件管理能力的途徑。

Kubernetes CI/CD：GitOps 的實作路徑

持續整合（CI）和持續交付（CD）是透過在應用程式開發階段引入自動化來頻繁交付應用程式的方法。CI/CD 管道是 GitOps 最常見的使用案例之一。

在典型的 CI/CD 管道中，提交的程式碼透過 CI 流程進行檢查，而 CD 流程則檢查並應用安全性、基礎架構即程式碼或應用程式框架設定的任何其他邊界條件的要求。所有程式碼變更都被追蹤，使更新變得簡單，同時還提供了版本控制，以便在需要時進行回復。CD 是 GitOps 的領域，它透過以下方式工作：

CI/CD 在 GitOps 中的角色

在實際的 GitOps 實作中，CI 和 CD 扮演不同但互補的角色：

  • CI（持續整合） 專注於程式碼整合、測試和構建，確保應用程式碼的品質
  • CD（持續交付） 處理佈署過程，將構建好的應用程式交付到目標環境

當這兩個流程與 GitOps 結合時，我們可以建立一個完全自動化與可靠的佈署流程，從程式碼提交到生產環境佈署，每一步都有明確的審核點和回復機制。

GitOps 架構與工具選擇

在設計 GitOps 架構時，工具的選擇至關重要。雖然 GitOps 是一種與工具無關的方法論，但某些工具組合能更有效地實作其原則。

核心元件：構建 GitOps 流程的根本

一個完整的 GitOps 實作通常包含以下核心元件：

  1. **Git 儲存函式庫 - 儲存所有基礎設施和應用程式設定
  2. CI 系統 - 負責程式碼構建、測試和封裝（如 Jenkins、GitHub Actions、GitLab CI 等）
  3. CD 系統 - 負責將變更應用到目標環境（如 ArgoCD、Flux 等）
  4. Kubernetes 叢集 - 執行應用程式和 GitOps 控制器的平台

在這些元件中，GitOps 控制器（如 ArgoCD 或 Flux）扮演著關鍵角色。它們持續監控 Git 儲存函式庫標環境之間的差異，並自動調和這些差異。

儲存函式庫：組織你的 GitOps 程式碼

在實施 GitOps 時，儲存函式庫織方式直接影響管理效率和安全性。根據我的經驗，有幾種常見的儲存函式庫：

單一儲存函式庫

將所有應用程式碼和設定存放在同一個儲存函式庫這種方式簡單直接，適合小型專案或初始階段。

my-app-repo/
  ├── src/                  # 應用程式原始碼
  ├── kubernetes/           # Kubernetes 設定
  │   ├── base/             # 基礎設定
  │   └── overlays/         # 環境特定設定
  └── ci/                   # CI 設定

多儲存函式庫

將應用程式碼和設定分開存放，甚至可以進一步按環境或團隊進行分割。這種方式提供更精細的存取控制和更清晰的職責劃分。

# 應用程式碼儲存函式庫pp-src-repo/
  ├── src/                  # 應用程式原始碼
  └── ci/                   # CI 設定

# 設定儲存函式庫pp-config-repo/
  ├── base/                 # 基礎設定
  └── environments/         # 環境特定設定
      ├── dev/
      ├── staging/
      └── production/

在大型組織中，我通常推薦多儲存函式庫，因為它能更好地支援複雜的團隊結構和許可權需求。然而，這也增加了管理的複雜性，需要更成熟的流程和工具支援。

實際案例：GitOps 工作流程

為了更直觀地理解 GitOps 如何工作，讓我們看一個典型的工作流程：

  1. 開發者將程式碼變更推播到應用程式儲存函式庫. CI 系統檢測到變更，執行構建和測試，生成容器映像
  2. 開發者或 CI 系統更新設定儲存函式庫映像標籤
  3. GitOps 控制器檢測到設定變更，將新版本佈署到目標環境
  4. GitOps 控制器持續監控實際狀態與期望狀態之間的差異，自動調和

這個流程完全根據 Git 操作，不需要直接存取 Kubernetes 叢集。所有變更都經過版本控制，可以輕鬆回復或稽核。

GitOps 實作：從理論到實踐

將 GitOps 的理論轉化為實際可用的流程需要一系列具體步驟。下面我將分享一些在實際專案中驗證過的實作方法。

環境準備：開始 GitOps 之旅

在開始實施 GitOps 之前，需要準備以下環境：

  1. **Git 儲存函式庫 - 設定應用程式和設定儲存函式庫. Kubernetes 叢集 - 至少需要一個測試叢集
  2. CI/CD 工具 - 選擇並設定適合的 CI/CD 工具
  3. GitOps 控制器 - 安裝 ArgoCD 或 Flux 等控制器

對於 GitOps 控制器的選擇，我通常推薦 ArgoCD，因為它提供了強大的 UI 和豐富的功能，特別適合初學者。下面是一個使用 Helm 安裝 ArgoCD 的例子：

# 建立名稱空間
kubectl create namespace argocd

# 使用 Helm 安裝 ArgoCD
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --namespace argocd

這段程式碼執行兩個關鍵操作：首先建立一個名為 argocd 的 Kubernetes 名稱空間，這是安裝 ArgoCD 的隔離環境；然後使用 Helm（Kubernetes 的套件管理器）從官方儲存函式庫 ArgoCD。這種方法比手動應用 YAML 檔案更簡潔，並且能夠更輕鬆地管理 ArgoCD 的升級和設定。

組態管理：Kustomize 與 Helm 的選擇

在 GitOps 中，組態管理是一個核心問題。兩個最常用的工具是 Kustomize 和 Helm：

Kustomize 方法

Kustomize 採用無範本的方式管理 Kubernetes 設定，透過基礎與覆寫層的概念實作設定的復用和環境特定調整。

# base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml

# overlays/production/kustomization.yaml
bases:
- ../../base
patches:
- path: production-patch.yaml

Helm 方法

Helm 使用範本化方法，透過 圖表 和 values 檔案管理設定，適合複雜應用程式的封裝和分發。

# values.yaml (預設值)
replicaCount: 1
image:
  repository: nginx
  tag: latest

# production-values.yaml (生產環境特定值)
replicaCount: 3
resources:
  limits:
    cpu: 1000m
    memory: 1Gi

在實際專案中，我發現 Kustomize 和 Helm 各有優勢。Kustomize 更輕量與與 Kubernetes 原生集

Kubernetes 上的 GitOps 自動化佈署實戰

在現代軟體開發環境中，自動化佈署已經成為提高團隊效率的關鍵因素。而 GitOps 作為一種以開發者為中心的持續交付方法，結合 Kubernetes 的強大容器協調能力，能夠大幅簡化應用程式的佈署與管理流程。

持續整合與持續交付的核心價值

持續整合 (CI) 與持續交付 (CD) 已經成為現代軟體開發的標準實踐。在 Kubernetes 環境中，我們可以輕鬆實作叢集內的 CI/CD 管道。這個流程通常包含幾個關鍵步驟：

  1. CI 系統建立代表應用程式的容器映像
  2. 將映像儲存於容器映像登入檔
  3. 透過 Git 工作流程（如 Pull Request）變更 Kubernetes 設定檔案
  4. 啟動 CD 同步迴圈，將變更佈署到叢集

Kubernetes 作為容器協調平台，天生就適合實作這種自動化工作流程，讓開發團隊能夠專注於程式碼的開發而非複雜的佈署流程。

Kubernetes 上的 GitOps 應用佈署模型

GitOps 作為一種與平台無關的方法論，在 Kubernetes 上的應用佈署模型可以是叢集內或多叢集架構。外部 GitOps 工具可以僅將 Kubernetes 作為佈署應用的目標平台，同時，叢集內方法則在 Kubernetes 內部執行 GitOps 引擎，以便在一個或多個 Kubernetes 叢集中佈署應用並同步設定檔案。

GitOps 引擎負責 CI/CD 管道中的 CD 部分，並完成一個 GitOps 迴圈，該迴圈由四個主要動作組成：

  1. 佈署 - 從 Git 佈署設定檔案
  2. 監控 - 監控 Git 儲存函式庫集狀態
  3. 偵測偏差 - 檢測 Git 中描述的內容與叢集中存在的內容之間的任何變化
  4. 採取行動 - 執行反映 Git 上內容的操作（回復或三向差異比較）

在這個模型中，Git 是唯一的真相來源，任何變更都必須透過 Git 工作流程進行。

在我設計大型系統的經驗中，將 Git 作為唯一真相來源是確保系統一致性和可靠性的關鍵。若沒有這種方法，團隊常會面臨環境差異和手動佈署錯誤的挑戰。

Kubernetes 中的 GitOps 專案結構

在 Kubernetes 中，使用 GitOps 方法進行應用佈署通常需要至少兩個 Git 儲存函式庫個用於應用程式原始碼，另一個用於描述應用佈署的 Kubernetes 設定檔案（如 Deployment、Service 等）。

Kubernetes GitOps 迴圈通常包含以下元素：

  1. 應用程式原始碼儲存函式庫. 建立容器映像的 CI 管道
  2. 容器映像登入檔
  3. Kubernetes 設定檔案儲存函式庫. GitOps 引擎，將設定檔案同步到一個或多個叢集並檢測偏差

這種結構不僅提高了佈署的可靠性，還增強了系統的可觀察性和可追溯性，讓團隊能夠更容易地理解系統的變更歷史。

DevOps 與敏捷性

GitOps 是一種以開發者為中心的持續交付和基礎設施操作方法，透過 Git 實作自動化流程的開發者工作流程。正如 DevOps 是敏捷軟體開發的補充，GitOps 也是 DevOps 在基礎設施自動化和應用生命週期管理方面的補充。它本質上是一種用於自動化操作的開發者工作流程。

敏捷方法論中最關鍵的一個方面是減少前置時間，這抽象地描述為從識別需求到實作之間的經過時間。減少這個時間是基礎性的，需要 IT 組織在文化上進行轉變。看到應用程式上線為開發者提供了一個反饋迴圈，可以重新設計和改進他們的程式碼，使專案蓬勃發展。

類別似於 DevOps，GitOps 也需要在業務流程中進行文化上的採用。每項操作，如應用佈署或基礎設施變更，只能透過 Git 工作流程進行。有時，這意味著一種文化上的轉變。

Burr Sutter 的 “教大象跳舞（和飛翔！）” 演講清楚地說明瞭這一點。大象代表你的組織當前所處的位置。在傳統環境和由 GitOps 工具驅動的現代環境之間存在變革階段。有些組織有從頭開始的奢侈，但對於許多企業來說，挑戰在於教他們笨重的大象像優雅的芭蕾舞者一樣跳舞。

在我帶領的多個技術轉型專案中，最大的挑戰往往不是技術本身，而是組織文化的轉變。成功的 GitOps 匯入需要從高層長官到一線開發者的全面支援和參與。

實施 GitOps 的技術需求

要成功實施 GitOps 方法論，我們需要準備一些關鍵工具和環境。以下是開始使用 GitOps 和 Kubernetes 的基本需求：

容器登入檔的設定

容器登入檔是儲存和管理容器映像的中央儲存函式庫 CI/CD 管道中的重要元件。對於實驗和學習目的，Docker Hub (docker.io) 是一個不錯的選擇。

如果你還沒有 Docker Hub 帳戶，可以按照以下步驟註冊：

  1. 存取 Docker Hub 網站
  2. 填寫登入檔單，設定 Docker ID、電子郵件和密碼
  3. 點選「註冊」按鈕
  4. 確認帳戶後，你就可以使用你的 Docker ID 發布容器了

除了 Docker Hub，Quay.io 也是一個流行的容器登入檔服務。它可以在雲端使用（類別似 docker.io）或在本地安裝。

在大型企業環境中，我通常建議使用私有容器登入檔，如 Harbor 或 Nexus，以增強安全性和控制性。但對於初學者和小型團隊，公共服務如 Docker Hub 已經足夠。

Git 儲存函式庫的設定

Git 服務是實施 GitOps 方法論的核心需求。GitHub 是最常用的 Git 服務之一，可用於建立和複製 Git 儲存函式庫 如果你還沒有 GitHub 帳戶，可以按照以下步驟註冊：

  1. 存取 GitHub 網站

  2. 點選「註冊 GitHub」按鈕並按照說明操作

  3. 確認帳戶後，你就可以開始建立或複製 Git 儲存函式庫 要複製範例程式碼函式庫可以：

  4. 點選儲存函式庫上的「Fork」按鈕

  5. 在「Owner」部分選擇你的帳戶（如果尚未選擇）

  6. 點選「Create fork」按鈕

除了 GitHub，GitLab 也是另一個流行的 Git 服務。它可以在雲端使用或在本地安裝。

從我的實踐經驗來看，選擇 Git 服務時應考慮團隊的工作習慣、安全需求和整合需求。對於需要嚴格合規的企業，自託管的 GitLab 可能更合適，而對於開放原始碼專案和小型團隊，GitHub 通常是最佳選擇。

建立本地 Kubernetes 叢集

要實踐 GitOps 方法論，你需要一個 Kubernetes 叢集。對於本地開發和學習，Minikube 是一個理想的選擇，它可以在本地機器上啟動一個 Kubernetes 叢集。

Minikube 使用容器/虛擬化技術（如 Docker、Podman、Hyperkit、Hyper-V、KVM 或 VirtualBox）來啟動一個安裝了 Kubernetes 叢集的 Linux 機器。

為了簡單起見，我們將使用 VirtualBox 作為虛擬化系統，這是一個在大多數平台上都能正常工作的選擇。

如果你尚未安裝 VirtualBox，可以存取其首頁並點選「下載」連結。

注意：對於 macOS 使用者，以下說明已在搭載 macOS Monterey 和 VirtualBox 6.1 的 Mac AMD64 上測試過。在撰寫本文時，使用 ARM 版本或 macOS Ventura 時存在一些不相容問題。

在實際生產環境中，我通常推薦使用託管 Kubernetes 服務，如 AWS EKS、Google GKE 或 Azure AKS，因為它們提供了更好的可靠性和可擴充套件性。但對於學習和開發目的，Minikube 或 Kind 是絕佳的選擇。

GitOps 與傳統佈署方法的對比

在傳統的佈署流程中，開發者通常需要手動執行多個步驟來佈署應用：建立環境、設定伺服器、佈署應用等。這種方法容易出錯，與難以追蹤變更歷史。

相比之下，GitOps 提供了一種更加自動化和可追溯的方法：

  1. 單一真相來源：所有設定都儲存在 Git 中，提供完整的變更歷史和稽核跟蹤
  2. 自動化同步：系統自動將 Git 中的設定同步到叢集中，減少人為錯誤
  3. 偏差檢測：自動檢測並糾正叢集中與 Git 定義不符的設定
  4. 回復能力：透過簡單的 Git 操作即可回復到之前的狀態

我曾參與一個專案，團隊從手動佈署轉向 GitOps 模型，佈署頻率從每週一次增加到每天多次，同時佈署失敗率降低了 80%。這種改進直接轉化為更快的產品迭代和更高的客戶滿意度。

GitOps 的優勢不僅限於技術層面，它還能促進開發和維運團隊之間的協作，打破傳統的隔閡，實作真正的 DevOps 文化。

實踐中的 GitOps 工具選擇

在實施 GitOps 時，選擇合適的工具非常重要。目前市場上有多種 GitOps 工具，包括：

  1. Flux CD：Kubernetes 原生的 GitOps 工具，支援多租戶和多叢集佈署
  2. Argo CD：提供強大的 UI 和多叢集管理能力
  3. Jenkins X：專注於雲原生 CI/CD 的綜合解決方案
  4. Spinnaker：提供複雜佈署策略的企業級持續交付平台

每種工具都有其優缺點，選擇應根據團隊需求和技術堆積積疊。在我的實踐中，對於大多數團隊來說，Flux CD 和 Argo CD 是最佳的起點，它們具有較低的學習曲線和強大的社群支援。

我曾在一個金融科技專案中使用 Argo CD 實作了一套完整的 GitOps 流程，該系統能夠自動將設定變更佈署到多個環境中，大幅提高了佈署效率和系統穩定性。

建立有效的 GitOps 工作流程

成功的 GitOps 實施需要明確定義的工作流程。以下是一個基本的 GitOps 工作流程範例：

  1. 開發階段：

    • 開發者編寫程式碼並提交到應用程式原始碼儲存函式庫 - CI 系統自動構建、測試並生成容器映像
    • 容器映像被推播到容器登入檔

  2. 設定階段：

在本機快速佈署 Kubernetes 開發環境

建立一個本地 Kubernetes 環境對開發者來說至關重要，它讓我們能夠在不需連線到雲端的情況下測試和開發 Kubernetes 應用。在這篇文章中，玄貓將帶你一步建立本地 Kubernetes 開發環境，並探討容器技術的實作方式。

Minikube：本地 Kubernetes 的最佳選擇

安裝完 VirtualBox（本文使用 6.1.x 版本）後，下一步是設定 Minikube 來佈署本地 Kubernetes 叢集。Minikube 是一個輕量級的 Kubernetes 實作，專為開發和測試環境而設計。

安裝 Minikube 的步驟

  1. 前往 Minikube 的 GitHub 發布頁面，展開 Assets 區塊
  2. 下載與你係統相符的檔案（例如 AMD Mac 使用者應選擇 minikube-darwin-amd64）
  3. 解壓縮檔案後，將其重新命名為 minikube 並放置在系統環境變數 PATH 可存取的目錄中（如 Linux/macOS 的 /usr/local/bin）

啟動本地 Kubernetes 叢集

安裝好 VirtualBox 和 Minikube 後，我們可以在本機上啟動 Kubernetes 叢集。以下命令會安裝 Kubernetes 1.23.0 版本，並分配 8GB 記憶體：

minikube start --kubernetes-version='v1.23.0' \
--driver='virtualbox' --memory=8196 -p gitops

這個命令做了三件關鍵的事情：

  • --kubernetes-version='v1.23.0' 指定了要安裝的 Kubernetes 版本
  • --driver='virtualbox' 設定使用 VirtualBox 作為虛擬化工具
  • --memory=8196 -p gitops 分配 8GB 記憶體並將叢集命名為 “gitops”，方便之後參考

執行後，你會看到類別似以下的輸出內容：

[gitops] Minikube v1.24.0 on Darwin 12.0.1
Using the virtualbox driver based on user configuration
Starting control plane node gitops in cluster gitops
Creating virtualbox VM (CPUs=2, Memory=8196MB, Disk=20000MB) ...
> kubeadm.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
> kubelet.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
> kubectl.sha256: 64 B / 64 B [--------------------------] 100.00% ? p/s 0s
> kubeadm: 43.11 MiB / 43.11 MiB [---------------] 100.00% 3.46 MiB p/s 13s
> kubectl: 44.42 MiB / 44.42 MiB [---------------] 100.00% 3.60 MiB p/s 13s
> kubelet: 118.73 MiB / 118.73 MiB [-------------] 100.00% 6.32 MiB p/s 19s
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
...
Done! kubectl is now configured to use "gitops" cluster and
"default" namespace by default

同步 kubectl 版本

系統可能會提示 kubectl 版本與 Kubernetes 叢集版本不一致。為了避免相容性問題，建議下載相對應的 kubectl 版本：

# 下載 kubectl 1.23.0 版本
curl -LO https://dl.k8s.io/release/v1.23.0/bin/darwin/amd64/kubectl

請依據你的系統架構調整下載路徑，例如 Windows 使用者應下載 windows/amd64/kubectl.exe。下載完成後，將檔案放置在 PATH 環境變數可以存取的目錄（如 /usr/local/bin）。

其他本地 Kubernetes 選項

雖然本文主要使用 Minikube，但還有其他方式可以在本機執行 Kubernetes：

  • kind (Kubernetes in Docker)：另一個熱門的本地 Kubernetes 解決方案
  • k3d：輕量級的 Kubernetes 分發版，根據 k3s
  • Docker Desktop 內建的 Kubernetes

這些選項各有優缺點，但 Minikube 對於初學者來說是最直觀與檔案最完善的選擇。

玄貓

玄貓

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