在我看來，Kubernetes 的優勢主要在于它的聲明式性質與控制循環相結合，并通過這些控制循環持續監控集群的活動狀態，確保它與 etcd[2] 中存儲的期望狀態保持一致。這種方式非常強大，但同時其數據庫也被限制為etcd(etcd僅提供了有限的可觀察性)，并影響到了集群變更時的責任性和審計性。另外一個缺點是將etcd和代碼倉庫作為兩個SOT(sources of truth)，有可能會導致配置漂移，造成管理上的困難。

開發者使用代碼倉庫這種安全且可追溯的方式來保存代碼，并開發出了 Workflows[3] 這種方式來高效地管理中央倉庫，不同的團隊可以并行工作，且不會產生過多的沖突，同時保證對所有變更進行審核，并支持追溯和回滾。

如果我們能夠從圍繞 Git 倉庫創建的流程中獲得這些優勢，并將它們擴展到基礎設施或是 kubernetes 中，那不是很好嗎？

首先聊一下什么是 GitOps，以及如何將其應用到 Kubernetes，然后再看一下在 kubernetes 中實現的 GitOps 聲明式工具，最后回顧一些 GitOps 友好的工具，即它們是以代碼的形式實現和聲明的工具。

什么是 GitOps？

GitOps 的目的是將 etcd 的這種聲明式特性擴展到(保存代碼的) Git 倉庫，并作為 SSOT(single source of truth)。通過這種方式，我們可以利用 Git 帶來的優勢，如代碼監視、歷史變更、快速回滾、可追溯性等等。

   GitOps 的核心觀點是使用包含當前期望的(生產環境基礎設施的)聲明式描述的 GIt 倉庫，并通過自動化流程來確保生產環境與倉庫中的期望狀態保持一致。如果你想要部署一個新的應用或更新一個現有的應用，只需要更新相應的倉庫即可(自動化流程會處理后續的事情)。這就像在生產中使用巡航控制來管理應用程序一樣。

GitOps 不僅限于 Kubernetes，實際上它還可以通過將 基礎設施作為代碼[4] 保存到GIt倉庫中來將應用代碼延伸到基礎設施中，這通常是通過 Terraform[5] 這樣的工具進行普及的。聲明式基礎設施既代碼[6] 在實現GitOps中扮演著一個重要的作用，但不僅限于此。GitOps圍繞Git構建了整個生態系統和工具，并將其應用到基礎設施，僅僅在Git中使用Terraform并不能保證基礎設施的狀態能夠與生產環境保持一致，還需要持續運行Terraform命令(trrraform apply)來監控實時版本的變化，以及在流水線中實現手動審批等功能。

GitOps 的理念是持續監控集群的狀態并與 Git 倉庫進行對比，在配置不一致時立即采取相應的動作，防止發生配置漂移。除此之外，你還可以獲得 Git 帶來的好處，如通過代碼監視進行手動審批。

對于我來說，這些理念是革命性的，如正確使用，可以讓組織更多關注功能特性，并減少自動化腳本的編寫工作。這種觀念可以延申到軟件開發的其他領域，如可以將文檔存儲在代碼中，以此來跟蹤歷史變更，并保證文檔的及時更新；或使用 ADRs[7] 來跟蹤架構決策。

Kubernetes 中的 Gitops

Kubernetes 從一開始就有控制循環的想法，這意味著 Kunernetes 總是會監控集群的狀態來保證達到期望狀態。例如，使運行的副本數與期望的副本數匹配。將 GitOps 的理念延申到應用，這樣就可以將服務定義為代碼，例如，通過定義 Helm[8] Charts，并使用一個通過K8s提供的功能來監控App狀態的工具來調整對應的集群狀態，即，更新了代碼倉庫，或更新了生產集群的 helm chart。這才是真正的持續部署。其中的核心原則是，應用部署和生命周期管理應該是自動化的、可審計并易于理解的。

