Istio1.7有哪些特性

本篇內容介紹了“Istio1.7有哪些特性”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

如約而至 ——Istio 1.7.0 發布

就在幾天前，Istio 發布了 1.7 版本，和 1.6 版本的發布時間正好間隔三個月，完美的實現了季度發布的諾言。本次發布的口號是 “偉大的 Istio 社區（Istio’s great community）”，因為有來自 40 多個公司的 200 多個開發者做出了貢獻。Istio 官方是這樣描述的：

正是因為有如此令人驚羨（amazing）的社區，才讓 Istio 能夠在每個季度有如此多的改進。

Istio 團隊已經從上個月倒賣商標的麻煩中走了出來，看上去是想通過強調 Istio's great community
這個理念來撫平社區開發者受傷的心靈？筆者認為，作為開發者和用戶不必太在意 Google 的商業行為，至少現階段 Istio 還在以開源的身份持續演進，還能為我所用，這就足夠了。

1.7 版本中重要的更新主要有以下四個方面。

安全增強

• 確認了使用安全發現服務（SDS）作為證書分發的優勢，并把它作為一個重要的安全最佳實踐。現在這一特性也被使用在出口網關上。

• 信任域驗證除了支持 HTTP，現在也可以驗證 TCP 流量了，并且還支持在 MeshConfig 中進行配置，提供了更多靈活性。

• 可以使用ECC 進行 CA 通信，提高了安全性和效率。

• 網關默認使用非根（non-root）用戶部署，這主要是基于一條最佳實踐：不要讓運行的進程有多于它所需的權限，這會導致不必要的混淆。

提升易用性

在易用性方面主要的改進依然是對 istioctl
命令行工具的增強：

DestinationRule
ISTIOCONFIG
istioctl x uninstall

生產運維改進

在運維方面也有些許改進，例如：

• 可以支持讓 Sidecar 啟動后才啟動你的應用容器。如果你的應用需要在啟動時通過 Sidecar 代理來訪問資源，這項修改可以讓部署變的更穩定（避免因為 Sidecar 沒啟動而應用訪問不到資源的情況）。

• Istio Operator 作為最佳安裝方式。Operator 在之前的版本就已經提供了，看上去 Istio 想主推 Operator 以替代其他的安裝形式。但筆者必須要吐槽一下官方發布文檔對這一條的描述：

TheIstio Operator is a great way to install Istio, as it automates a fair amount of toil. Canary control plane deployments are also important; they allow ultra-safe upgrades of Istio. Unfortunately, you couldn’t use them together -until now.

吹了一大堆，其實翻譯成人話就是：Operator 目前還不支持金絲雀更新。真是佩服這段文案編寫者拐彎抹角的能力。

• 提供了 istio-agent 的指標，可以觀察它的運行情況

• Prometheus 指標收集方面的改進

VM 安全性

持續對虛擬機相關功能的開發是本年度的重點，這是 Istio 多次強調的。這是因為目前客戶應用部署環境的復雜性和混合性，VM 依然是一種主要的部署選擇。和一些托管的競品（比如 AWS APP Mesh ）相比，Istio 缺失了這方面的能力，使得這些客戶不得不觀望而無法落地。對 VM 的支持就成為了重中之重，這也是商業上的考量。

然而本次更新沒有太多的重量級功能發布，只是做了小的改進，且還在 alpha 階段。比如為 VM 也增加了安全特性，支持證書自動輪轉； istioctl
現在可以驗證 VM 的代理狀態；增加了 RPM 安裝包等。

溫柔一刀 —— 升級的傷痛

客觀的講，以上官方的發布文檔大部分內容都不痛不癢，對使用層面的用戶影響不大。而真正和用戶息息相關是安裝和升級的變化。Istio 團隊并沒有在發布首頁強調這一點，這引起了筆者的強烈不適并嚴重懷疑 Istio 有刻意規避問題的嫌疑。我們先來看筆者認為最重要的一條變更：

過分嚴格的平臺版本限制

Require Kubernetes 1.16+

Kubernetes 1.16+ is now required for installation.

這是 Istio 官方第一次在新版本的 Release Note 中明確的說明了 Kubernetes 的版本限制問題。盡管以前老版本的 Istio 也會對平臺版本有要求，但通常是這樣的口吻：

Istio 1.5 has been tested with these Kubernetes releases: 1.14, 1.15, 1.16.

這種描述隱含的意思就是：我們在這幾個版本測試過兼容性，但我們并沒有說 Istio 不兼容其他版本，可能、也許、大概是兼容的，我們只是沒有測試過而已。而這一次是描述是 “required”，請仔細體會這兩種說法的區別。

為了驗證 1.7 真實的兼容性（ required 只是駭人聽聞？），筆者做了一次安裝測試，測試環境為 Docker 桌面版內置的 Kubernetes，版本 v1.15.5。

首先，使用預檢命令驗證集群環境是否合法（新版本已經取消了 istioctl verify-install
命令）

