簡單來說，它就像是一個翻譯器，把 Google Cloud 的資源轉換成 Kubernetes 可以理解的格式。

在實際使用中，Config Connector 扮演著橋樑的角色。

當我們想要在Google Cloud上建立新的服務，比如說建立一個 Cloud Storage Bucket 或是設定一個負載平衡器，我們不需要去 GCP 的控制台點點按按，而是可以直接用 Kubernetes 的設定檔來描述我們想要的資源。

Config Connector會自動幫我們在Google Cloud上建立這些資源，並且持續確保它們的狀態符合我們的期望。

這個工具的強大之處在於它的自動化能力。

比如說，如果有人不小心在 GCP Console 上手動修改了某些設定，Config Connector 會自動發現這個變化，並把它改回到我們在設定文件中定義的狀態。這樣可以確保我們的環境始終保持一致性。

在安全性方面，Config Connector 完全整合了 Kubernetes 的權限管理系統。代表我們可以精確控制誰能夠管理哪些 GCP 的資源，而且所有的操作都有完整的稽核記錄。

使用 Config Connector 的時候，我們需要先在 Kubernetes Cluster 中安裝它，然後配置適當的權限。之後，我們就可以用 YAML 格式的設定檔來描述我們想要的Google Cloud資源。

這些配置文件可以存放在Git倉庫中，配合 CI/CD 流程實現自動化部署。

在實際工作中，Config Connector 特別適合需要經常建立和管理GCP 資源的團隊。

比如說開發團隊需要經常建立測試環境，或者維運團隊需要統一管理多個專案的資源，使用 Config Connector 都能大大提高工作效率。

當遇到問題時，我們可以通過查看 Config Connector 的 Log 來進行故障排除。它會清楚地告訴我們哪裡出了問題，比如權限不足或者資源設定有誤。這讓問題診斷和修復變得更加直接和簡單。

總的來說，Config Connector 是一個非常實用的工具，它讓 GCP 資源的管理變得更加自動化和規範化，特別適合已經在使用Kubernetes的團隊。它不僅簡化了日常運維工作，還能確保環境的一致性和可靠性。

要使用 Config Connector，先準備以下 YAML 檔案：

apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: cluster
  googleServiceAccount: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

當這個 YAML 被應用 (Apply) 到GKE後，它會在你的 Kubernetes Cluster 中設置 Config Connector，並且設定使用指定的 Google Service Account 來操作 GCP 資源。

例如我們想要建立一個 Bucket，可以準備以下的 YAML 檔：

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: US-CENTRAL1
  uniformBucketLevelAccess: true

當這個 YAML 被套用 Apply 到 GKE 後，流程是這樣的：

1. GKE 中的 Config Connector 會讀取這個YAML檔
2. Config Connector 會解析這個檔案，了解到你想要創建一個Cloud Storage bucket
3. Config Connector 會使用它被配置的 Google Service Account的權限
4. 通過 Google Cloud API 去創建實際的 Storage bucket
5. 持續監控這個 bucket 的狀態，確保它符合 YAML 中描述的配置

如果之後有人直接在 GCP 控制台修改了這個 bucket 的設定，Config Connector 會自動發現並改回 YAML 檔中定義的狀態。

這就是為什麼它特別適合用在 GitOps 的工作流程中，因為它能確保實際的 GCP 資源狀態始終與程式碼倉庫中的定義保持一致。

The post [GKE 教學] Config Connector 是什麼東東？如何使用？ first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.

GitOps方法論是什麼？

GitOps是一種現代的軟體部署和運維方法論，核心理念是使用Git作為單一事實來源(Single Source of Truth)，所有系統設定和基礎設施都以程式碼形式存儲在Git倉庫中，以宣告式語法來描述整個系統狀態。

主要特點

1. 自動化同步：系統會自動將Git倉庫中的期望狀態與實際運行環境同步
2. 版本控制：所有更改都有完整的版本歷史記錄
3. 可稽核性：每個變更都可以追踪誰在什麼時候做了什麼修改
4. 回滾能力：可以輕鬆回退到任何之前的版本

優點如下：

1. 提高部署一致性和可靠性
2. 減少人為錯誤
3. 更容易進行協作和審查
4. 簡化復原流程

常用工具包含：Flux、ArgoCD、Jenkins X、Config Connector (Google Cloud 專屬)。

GitOps特別適合管理Kubernetes環境，因為Kubernetes本身就是基於聲明式配置的系統。這也是為什麼在GKE環境中，Config Connector配合GitOps方法論會是一個理想的選擇。

撇開 GKE，Flux 和 ArgoCD 就是兩個業界常用的 GitOps 工具

Flux:

• 像是一個勤奮的管家,會定期檢查 Git 程式碼庫有沒有更新
• 如果發現更新了,就會自動把新的設定套用到系統
• 特別適合單一團隊使用,設定相對簡單

ArgoCD:

• 功能比較豐富,有圖形化介面可以看系統狀態
• 可以管理多個專案和團隊
• 提供更多進階功能,例如可以設定部署的順序和條件

這兩個工具的主要差別在於:

• Flux 比較輕量化,適合小型專案
• ArgoCD 功能比較完整,適合大型組織使用
• Flux 通常整合在系統內,ArgoCD 則是獨立運作的服務

你要選擇哪一個,主要看:

1. 團隊規模大小
2. 是否需要圖形化介面
3. 需要的進階功能有哪些
4. 維護的難易程度

GitOps的工作流程是什麼？

1. 開發階段

• 開發人員在本地開發功能或修改
• 將所有設定檔（包括應用代碼、基礎設施配置）存儲在 Git 倉庫 (Repository)，例如 Github。
• 創建 Pull Request（PR）提交更改

2. 審核階段

• 其他團隊成員審查代碼變更
• 自動化測試運行檢查
• CI（持續整合）流程驗證更改
• 審核通過後合併到主分支 (Main Branch)

3. 同步階段

• GitOps 操作器（如 ArgoCD 或 Flux）持續監控 Git 倉庫
• 自動檢測到主分支的新變更
• 比較目標環境與 Git 中定義的期望狀態

4. 部署階段

• 操作器自動將變更同步到目標環境
• 執行必要的部署和配置更新
• 確保實際狀態與 Git 中定義的狀態一致

5. 監控與修正

• 持續監控部署狀態
• 如果檢測到偏差，自動進行修正
• 將實際狀態調整回 Git 中定義的期望狀態

6. 回滾機制

• 如果發現問題，可以快速回滾
• 只需將 Git 倉庫回退到之前的穩定版本
• 操作器會自動將環境同步到回滾後的狀態

整個流程的核心是：

• 所有更改都通過 Git 進行
• 自動化工具負責同步和部署
• 持續確保系統狀態與 Git 定義保持一致

這種工作流程特別適合：

• Kubernetes 環境管理
• 微服務架構
• 大規模分布式系統
• 需要嚴格變更控制的環境

The post [GKE 教學] GitOps 方法論是什麼東東？GitOps的工作流程是什麼？ first appeared on 東東 GCP 教學 - GCP 實戰講師 - 雲上星辰有限公司.