關於可靠資料來源

本文說明 Config Sync 可從中同步處理的不同類型可靠資料來源。

GitOps 工作流程的重要概念是「可靠來源」，也就是儲存設定檔的中央存放區。設定檔通常是定義 Kubernetes 資源的 YAML 或 JSON 檔案。一般來說，您可能會使用 kubectl 指令列工具手動套用 Kubernetes 物件，但 Config Sync 可以從單一可靠來源 (例如 Git 存放區) 自動套用這些資源。接著，Config Sync 會監控您指定的單一事實來源，並自動將所有變更套用至叢集。

Config Sync 可以從三種不同類型的來源同步設定檔：Git 存放區、開放容器倡議 (OCI) 映像檔和 Helm 資訊套件。本文將說明各個來源類型，以及 Config Sync 與這些來源的互動方式。閱讀這份文件有助於為工作流程和環境選擇最佳來源選項。

Git 存放區

Git 是廣為採用的版本管控和協作技術。使用 Git 時，您可以根據需求整理存放區，並視需要享有版本控管和分支的好處。由於 Git 是成熟且廣泛採用的技術，因此您可選擇各種供應商和工具。

使用 Git 存放區做為可靠來源設定 Config Sync 時，Config Sync 會使用調解器 Pod 中的 git-sync 容器，從 Git 存放區提取設定。您可以設定存放區網址、分支和修訂版本 (修訂或標記)，進一步控管從 Git 存放區中提取設定的位置。

RootSync 設定範例

以下範例顯示從 Git 存放區同步的 RootSync 資訊清單：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: unstructured
  git:
    repo: https://github.com/example/my-configs.git
    revision: main
    dir: cluster-configs
    auth: none # replace with your authentication method such as ssh or token
    period: 60s

這項設定會將 Config Sync 設為從 Git 存放區同步處理資訊清單。Config Sync 會監控 https://github.com/example/my-configs.git 存放區的 main 分支中的 cluster-configs 目錄，每 60 秒檢查一次更新，且不使用驗證。

使用案例範例：集中管理

假設您是平台管理員，想使用 Git 存放區，在機群中的所有叢集強制執行基準政策。在這種情況下，您可能會將標準 NetworkPolicies、RoleBindings 和 ResourceQuotas 儲存在名為 standard-configs 的中央 Git 存放區中。佈建新叢集時，Config Sync 會設定為從 standard-configs 存放區同步處理，確保所有叢集從一開始就符合機構標準。

OCI 映像檔

OCI 映像檔是封裝應用程式及其依附元件的標準格式。這個做法會將設定視為構件，類似於處理容器映像檔的方式。這項做法的優點包括不可變動性，以及大規模運作時的效能提升。透過 OCI，您可以使用容器映像檔基礎架構和工具 (例如 Artifact Registry) 管理映像檔，並使用 Workload Identity Federation for GKE 簡化驗證程序。

使用 OCI 做為設定來源時，通常需要另外一個程序，將設定檔建構為 OCI 映像檔，然後推送至 Artifact Registry 等登錄平台。相較於以檔案形式儲存在 Git 存放區中的設定，這種做法可能較難直接供人閱讀。

使用 OCI 映像檔做為可靠來源設定 Config Sync 時，Config Sync 會使用調解器 Pod 中的 oci-sync 容器，從登錄檔中提取含有設定的 OCI 映像檔。

RootSync 設定範例

以下範例顯示從 Artifact Registry 儲存的 OCI 映像檔同步的 RootSync 資訊清單：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: unstructured
  oci:
    image: us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0
    dir: .
    auth: k8sserviceaccount

這項設定會設定 Config Sync，從 OCI 映像檔進行同步。Config Sync 會使用 Kubernetes 服務帳戶進行驗證，並從 Artifact Registry 提取 us-central1-docker.pkg.dev/my-project/my-repo/my-config-image:v1.0.0 映像檔。

使用案例範例：整合 CI/CD 管道

假設您想將 OCI 映像檔建立作業整合至貴機構的 CI/CD 管道。合併設定檔變更時，您可以設定管道來執行驗證測試 (例如 nomos vet 指令)、將 YAML 檔案建構為 OCI 映像檔，並將映像檔推送到 Artifact Registry。Config Sync 接著會自動偵測新版映像檔，並套用至叢集，確保所有設定變更都經過驗證並推出新版本。

