GitOps——像代碼同樣管理Istio配置

GitOps——像代碼同樣管理Istio配置

• 本文譯自Weaveworks 官方博客：
  • https://www.weave.works/blog/gitops-for-istio-manage-istio-config-like-code
• 本文來源，https://mp.weixin.qq.com/s/Zt8BjW4GhR89jhprG8hD8A
• 本文地址，http://www.javashuo.com/article/p-hwovwrlo-cr.html

在今年的哥本哈根 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 有四個普遍的領域應用，都是經過聲明式配置驅動的：

1. 流量管理：與管理入口和服務流量有關。
2. 可觀察性：監控、流量延遲、QPS、錯誤率等。
3. 安全性：全部服務間調用的認證與受權。
4. 性能：包括重試超時、故障注入和斷路等。

由於全部這些領域均可以跨越組織內的不一樣團隊，因此這使得在 Istio 上管理應用程序尤爲具備挑戰性。

這些配置驅動的不少設置是跨團隊的。例如，有的團隊想用 Zipkin 進行跟蹤，而另外一個團隊可能想用 Jaeger。這些決策能夠針對某一項服務進行，也能夠跨服務進行。當決策跨越團隊時，審批工做流程將變得更加複雜，並不老是原子性的。金絲雀發佈不是原子的一次性事情。

經過 GitOps 工做流程在 Istio 上作金絲雀部署

Stefan Prodan 向咱們展現瞭如何使用帶有 Weave Flux 和 Prometheus 的 GitOps 工做流程在 Istio 中作一次金絲雀發佈——您能夠在 Weave Cloud 中使用這些工具以及金絲雀部署和可觀察性。

簡而言之，當您想要用一部分用戶測試某些新功能時，會使用金絲雀部署或發佈。傳統上，您可能擁有兩臺幾乎徹底相同的服務器：一臺用於全部用戶，另外一臺用於將新功能部署到某一組用戶。

但經過使用 GitOps 工做流程，您能夠經過 Git 控制您的金絲雀，而不是設置兩個獨立的服務器。當出現問題時，能夠回滾到舊版本，而且能夠在金絲雀部署分支上進行迭代，並繼續發佈，直到知足預期爲止。

在 Weave Cloud 中，Git 控制的金絲雀發佈具備徹底可觀察性

經過流水線推送變動，您能夠向用戶發送部分必定比例的流量。使用 Weave Cloud，您能夠在儀表板中觀察金絲雀是否按預期工做。若是有問題能夠繼續修改，而後推出下一個版本，對其進行標記後經過同一流水線部署。這就是 GitOps 工做流程幫助您管理的迭代過程。

總結

Alexis Richardson 給了咱們關於 GitOps 的概述，以及爲何您須要在管理運行在 Kubernetes 和 Istio 上的應用程序時考慮這種方法。而後 Varun Talwar 談到了 Istio 是什麼以及如何使用 GitOps 工做流程來管理應用程序。最後，Stefan Prodan 向咱們展現了一個特殊用例，其中非原子工做流程（如金絲雀發佈）也能夠經過像 Istio 這樣的服務網格上的 GitOps 進行管理。

• 查看演講全文及視頻，請訪問：https://youtu.be/VkKMf23ZokY
• 想要投稿，參與到 Service Mesh 相關資料的翻譯活動中來，請訪問 https://servicemesher.github.io/blog/gitops-for-istio-manage-istio-config-like-code/