GitOps 解決方案深度解析：Argo CD、Flux 與 Terraform 的定位

本文整理了關於 Argo CD 和 Flux CD 的比較、Argo CD 的安裝計畫，以及 GitOps 理念在網路設備管理和與 Terraform 整合方面的應用。

一、Argo CD 與 Flux CD 比較

Argo CD 和 Flux 都是 Kubernetes 社群中優秀的 **GitOps Agent**，它們都實作了「拉取式 (Pull-Based)」部署模式。以下是它們的差異：

特性	Argo CD (CNCF 畢業專案)	Flux (CNCF 畢業專案)
設計理念/結構	Application Controller 集中管理：專注於應用程式級別的部署和狀態同步。	分散式工具集：由多個專注於不同功能的專門控制器組成（更模組化）。
部署模型	應用程式為中心 (App-centric)：每個部署定義為一個 Application 資源。	功能為中心 (Feature-centric)：使用 HelmRelease 或 Kustomization 資源來定義部署。
主要介面	優秀的 Web UI：提供功能豐富、視覺化強大的介面。	CLI 為主：主要透過 flux cli 進行管理。
多叢集支援	集中式管理：單一 Argo CD 實例可管理多個外部 K8s 叢集。	分散式管理：通常建議在每個目標叢集上安裝一個 Flux 實例。

選擇建議： Argo CD 更「操作友好」且「集中」；Flux 更「Kubernetes 原生」且「模組化」。

二、Argo CD 導入與測試計畫

以下為採用 Argo CD 的三階段安裝與驗證計畫：

階段一：準備與規劃 (Pre-Installation)

• **P1 - K8s 環境檢查：** 確認叢集版本和權限。
• **P2 - Git 儲存庫準備：** 建立配置 YAML 檔的 Git 儲存庫（如：git@github.com/org/k8s-manifests.git）。
• **P3 - 測試應用程式配置：** 在 Repo 中準備簡單的 YAML 檔案（如：k8s-manifests/guestbook/）。

階段二：安裝與核心配置

# 1. 安裝 Argo CD

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# 2. 取得初始密碼

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{'.data.password'}" | base64 -d; echo

# 3. 啟動 Port Forward 測試存取

kubectl port-forward svc/argocd-server -n argocd 8080:443

階段三：功能驗證與測試

測試項目	目的	預期結果
T1.3 手動同步	驗證部署功能	應用程式狀態變為 Synced 和 Healthy。
T2.2 手動漂移修復	驗證持續協調 (Self-Heal)	手動修改 K8s 資源後，Argo CD 自動偵測並將其修正回 Git 定義的狀態。
T2.3 版本回溯	驗證回溯機制	Git 回溯 Commit 後，Argo CD 自動將 K8s 狀態回溯到舊版本。

三、Argo CD 的部署位置

答案：Argo CD 是安裝在 Kubernetes (K8s) 叢集內部的。

它作為一個控制迴路在叢集內部運行，持續：

• 監控 Git 儲存庫的期望狀態 (Desired State)。
• 透過 K8s API 讀取叢集的實際狀態 (Live State)。
• 執行協調，確保兩者一致（GitOps 拉取式模式）。

四、Argo CD 的狀態偵測機制

答案：Argo CD 部署後，不會主動偵測現有 K8s 的所有 YAML。它只會根據您給它的配置去工作。

Argo CD 的工作流程是以「**應用程式定義**」為中心：

1. 您必須建立一個 Application 資源，明確指向一個 Git Repo/Path。
2. Argo CD 才會開始：讀取 Git (期望狀態) → **查詢 K8s API (實際狀態)** → **比較**並判斷是否需要同步。

所有未被 Argo CD 定義和管理的資源，將不會受到 GitOps 流程的影響。

五、k8s-manifests/guestbook 的意義

這是一個範例路徑結構，結合了兩個概念：

• k8s-manifests/： 業界常用的資料夾名稱，用於存放 **Kubernetes Manifests**（K8s 資源定義的 YAML 檔）。
• guestbook： 指一個特定的應用程式名稱（通常是 K8s 範例應用程式）。

在 Argo CD 中，這個路徑就是指定：「請將這個資料夾內的所有 YAML 檔案部署到目標叢集，並將這些資源歸類為 guestbook 應用程式。」