Helm 資訊套件

Helm 是 Kubernetes 的熱門套件管理工具，使用稱為「資訊套件」的封裝格式。Config Sync 可以擷取、轉譯及同步處理 Helm 資訊套件中定義的資源。

Helm 提供一致的方式，可包裝及重複使用 Kubernetes 應用程式。您可以使用範本或預先建構的 Helm 圖表，確保設定一致且可重複使用。

如果您不熟悉 Helm，範本和發布程序可能會為設定管理管道增加額外的複雜度。

使用 Helm 資訊套件設定 Config Sync 做為可靠來源時，Config Sync 會使用協調器 Pod 中的 helm-sync 容器，從 Helm 存放區 (例如 Artifact Registry) 或 Git 存放區提取資訊套件，然後轉譯資訊套件來產生 Kubernetes 資訊清單。或者，您也可以搭配使用 Config Sync 與 Kustomize 來轉譯 Helm 圖表。如要進一步瞭解這種做法，請參閱「搭配使用 Config Sync 與 Kustomize 和 Helm」。

RootSync 設定範例

以下範例顯示 RootSync 資訊清單，該資訊清單會從儲存在 Artifact Registry 中的 Helm 資訊圖表進行同步：

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  namespace: config-management-system
spec:
  sourceType: helm
  helm:
    repo: oci://us-central1-docker.pkg.dev/my-project/my-helm-repo
    chart: my-chart
    version: 1.2.0
    auth: gcpserviceaccount
    gcpServiceAccountEmail: my-service-account@my-project.iam.gserviceaccount.com
    releaseName: my-chart-release
    namespace: my-app-namespace # Namespace where the chart resources will be deployed

這項設定會將 Config Sync 設為從 OCI 存放區同步處理 Helm 資訊圖表。Config Sync 會從 oci://us-central1-docker.pkg.dev/my-project/my-helm-repo 存放區擷取 my-chart 圖表的 1.2.0 版本，並使用 my-service-account@my-project.iam.gserviceaccount.com 服務帳戶進行驗證。這會將圖表的資源部署到 my-chart-release 發布名稱下的 my-app-namespace 命名空間。

應用範例：部署第三方應用程式

假設您是應用程式團隊的成員，想將 Prometheus 部署至叢集。您可以設定 Config Sync，從預先建構的 Helm 圖表提取資料，部署 Prometheus。您不必手動執行 Helm 指令，只要在 Config Sync 的 RootSync 或 RepoSync 物件中定義資訊套件來源、版本和任何自訂 values 即可。Config Sync 接著會讓部署作業與指定的圖表版本和設定保持同步。

選擇來源類型

最佳來源類型取決於團隊現有的工具、工作流程和偏好設定。您可以參考下表，瞭解各來源類型的主要特徵，做出明智決策：

功能 Git 存放區 OCI 映像檔 Helm 資訊套件
適用情境 一般用途的設定管理；彈性；可讀性 不可變更的設定 (含版本資訊)；運用容器基礎架構 封裝及發布複雜應用程式
可變動性 可以變更 無法變更 可變動 (圖表版本不可變動，但值可以變更)
復原 還原提交或變更分支 部署先前的圖片代碼 復原至先前的圖表版本
工具 標準 Git 用戶端、持續整合/持續推送軟體更新管道 Docker 或 Podman、容器登錄檔 Helm CLI、Helm 存放區
效能 大型存放區的速度可能較慢 速度更快，尤其是在大規模作業時 從圖表存放區擷取時速度很快
驗證 彈性 (SSH、權杖)，設定可能較為複雜 透過 Workload Identity Federation for GKE 簡化程序 (例如使用 Artifact Registry) 透過 Workload Identity Federation for GKE 簡化程序 (例如使用 Artifact Registry)

您也可以在同一個叢集上，針對不同用途使用不同來源類型。舉例來說，叢集可能具有下列項目：

  • RootSync 從 Git 存放區同步處理，該存放區包含平台團隊管理的基本叢集資源和政策。
  • 特定命名空間中的 RepoSync 會從 Helm 圖表同步，以部署由應用程式團隊管理的 Redis 執行個體。
  • 另一個 RepoSync 位於不同命名空間，從 OCI 映像檔同步處理，其中包含一組由獨立 CI/CD 程序建構的應用程式專屬設定。

後續步驟