每個環境都應該有一個代碼倉庫，用于定義給定集群的期望狀態。然后 Kubernetes Operators 會持續監控特定分支(通常是master分支)，并在探測到 Git 發生變更后，將此次變更傳遞到集群，并更新etcd中的狀態。在這種方式中，etcd只作為一個數據庫，且不是唯一的SOT。可以在包含聲明式Kubernetes基礎設施的Git倉庫中定義應用的Helm chart。此外，還可以鏈接存儲庫，這樣一個存儲庫可以監視另一個存儲庫，以此類推。Kubernetes GitOps工具可以監控其他倉庫(如Helm Chart倉庫)的狀態，這樣你的集群環境倉庫中無需包含Helm Chart，只需要一條到Helm 倉庫的連接，并使用該鏈接監控其變更即可，這樣當你發布的一個新的chart時，后續會將該chart自動部署到集群。通過這種方式自動執行端到端的聲明式CI/CD流水線。

聲明式 GitOps 工具

如果考慮 Kubernetes 上的 GitOps，就需要討論那些在 Kubernetes 上實現了 GitOps 原則的工具(負責監控 Git 的狀態，并將其同步到集群)。

ArgoCD

在我看來，Kubernetes 上最好的 GitOps 工具就是 ArgoCD[9] 。ArgoCD 是Argo生態系統的一部分，該生態系統包含了很多很好的工具，后續會進行討論。

使用 ArgoCD，可以在代碼庫中定義每個環境的所有配置。Argo CD 會在特定的目標環境中自動部署所需的應用狀態。

Argo CD 作為一個 kubernetes controller，持續監控運行的應用，并將當前的活動狀態與所需的目標狀態(如 Git repo 中描述的狀態)進行比較。Argo CD 會報告并呈現這種差異，并通過自動或手動的方式將實時狀態同步到期望的目標狀態。

**ArgoCD **有一個非常棒的 UI，支持 SSO，它是安全、可擴展且易于使用的。

Flux

Flux[10] 是除 ArgoCD 外另一個非常有名項目。最近的版本包含很多改進，功能上非常接近 ArgoCD，Flux 是 CNCF 孵化項目。

GitOps 工具

在本節中，回顧一下我比較喜歡的 GitOps 友好的(即基于 CRD 的)工具。

helm

Helm 無需多言，它是 Kubernetes 上最著名的包管理器，當然，你應該像在編程語言中使用包一樣，在K8s中使用包管理器。Helm 允許使用 Charts 的方式打包應用，將復雜的應用抽象為可重用的簡單組件，便于定義、安裝和升級。

它還提供了一個強大的模板引擎，Helm 已經很成熟，它包含很多預定義的charts，支持性強，使用方便。

Helm 可以很好地集成到 ArgoCD 或 Flux，后者可以監控 Helm 倉庫的變化，并在發布新的 charts 時進行部署。實現思路是將 ArgoCD 或 Flux 指向 Helm 倉庫，并指定一個特定的版本或通配版本。如果使用通配版本，一旦發布了新的版本，就會進行自動部署。你可以使用主版本或次版本的方式進行命名。我通常傾向于將應用打包到 charts 中，將其作為 CI/CD 的一部分進行構建，并讓 ArgoCD 監控特定的倉庫。這種關注點分離允許開發者在獨立于環境的倉庫中管理應用，并讓 ArgoCD 選擇在哪個環境中部署哪個 charts。你可以使用多個 Helm 倉庫并根據不同的環境推送變更。例如，在合并一個 PR 后，可以執行一次 "bronce" 構建，該構建會將 Helm chart 發布到一個名為 "bronce" 的倉庫中。dev 環境的 ArgoCD 倉庫指向 "bronce" 倉庫，并在可用時部署新版本。staging 環境的 ArgoCD 倉庫會指向名為 "silver" 倉庫，而 production 環境則指向名為 "gold" 的倉庫。當需要向 staging 或 production 環境推送某些內容時，CI/CD 只需將該 chart 發布到下一個倉庫即可。

ArgoCD 可以覆蓋任何環境的特定 Helm 值。

Kustomize[11] 是一個新的 helm 的替代品，它不需要模板引擎，而使用了一個 overlay 引擎，之上有基本定義和 overlays 。

Argo Workflows 和 Argo Events

在 Kubernetes 中，你可能需要運行批量任務或復雜的工作流，作為數據處理流程、異步處理或 CI/CD 的一部分。除此之外，你可能需要運行驅動微服務來響應特定的事件，如文件上傳或發送消息到某個隊列。為了實現這些功能，可以使用 Argo Workflows[12] 和 Argo Events[13] 。