$ bin/istioctl x precheck
Error: 1 error occurred:
* The Kubernetes API version: v1.15.5 is lower than the minimum version: 1.16

果然，預檢沒有通過，出現了版本過低的錯誤。筆者忽略預檢結果，嘗試強行安裝，想看看預檢是否也只是嚇唬人而已：

$ bin/istioctl install
This will install the default Istio profile into the cluster. Proceed? (y/N) y
The Kubernetes version v1.15.5 is not supported by Istio 1.7.0. The minimum supported Kubernetes version is 1.16.
Proceeding with the installation, but you might experience problems. See https://istio.io/latest/docs/setup/platform-setup/ for a list of supported versions.
? Istio core encountered an error: failed to wait for resource: failed to verify CRD creation: the server could not find the requested resource

驗證結果被現實啪啪打臉。除了對版本限制的說明，Istio 還非常嚴謹的告知安裝過程會繼續，但你可能會遇到各種問題。果然，在 Istio core 的安裝步驟中就報了錯，安裝過程被卡住無法繼續進行。看來這一次 Istio 的 required 是來真的了。

為什么說這個強制性的版本限制會對用戶造成最大的困擾？其根本原因就是當前絕大部分企業和用戶所使用的 Kubernetes 根本沒有達到 1.16+ 版本，大部分都是基于 1.14、1.12，甚至更低。目前兩大云廠商的 Kubernetes 服務（AWS EKS 和 GCloud GKE）也都是兼容 1.14+，這也能從一個側面說明有一大批老用戶很可能都使用的是 1.14 版本。然而 Istio 并沒有遵循這一規則，這等于直接將很大一部分用戶踢出了場外，Istio 1.7 不帶你們玩了。

另一個潛在的問題是為想要升級的用戶帶來了極大的困惑。舉一個例子：某企業的運維團隊正在打算將 1.14 版本的 Kubernetes 升級到 1.16，而架構團隊正打算將安裝在其上的 Istio 1.2 升級到 1.7。這個團隊所面臨的問題是，要升級到 Istio 1.7 必須先升級 Kubernetes 到 1.16；但是一旦升級了 1.16，原本的 1.2 版本很可能有兼容問題，因為 Istio 1.2 宣稱只在 Kubernetes 1.12~1.14 測試過。Istio 1.7 過分嚴格的的平臺版本限制給了這些用戶致命一刀，升級之路充滿荊棘。他們只能退而求其次選擇老版本進行升級。

從 1.5 版本開始，Istio 一方面不斷的強調易用性和用戶體驗，一方面又武斷的放棄向下兼容，將大量用戶拒之門外。其自相矛盾的行為令人匪夷所思。

資源版本號的變更

這一問題出現在 Change Note 安裝部分的一條，很可能成為升級用戶新的痛點。

Upgraded the CRD and Webhook versions to v1. ( Issue #18771
),( Issue #18838
)

從 Issue 可以看出，因為 Kubernetes 在 1.16 中將 webhook 的 API 版本改為 v1，并會在 1.19 版本中刪除老的 v1beta 版本。這一激進行為導致 Istio 不得不在自己的 1.8 版本之前完成對應的遷移。筆者在 Istio 官方 Slack 中也驗證了這一問題：

Yes this is a hard requirement. Most specifically CRDs, and other apis use APIs that were promoted to v1 in 1.16 are being used.

Istio 開發團隊也在 Issue 中抱怨對方太激進（aggressive），留給他們的開發周期太短（pretty tight window），有很多工作要做（probably a lot of work），一副巧婦難為無米之炊的委屈樣。筆者不由得感嘆：本是同門師兄弟，相煎太急！

而對于用戶而言，意味著你不得不將自己的 mesh 配置文件的版本號進行更新，如果集群比較龐大，很可能有不少的工作量（主要是測試、驗證方面）。你很可能還需要通過金絲雀升級的方式進行，因為無論是先升級 Istio，還是先修改配置，都可能出現兼容問題（說好的易用性和用戶體驗呢？）。

是 LTS 還是 STS（short term support）？

在 Istio 的版本支持公告頁面，你可以發現以前的老版本都逐漸的停止了維護，特別是具有里程碑意義的 1.5 版本，在發布 3 個月后即停止維護，成為 Istio 史上最短命的版本。這一度讓我懷疑其架構重建的質量。Istio 在構建和發布節奏頁面中這樣定義 LTS（long term support）：

Support is provided until 3 months after the next LTS

即所謂長期支持，也只有 3 個月。也就是說在每發布一個新版本，上一個老版本就不保證繼續支持了（包括更新、修復 bug 等）。我們再來對比一下 Ubuntu 對 LTS 的定義，下面是 Ubuntu 20.04 LTS 的一段說明：

下載專為桌面 PC 和筆記本精心打造的 Ubuntu 長期支持 (LTS) 版本。LTS 意為 “長期支持”，一般為 5 年。LTS 版本將提供免費安全和維護更新至 2025 年 4 月。

“Istio1.7有哪些特性”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！