本系列文章的第一部分介紹了如何在Kubernetes集群中實現真正的零停機時間更新。 我們專門解決了將流量從舊實例切換到新實例時出現的請求失敗。 本文將展示如何使用Istio群集實現相同的目標。

服務網格技術（例如Istio）通常與容器編排結合使用。 Istio以透明的方式為我們的應用程序提供了諸如彈性，遙測和高級流量管理之類的跨領域問題。

當我們使用Istio時，與內部Kubernetes相比，集群內部網絡模型看起來有些不同。 如果您不了解Istio當前的網絡API的設計方式，則可以觀看以下說明視頻 。

使用Istio嘗試零停機

讓我們從文章的第一部分開始。 如果我們采用與以前類似的方式將應用程序重新部署到Istio群集，則會注意到更新期間的行為有所不同。 當我們重新運行旨在檢測可用性差距的負載測試時，我們會注意到，盡管我們有preStop pod生命周期處理程序，但仍有一些失敗的請求。

Fortio 1.1.0 running at 500 queries per second, 4->4 procs, for 20s Starting at 500 qps with 50 thread(s) [gomax 4] for 20s : 200 calls each (total 10000) 09:11:39 W http_client.go:673> Parsed non ok code 503 (HTTP/1.1 503) [...] Code 200 : 9960 (99.6 %) Code 503 : 40 (0.4 %) Response Header Sizes : count 10000 avg 165.204 +/- 10.43 min 0 max 167 sum 1652048 Response Body/Total Sizes : count 10000 avg 176.12 +/- 3.817 min 171 max 227 sum 1761200 [...]

輸出表明有一些HTTP請求失敗，并帶有503 Service Unavailable狀態代碼。 無論我們如何調整preStop處理程序的等待時間，在流量大時更新服務時，我們似乎都會至少preStop一些客戶端請求。 同樣，我們是否通過網關從網格內部還是從群集外部訪問Istio服務似乎也沒有什么區別。

了解發生了什么

要了解發生了什么，讓我們仔細看看Istio邊車容器如何連接到各個服務。

網格中的所有流量都通過連接到各個實例的Sidecar代理進行路由。 對于通過網關的入口流量也是如此。

在我們的場景中，這意味著邊車可能無法連接到實例，即使它們已經準備好為交通服務。 代理以最終一致的方式配置； 配置從飛行員平面逐漸傳播。

Envoy還對實例執行主動的運行狀況檢查，它將檢測異常值并最終阻止與它們的連接。 為Pod定義的基于HTTP的就緒探針也將包括在內，并由Envoy代理執行。 換句話說，即使容器仍會接受請求，代理容器也不會連接到準備就緒探測失敗的容器。 我們可以通過網狀配置添加到Sidecar代理中的重試配置只能緩解但不能解決此問題。

通過Istio實現零停機

有一些方法可以在將來向Kubernetes引入更多增強的健康檢查概念。

但是，當前，在工作量和可靠性之間的合理平衡是使用Istio子集作為版本指示符，并獨立于Kubernetes的滾動更新機制重新路由服務流量。 通過這種方法，我們使用服務子集來標識應用程序的版本（例如v1或v2 ，并將虛擬服務配置為路由到一個特定版本。 由虛擬服務資源配置的Istio代理路由可以重新路由到具有真正零停機時間的不同子集版本。

為了使用這種方法，我們將創建單獨的Kubernetes部署，為我們的應用程序的每個單獨版本創建一個，并通過Istio執行實際的切換。

部署示例如下所示：

• 最初：Kubernetes部署coffee-shop-v1帶有標簽app=coffee-shop ， version=v1 ，目的地規則來定義子集v1 ，和虛擬服務，航線coffee-shop v1
• 我們增強了目標規則，以包括版本v2的新子集
• 我們創建一個version=v2的部署coffee-shop-v2 version=v2
• 成功部署完成后，我們將虛擬服務重新路由到v2 。 切換將不會丟失請求。
• 短暫的等待后，我們從目標規則中刪除了子集v1 ，并部署了coffee-shop-v1

如果我們從第一部分開始重新運行相同的負載測試，則會注意到我們可以執行實際的零停機時間部署。

Fortio 1.1.0 running at 500 queries per second, 4->4 procs, for 20s Starting at 500 qps with 50 thread(s) [gomax 4] for 20s : 200 calls each (total 10000) [...] Code 200 : 10000 (100.0 %) Response Header Sizes : count 10000 avg 159.530 +/- 0.706 min 154 max 160 sum 1595305 Response Body/Total Sizes : count 10000 avg 167.853 +/- 2.51 min 161 max 171 sum 1678534 [...]

如果您不熟悉如何使用Istio的網絡API來實現此過程，則可以觀看說明視頻 。

自動化是關鍵

當然，我們不想手動執行這些步驟。 想法是定義一個在每個新軟件版本上執行的自動化過程。 最終，這種部署應作為持續交付管道的一部分進行，該管道將我們的軟件部署到相應的環境中。

我們可以增強我們的持續交付渠道，以部署Canary版本，在該版本中，我們僅將一小部分用戶流量路由到。 這也將作為自動化方法同樣包含在管道中：逐漸將用戶流量路由到新部署的版本，然后在Canary版本證明其自身運行良好后執行完全切換。

如果我們以模板語言定義部署和Istio路由定義，則將有幫助。 這樣，我們可以可靠地定義和更改應用程序版本和映像版本，并始終如一地推出更改。 coffee-shop示例項目包括一個自動化腳本，該腳本使用Istio執行零停機時間部署，并基于使用kontemplate的YAML模板方法進行構建 。

結論

Kubernetes的生產就緒性是一個非常有價值的功能，它是開箱即用的。 但是，我們需要更多地考慮，以充分實現零停機時間行為。 測試您將在生產環境中運行的應用程序的停機時間并相應地調整探測和各種超時至關重要。

當然，了解Kubernetes和Istio如何分別管理與后端的連接也很有幫助。 如果我們在更新期間稍微調整行為，則可以消除最后的可用性差距。

零宕機時間以及正確的連接耗盡和保持活動連接處理能力使我們的應用程序可以隨時部署，而不會中斷用戶。 一旦達到這一點，我們就可以不斷改進軟件，并更快地交付功能和錯誤修復以投入生產。 因此，零停機時間部署是持續交付和持續改進文化正常運行的前提之一。

• GitHub項目示例（Istio版本）
• Kubernetes的零停機滾動更新（第一部分）
• Istio Networking API說明視頻
• Kontemplate（Kubernetes模板工具）

翻譯自: https://www.javacodegeeks.com/2018/10/zero-downtime-rolling-updates-istio.html

總結

以上是生活随笔為你收集整理的Istio的零停机滚动更新的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。