雖然它們是獨立的項目，但趨向于部署到一起。

Argo Workflows 是一個類似 Apache Airflow[14] 的編排引擎，但天然適用于Kubernetes。它使用CRDs來定義復雜的workflows(使用YAML表示的steps或 DAGs[15] 來表達工作流)。它還有個不錯的UI，支持重試機制，定時任務，輸入輸出跟蹤等。你可以使用它來編排數據處理流水線和批量任務等。

有時你可能希望將流水線與異步服務(如 Kafka、隊列、webhook 或底層存儲服務)集成到一起。例如，你可能希望對上傳文件到S3這樣的事件做出響應，此時你可以使用 Argo Events。

上述兩種工具為需要 CI/CD 流水線提供了簡單且強大的解決方案，可以在 Kubernetes 上運行 CI/CD 流水線。

由于所有 workflows 定義都可以打包到 Helm charts 中，因此 Argo Workflows 可以很好地集成到 ArgoCD。

對于 ML 流水線，可以使用 Kubeflow[16] 實現相同的目的。

對于 CI/CD 流水線，可以使用 Tekton[17] 。

Istio

Istio[18] 是市面上最著名的 服務網格[19] ，它是開源的，且非常流行。由于服務網格內容龐大，因此這里不會討論細節，但如果你在構建微服務，有可能你會需要一個服務網格來管理通信、可觀測性、錯誤處理、安全以及(作為微服務架構一部分的)其他交叉方面。使用服務網格可以避免因為重復的邏輯而污染微服務的代碼。

簡而言之，一個服務網格就是一個特定的基礎設施層，你可以在上面添加應用，它允許透明地添加可觀測性、流量管理和安全，而無需自己實現這些功能。

Istio 使用 CRDs 來實現其所有功能，因此可以將virtual services、gateways、policies等作為代碼打包在Helm charts中，并使用ArgoCD或Flux來讓Istio變得GitOps友好(雖然不是那么強大)。

還可以使用 Linkerd[20] 或 Consul[21] 替代Istio。

Argo Rollouts

上面已經提到過，你可以使用 Kubernetes 來運行使用Argo Workflows 或類似工具的 CI/CD 流水線。下一步邏輯上是執行持續部署，但在現實場景中，由于其風險較高，因此大部分公司只做了持續交付，這意味著他們可以實現自動化，但仍然采用手動方式進行審批和校驗，這類手動步驟的根因是這些團隊無法完全信任其自動化。

那么該如何構建這種信任度來避免使用腳本，進而實現從代碼到生產的完全自動化。答案是：可觀測性。你需要關注資源的指標，并通過采集所有的數據來精確地傳達應用的狀態，即使用一組指標來構建信任度。如果 Prometheus 中包含所有的數據，那么就可以實現自動化部署，因為此時你可以根據指標來實現滾動更新應用。

簡單地說，你可以使用 K8s 提供的開箱即用的高級部署技術-- 滾動升級。我們需要使用金絲雀部署來實現漸進式發布，目的是將流量逐步路由到新版本的應用，等待指標采集，然后進行分析并于預先定義的規則進行匹配。如果檢查正常，則增加流量；如果發現問題，則回滾部署。

在 Kubernetes 上可以使用 Argo Rollouts[22] 來實現金絲雀發布。

•  Argo Rollouts 是一個 Kubernetes controller，它使用一組 CRDs 來提供高級部署能力，如藍綠、金絲雀、金絲雀分析、實驗等，并向Kubernetes提供漸進式交付功能。

雖然像 Istio 這樣的服務網格可以提供金絲雀發布，但Argo Rollouts簡化了處理流程，且以開發者為中心。除此之外，Argo Rollouts還可以集成到任何服務網格中。

Argo Rollouts 是 GitOps 友好的，且能很好地與 Argo Workflows 和 ArgoCD 進行集成。使用這三種工具可以為部署創建一個非常強大的聲明式工具集。

Flagger[23] 和Argo Rollouts非常類似，可以很好地與 Flux[24] 進行集成，因此如果你正在使用Flux，可以考慮使用Flagger。

