在今年的哥本哈根 Kubecon 大會上，Weaveworks 的 CEO Alexis Richardson 與 Varun Talwar談到了 GitOps 工作流程和 Istio。會後 Weaveworks 的 Stefan Prodan 進行了的示範，介紹如何使用 GitOps 上線和管理 Istio 的金絲雀部署。
會談和示範中解釋了：
- 什麼是 GitOps？為什麼需要它？
- Istio 和 GitOps 的最佳實踐是如何管理在其上運作的應用程式的。
- 如何使用 GitOps 工作流程和 Istio 進行金絲雀部署。
什麼是GitOps？
GitOps 是實作持續傳遞的一種方式。“GitOps 使用 Git 作為聲明式基礎架構和應用程式的真實來源” Alexis Richardson 說。
當對 Git 進行更改時，自動化傳遞管道會上線對基礎架構的更改。但是這個想法還可以更進一步——使用工具來比較實際的生産狀态和源代碼控制中描述的狀态，然後告訴你什麼時候叢集的狀态跟描述的不符。
Git 啟用聲明式工具
通過使用 Git 這樣的聲明式工具可以對整套配置檔案做版本控制。通過将 Git 作為唯一的配置來源，可以很友善的複制整套基礎架構，進而将系統的平均恢複時間從幾小時縮短到幾分鐘。
GitOps 賦能開發人員擁抱運維
Weave Cloud 的 GitOps 核心機制在于 CI/CD 工具，其關鍵是支援 Git 叢集同步的持續部署（CD）和釋出管理。Weave Cloud 部署專為版本控制系統和聲明式應用程式堆棧而設計。以往開發人員都是使用 Git 管理代碼和送出 PR（Pull Request），現在他們也可以使用 Git 來加速和簡化 Kubernetes 和 Istio 等其他聲明式技術的運維工作。
GitOps 的三個核心原則
根據 Alexis 的說法，下面描述的是為何 GitOps 既是 Kubernetes 又是雲原生核心的原因：
1. GitOps 的核心是聲明式配置
通過使用 Git 作為實體源，并使用 Kubernetes 做滾動更新，可以觀察叢集并将其與期望的狀态進行比較。 通過将聲明性配置視為代碼，它允許您通過在未成功時重新應用更改來強制收斂。
2. 不應該直接使用 Kubectl
根據一般規則來看，将代碼經過 CI 直接 push 到生産并不是個好主意。許多人通過 CI 工具驅動部署，但是當你這樣做的時候你可能不得不做一個通路生産的東西。
3. 使用 operator 模式
通過 operator 模式，叢集将始終與 Git 中簽入的内容保持同步。Weave Flux 是開源的，它是使用 Istio 示範下面的金絲雀部署的基礎，您可以使用 operator 管理叢集中的更改。
無論是開發流程還是生産流程，還是從預發到合并到生産，operator 都會将更改 pull 到叢集中，即使是有多個更改也能以原子的方式部署。
Istio 的 GitOps 工作流程
接下來，Varun Talwar 談到了 Istio 是什麼以及如何使用 GitOps 工作流管理應用程式。
Istio 是一年前釋出的服務網格。它是一個專用的基礎設施層，用于為微服務架構中的所有服務間互動提供服務。Istio 中的所有操作都是通過聲明式配置檔案驅動的。也就是說像 Istio 這樣的服務網格可以讓開發人員在 Git 中像管理代碼一樣完全的管理服務行為。
借助 Git 工作流程，開發人員可以對 Istio 中的任何内容進行模組化，包括服務行為及其互動，如逾時、斷路器、流量路由、負載均衡及 A/B 測試和金絲雀釋出等。
跨團隊的多組配置
Istio 有四個廣泛的領域應用，都是通過聲明式配置驅動的：
- 流量管理：與管理入口和服務流量有關。
- 可觀察性：監控、流量延遲、QPS、錯誤率等。
- 安全性：所有服務間調用的認證與授權。
- 性能：包括重試逾時、故障注入和斷路等。
因為所有這些領域都可以跨越組織内的不同團隊，是以這使得在 Istio 上管理應用程式尤其具有挑戰性。
這些配置驅動的很多設定是跨團隊的。例如，有的團隊想用 Zipkin 進行跟蹤，而另一個團隊可能想用 Jaeger。這些決策可以針對某一項服務進行，也可以跨服務進行。當決策跨越團隊時，審批工作流程将變得更加複雜，并不總是原子性的。金絲雀釋出不是原子的一次性事情。
通過 GitOps 工作流程在 Istio 上做金絲雀部署
Stefan Prodan 向我們展示了如何使用帶有 Weave Flux 和 Prometheus 的 GitOps 工作流程在 Istio 中做一次金絲雀釋出——您可以在 Weave Cloud 中使用這些工具以及金絲雀部署和可觀察性。
簡而言之，當您想要用一部分使用者測試某些新功能時，會使用金絲雀部署或釋出。傳統上，您可能擁有兩台幾乎完全相同的伺服器：一台用于所有使用者，另一台用于将新功能部署到某一組使用者。
但通過使用 GitOps 工作流程，您可以通過 Git 控制您的金絲雀，而不是設定兩個獨立的伺服器。當出現問題時，可以復原到舊版本，并且可以在金絲雀部署分支上進行疊代，并繼續釋出，直到滿足預期為止。
在 Weave Cloud 中，Git 控制的金絲雀釋出具有完全可觀察性