六、GitOps 理念與 Cisco 網路設備管理

答案：可以，但不能直接使用 Argo CD。

GitOps 的理念（以 Git 作為唯一事實來源、宣告式、自動協調）完全適用於網路設備，這被稱為 **NetDevOps**。

由於 Cisco 設備不使用 K8s YAML，您需要將 GitOps 理念與專門的 **網路自動化工具** 結合，作為 Argo CD 的替代執行器：

• 期望狀態： Git Repo 中的 **YAML/Jinja2 模版**。
• 執行代理： **Ansible** 或 **Terraform**。它們負責讀取模版、生成 Cisco CLI 命令，並透過 SSH/API **推送**到設備。
• 協調： Ansible 的冪等性 (Idempotency) 機制，確保只應用必要的更改。

七、Terraform 與 Argo CD 的比較與協作

兩者是互補而非競爭的關係，主要區別在於管理的**範圍**和**機制**：

關鍵差異

特性	Terraform	Argo CD
核心用途	**基礎設施的供應 (Provisioning)**	**應用程式的持續交付 (CD)**
管理範圍	VPC、RDS、S3、**K8s 叢集本身**	**K8s 內部的** Deployment、Service、ConfigMap 等
機制	CLI 驅動 (Push-Based)	控制器驅動 (Pull-Based)

最佳協作模式

在 End-to-End GitOps 中，兩者形成清晰的階層：

1. Terraform (IaC/Provisioning)： 負責建立 K8s 叢集、資料庫等底層**基礎設施 (Infrastructure)**，作為部署的「畫布」。
2. Argo CD (GitOps/Delivery)： 安裝在 K8s 叢集內，負責持續管理和部署**應用程式 (Application)** 資源到這個畫布上。

aa

三大物料清單：SBOM、CBOM 與 AIBOM 及其組成與用途

---

1. 人工智慧物料清單 (AIBOM)

定義： AI Bill of Materials 用於描述人工智慧生態系統中所有資產的完整清單，涵蓋模型、資料集、訓練流程與治理資訊。

區塊	內容
組成	模型規格： 模型版本、類型、演算法等信息。 訓練資料來源： 資料集來源、許可證、預處理。 模型卡： 預期用途、限制、道德問題、效能衡量和風險緩解措施。 授權資訊： 模型和資料所遵循的相關許可協議。
用途	提供模型大小、訓練資料來源、訓練時間、授權類型、治理指標的透明度與法律聲明等。 評估AI系統面對偏差、風險與法規的韌性。 實現對AI資產與政策的主動治理。 與EU AI Act / NIST AI等未來法規標準對齊。

---

2. 軟體物料清單 (SBOM)

定義： SBOM 代表 "Software Bill of Materials"，為軟體物料清單。

• 這是一種運用於追蹤和記錄軟體組件及其相關資訊的標準化格式。這些資訊包括軟體的版本、依賴關係、開源軟體組件、授權信息等。
• 現代運維和軟體很少是從頭開始編寫的。典型的應用程式由預先建置的開源或第三方商業元件組成。
• 隨著軟體供應鏈攻擊的威脅，這使得 SBOM 成為確保供應鏈安全 (Supply Chain Security) 的關鍵。

---

3. 加密物料清單 (CBOM)

定義： Cryptography Bill of Materials 是 SBOM 的擴展，它更詳細地描述了軟體中的加密元件及其相依性。CBOM的元件包括整個細節中軟體產品使用的加密演算法和函式庫。

區塊	內容
組成	加密演算法 金鑰屬性 憑證與證書 通訊與協定 到期日期及其狀態
用途	提供演算法、金鑰和憑證等加密資產的透明度。 評估針對乘用演算法和量子威脅的彈性。 實現對加密資產和政策的主動管理。 顯示不同加密資產和使用它們的系統之間的依賴關係。 達到與量子密碼標準一致。

中距離航空戦闘戦術部隊(KAMIA HEAVY INDUSTRY)

Kubernetes Configuration Recovery: Retrieving and Cleaning Deployed YAML

This document outlines the technical facts regarding configuration storage in Kubernetes and provides a reliable method for technical leads to retrieve the current, deployed resource configurations, which closely resemble the original YAML files.

1. Kubernetes Does Not Store the Original YAML File Path