Crossplane

Crossplane[25] 是我最近喜歡的K8s工具，它填補了Kubernetes的一個關鍵空白：像管理K8s資源一樣管理第三方服務。這意味著，你可以使用YAML中定義的K8s資源，像在K8s中配置數據庫一樣配置AWS RDS或GCP cloud SQL等云供應商的數據庫。

有了 Crossplane，就不需要使用不同的工具和方法來分離基礎設施和代碼。你可以使用 K8s 資源定義所有內容。通過這種方式，你無需去學習并分開保存像 Terraform[26] 這樣的工具。

•  Crossplane 是一個開源的 Kubernetes 擴展，可以讓平臺團隊組合來自多個供應商的基礎設施，并為應用團隊提供更高級別的自服務 APIs(而無需編碼任何代碼)。

Crossplane 擴展了 Kubernetes 集群，使用 CRDs 來提供基礎設施或管理云服務。再者，相比于 Terraform 這樣的工具，它可以完全實現自動部署。Crossplane 使用現成的 K8s 能力，如使用控制循環來持續監控集群，并自動檢測配置漂移。例如，如果定義了一個可管理的數據庫實例，后續有人手動進行了變更，Crossplane 會自動檢測該問題，并將其設置回先前的值。它將基礎設施作為代碼并按照 GitOps 原則來執行。

Crossplane 可以與 ArgoCD 配合起來，監控源代碼，并保證代碼庫是唯一的信任源(SOT)，代碼中的任何變更都會傳遞到集群以及外部云服務。

如果沒有 Crossplane，你可以在 K8s 服務中實現 GitOps，但無法在沒有額外處理的前提下實現云服務的GitOps。

Kyverno

Kubernetes 為敏捷自治團隊提供了極大的靈活性，但能力越大責任越大。必須有一套最佳實踐和規則來保證部署的一致性和連貫性，并使工作負載遵循公司要求的策略和安全。

Kyverno[27] 是一種為 Kubernetes 設計的策略引擎，它可以像管理 Kubernetes 資源一樣管理策略，不需要使用新的語言來編寫策略。Kyverno 策略可以校驗、修改和生成 Kubernetes 資源。

•  Kyverno 策略是一組規則，每條規則包含一個 match 子句，一條 exclude 子句和 validate, mutate 或 generate 中的某條子句。一條規則定義中只可以包含一個 validate, mutate 或 generate 子節點。
  

你可以配置任何有關最佳實踐、網絡或安全的策略。例如，可以強制所有包含標簽的服務或所有容器運行在非 root 權限下。策略可以應用到整個集群或特定的命名空間中。你可以選擇是否期望對策略進行審計或強制它們阻止用戶部署資源。

Kubevela

Kubernetes 的一個問題是開發者需要知道并對平臺和集群配置有所了解。很多開發者抱怨 K8s 的抽象級別太低，因此在那些只關心編寫和交付應用的開發者中間出現了爭議。

Open Application Model (OAM[28] ) 可以解決這個問題，它的理念是圍繞應用創建一個更高級別的抽象，其獨立于底層運行時。。

•  通過關注應用而非容器或編排器。OAM 帶來了模塊化、可擴展和可移植的設計，通過更高級別且一致的 API 對應用程序部署進行建模。
  

Kubevela[29] 是OMA模型的一種實現。KubeVela是運行時無關，且可擴展的，但最重要的是，它以應用程序為中心。在Kubevela 中，應用程序是以Kubernetes資源實現的一等公民。需要區分集群運維人員(平臺團隊)和開發者(應用團隊)的區別。集群運維人員通過定義 components(構成應用程序的可部署/可提供的實體，如 helm charts)和 traits 來管理集群和不同的環境。開發者通過組裝components 和traits來定義應用。

•  平臺團隊：將平臺能力作為 components 或 traits 以及目標環境規范進行建模和管理。
  
•  應用團隊：選擇一個環境，組裝需要的 components 和 traits，并將其部署到目標環境中。
  

KubeVela 是 CNCF 的沙盒項目，目前正處于初始階段，在不久的將來，它可以改變開發者使用 Kubernetes 的方式，使他們能夠更加關注應用本身。但我對 OAM 在現實世界中的適用性有一些擔憂，由于一些像系統程序、ML 或大數據處理之類的服務，它們在很大程度上取決于底層細節，這種情況就很難融入 OAM 模型。

Schema Hero

軟件開發中另一種常見的的處理流程是在使用關系型數據庫時，需要管理 schema 的演進。

SchemaHero[30] 是一個開源數據庫的schema遷移工具，可以將schema定義轉化為可以在任何環境運行的遷移腳本。它使用了Kubernetes的聲明特性來管理數據庫schema的遷移。你可以指定期望的狀態，并讓 SchemaHero 管理剩下的工作。

Bitnami Sealed Secrets

至此，我們已經涵蓋了很多 GitOps 工具，我們的目標是將所有內容保存到 Git，并使用 Kubernetes 的聲明特性來讓環境保持同步。我們可以（也應該）在 Git 中保證 SOT，并讓自動化流程處理配置更改。

有一種資源通常難以保存到 Git 中，即 secret，如 DB 密碼或 API 密鑰。一種常見的解決方案是使用外部"保險庫"，如 AWS Secret Manager[31] 或 HashiCorp Vault[32] 來保存這些secret，但這樣也產生了沖突，你需要一個單獨的流程來處理secrets。理想情況下，我們希望通過某種方式將secrets像其他資源一樣安全地保存到Git中。

Sealed Secrets[33] 就是用來解決這種問題的，它允許你將敏感數據通過強加密保存到Git中，Bitnami Sealed Secrets天然集成進了Kubernetes中，可以使用Kubernetes中運行的Kubernetes controller來解密secret，而無需依賴其他組件。controller可以解密數據并創建原生的K8s secrets資源。通過這種方式可以將所有內容作為代碼保存到倉庫中，進而可以安全地執行持續部署，不需要依賴外部資源。

Sealed Secrets 包含兩部分：

•  集群側的控制器
  
•  客戶端側程序：kubeseal
  

kubeseal 程序使用非對稱加密來對 secrets 進行加密，且只有 controller 可以解密。這些加密的 secrets 被編碼到了 K8s 的 SealedSecret 資源中(可以保存到 Git 中)。

Capsule

很多公司使用多租戶來管理不同的客戶，這在軟件開發中很常見，但很難在 Kubernetes 中實現。一種方式是通過 命名空間 將集群劃分為獨立的邏輯分區，但無法完全隔離用戶，還需要引入網絡策略、配額等等。你可以在每個命名空間中創建網絡策略和規則，但這是一個讓人乏味的過程，且無法擴展，而且租戶無法使用多個命名空間，這是一個很大的限制。

分層命名空間[34] 可以用來解決這些問題。方法是為每個租戶分配分配一個父命名空間，并為該租戶配置通用的網絡策略和配額，并允許創建子命名空間。這是一個很大的改進，但在租戶層面，缺少安全性和治理方面的原生支持。此外，它還沒有達到生產狀態，但預計將在未來幾個月發布1.0版本。

一種常見的方式是為每個客戶創建一個集群，這樣做相對比較安全，并給租戶提供了所需的一切內容，但這種方式很難管理，費用也很高。

Capsule[35] 是一種在單個集群中為Kubernetes提供多租戶功能的工具。使用Capsule，你可以將所有租戶放到一個集群中。Capsul會為租戶提供一個"近乎"原生的體驗(雖然有一些小小的限制)，租戶可以在其集群中創建多個命名空間。這種方式隱藏了多租戶共享底層集群的事實。

在一個集群中，Capsule 控制器將多個命名空間聚合到一起，抽象為一個輕量級的 Kubernetes，稱為租戶，它是一組 Kubernetes 命名空間。在每個租戶中，用戶可以創建其命名空間并共享分配到的資源，Policy Engine 保證租戶間的隔離性。

網絡和安全策略、資源配額、LimitRanges、RBAC 和在租戶級別定義的其他策略由租戶中的所有命名空間自動繼承，類似于分層命名空間。然后，用戶可以自主地操作租戶，而無需集群管理員的干預。

Capsel 是 GitOps 的，因為它是聲明性的，所有的配置都可以存儲在 Git 中。