When a user executes kubectl apply -f [yaml file], Kubernetes does not record the actual location of the original file. Instead, it only stores the desired state of the resources, as defined in the YAML, within its internal database, etcd.

2. Obtaining the Resource's Current Configuration from the Cluster

While the original YAML file itself cannot be located within the cluster, the cluster holds the complete current configuration of the deployed resource, which is highly similar to the source file.

Steps to Retrieve the Deployed Resource Configuration:

A. Identify the Resource Name, Type, and Namespace

You must first determine the resource's Kind, Name, and its Namespace (if applicable).

Resource Type	Command to List Resources	Notes
StorageClass (SC)	kubectl get sc	Typically cluster-scoped (no specific Namespace).
PersistentVolume (PV)	kubectl get pv	Cluster-scoped.
PersistentVolumeClaim (PVC)	kubectl get pvc --all-namespaces	Use -n <namespace> if the Namespace is known. e.g., for Elasticsearch.
Workload (e.g., Elasticsearch)	kubectl get statefulset --all-namespaces kubectl get deployment --all-namespaces	Identify the name (e.g., elasticsearch-master) and its Namespace. (Workloads are usually StatefulSet or Deployment).

B. Export the Resource's YAML Configuration

Once the resource is identified, use kubectl get with the -o yaml flag to export its current configuration.

Resource Type	Example Command
StorageClass	kubectl get sc <sc-name> -o yaml > storageclass-<sc-name>.yaml (e.g., kubectl get sc netapp-trident-sc -o yaml > netapp-trident-sc.yaml)
PersistentVolume (PV)	kubectl get pv <pv-name> -o yaml > pv-<pv-name>.yaml
PersistentVolumeClaim (PVC)	kubectl get pvc <pvc-name> -n <namespace> -o yaml > pvc-<pvc-name>.yaml
Elasticsearch StatefulSet/Deployment	# Assuming StatefulSet kubectl get statefulset <es-statefulset-name> -n <namespace> -o yaml > es-statefulset.yaml

🚨 Critical Note: Cleaning the Exported YAML

The exported YAML files will contain numerous fields automatically added by Kubernetes during runtime. These include: status, creationTimestamp, resourceVersion, uid, and lengthy metadata.annotations (especially kubectl.kubernetes.io/last-applied-configuration).

If a "clean" YAML file is required for subsequent kubectl apply commands or for version control, these system-generated fields must be manually removed or stripped.

• Priority Fields to Delete (Top-Level): status, metadata.creationTimestamp, metadata.resourceVersion, metadata.uid, metadata.selfLink (if present), and often metadata.generation.
• For Deployment/StatefulSet, review and clean any unnecessary auto-generated annotations and labels within spec.template.metadata.

C. Using the last-applied-configuration Annotation (If Applicable)

If the initial kubectl apply command was executed without the --save-config=false flag, Kubernetes stores a copy of the successfully applied YAML content in a metadata.annotations field called kubectl.kubernetes.io/last-applied-configuration.

This configuration is typically closer to the original YAML (e.g., it lacks the status block) than the full kubectl get -o yaml output.

You can retrieve this clean configuration using tools like jq or yq:

# Retrieve for a StatefulSet, outputting JSON and piping to jq
kubectl get statefulset <es-statefulset-name> -n <namespace> -o jsonpath='{.metadata.annotations."kubectl\.kubernetes\.io/last-applied-configuration"}' | jq . > clean-es-statefulset.json

# Alternative: Retrieve for a StatefulSet, using yq to output clean YAML (requires yq)
# kubectl get statefulset <es-statefulset-name> -n <namespace> -o yaml | yq '.metadata.annotations."kubectl\.kubernetes\.io/last-applied-configuration"' -r | yq -P > clean-es-statefulset.yaml

Summary for Technical Management

The most robust method to reconstruct the configuration is:

1. Use kubectl get <resource_type> -n <namespace> -o yaml to export the resource.
2. Manually clean or use scripting tools to strip the exported YAML of status and system-generated metadata, rendering it a re-applyable configuration file.

Concurrently, the new administration must establish a mandatory process to store all future configuration files in a version control system (e.g., Git) and document the file location corresponding to each deployed resource, preventing recurrence of this "missing file" issue.