Istio?1.16對環境網格和用戶意味著什么？

作者：布加迪 2022-12-22 08:00:00

雖然Istio 1.15沒有太多新的功能，但Istio 1.16做了許多改進。值得關注的，由于支持從N-2到N的版本跳過升級，Istio項目一直致力于對偶數版本號發布更多的改進，奇數版本號充當穩定版本號，以便人們可以輕松實現從N-2到N的版本跳過升級。

?譯者 | 布加迪

審校 | 孫淑娟

雖然Istio 1.15沒有太多新的功能，但Istio 1.16做了許多改進。值得關注的，由于支持從N-2到N的版本跳過升級，Istio項目一直致力于對偶數版本號發布更多的改?進，奇數版本號充當穩定版本號，以便人們可以輕松實現從N-2到N的版本跳過升級。

這篇博文重點介紹讓人特別興奮的Istio 1.16的幾項新功能和改進。

sidecar和ingress中支持基于HTTP的覆蓋網絡環境（HBONE）

我們在KubeCon US 2022大會上發現Istio環境網格（ambient mesh）大受追捧，用戶非常喜歡2層架構以促進增量采用，在環境網格中添加工作負載異常簡單。環境網格還不是Istio 1.16的一部分，社區成立了一個專門的工作組，將環境網格推向Istio master視作重中之重。對于Istio 1.16或更新版本而言，社區通過在sidecar和ingress網關中添加HBONE支持，為sidecar與環境網格中的pod實現互操作鋪平了道路。

HBONE是一種用于服務間網格通信的新的隧道機制。這不是應用程序所有者直接看到或使用的東西，因為它被設計成在代理之間幕后透明地操作（sidecar <-> ztunnel <-> waypoint proxy <-> gateway）。考慮到ztunnel和waypoint代理只能通過HBONE發送和接收流量，sidecar若要與它們進行互操作，sidecar就要知道目的地是否可以處理HBONE流量，并且只有在目的地能夠理解HBONE流量的情況下才可以通過HBONE發送流量（見圖1，App C到App A）。如果目的地不支持HBONE，sidecar繼續如往常一樣發送經典的相互TLS流量（見圖1，App C到App B）。

圖1

同樣，sidecar從ztunnel或waypoint代理接收流量時知道如何終止HBONE流量（見圖2）。

圖2

為了探究這項功能，可以使用您偏愛的Istio安裝程序，安裝ambient配置文件即可，比如：

圖3

注意這個配置文件只為sidecar啟用HBONE，真正的環境模式很快就會實施。在部署注入sidecar的簡單的sleep應用程序后，您會注意到network .istio.io /tunnel: HTTP標簽被添加到sleep，類似于security.istio.io/tlsMode: istio標簽。這個新的隧道標簽使Istio能夠知道代理是否支持HBONE。

圖4

鑒于這項功能是實驗性的，默認情況下被禁用，因此不建議您在生產環境中使用它。

發現選擇器方面的改進

聽取Solol.io大規模客戶的意見后，去年我們為Istio上游貢獻了發現選擇器（discovery selector），以便用戶可以動態地限制作為網格一部分的命名空間集。我們對社區廣泛采用發現選擇器感到非常興奮，這使得Istio 1.16中的發現選擇器得到了改進！

您不僅可以使用發現選擇器來配置Kubernetes資源，借助1.16，還可以使用發現選擇器來配置Istio自定義資源，比如Gateway、VirtualService和DestinationRule等。此外，您可以利用發現選擇器來配置Istio控制平面。如果您想為特定的控制平面指定允許的網格命名空間，或者基于一個或多個命名空間的邊界為網格啟用軟性多租戶，這些改進非常有用。這一改進的最大好處是，對于開發人員來說，API方面沒有變化，您可以像1.16之前那樣繼續使用發現選擇器。

要啟用這項功能，您可以啟用發現選擇器以及ENABLE_ENHANCED_RESOURCE_SCOPING環境變量。下列YAML含有一個使用環境配置文件啟用這項功能的示例：

# The ambient profile has ambient mesh enabled
# Note: currently this only enables HBONE for sidecars, as the full ambient mode is not yet implemented.
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    discoverySelectors: 
      - matchLabels:
          istio-discovery: enabled
    defaultConfig:
      proxyMetadata:
        ISTIO_META_ENABLE_HBONE: "true"
values:
  pilot:
    env:
      PILOT_ENABLE_INBOUND_PASSTHROUGH: "false"
      PILOT_ENABLE_HBONE: "true"
      ENABLE_ENHANCED_RESOURCE_SCOPING: "true"

用istio-discovery=enabled標記default和foo命名空間，顯示sleep部署的路由配置：

將review虛擬服務運用于foo和bar命名空間，然后顯示sleep部署的路由。您會注意到reviews.foo虛擬服務在路由列表中，但reviews.bar不在列表中。

默認情況下，Istio為Kubernetes集群中的每個命名空間創建istio -ca-root-cert配置映射，不管該命名空間在網格中是否有任何服務。1.16中發現選擇器得到改進后，您可以選擇創建配置映射的命名空間。如果顯示每個命名空間的配置映射，您會注意到istio-ca-root-cert配置映射是為default和foo命名空間創建的，而不是為bar命名空間創建的：

不僅可以為Kubernetes服務選擇哪些命名空間是網格的一部分，還可以為Istio資源選擇哪些命名空間是網格的一部分，這不是很好嗎？

Istio API和Kubernetes Gateway API

Istio 1.16的一個關鍵變化是Gateway API選項卡被添加到Istio現有API的旁邊，用于一些流量管理任務，這是Istio采用Kubernetes Gateway API的結果。當您瀏覽流量管理任務時，會看到一些任務只能通過Istio API來完成，比如請求超時或故障注入。為什么？因為它們還不能被轉換成Gateway API。由于服務網格社區正致力于GAMMA項目，試圖跨Istio、Linkerd、Consul connect、Kuma和OSM為網格操作人員和開發人員實現網格API標準化，我們預計需要一段時間才能使網格API實現標準化，同時繼續使每個項目能夠創新，領先于通用API。作為GAMMA項目的貢獻者之一，我們對GAMMA以及基于角色的項目中立網格API作為GAMMA項目的一部分的前景方向感到興奮。

Wasm方面的改進

Istio社區采用由Solo.io發起的Wasm OCI映像規范是好事。最近規范方面有了改進，可支持多個層。比如說，您可以根據業務需求輕松添加另一層來標記鏡像。另一個令人興奮的變化是，在WasmPlugin資源中引入了traffic selector（流量選擇器），這使用戶能夠精確地選擇WasmPlugin資源應該運用于哪路流量。您可能想知道：“這與通常面向服務生產者的工作負載選擇器有什么不同？”不指定任何流量選擇器配置，WasmPlugin用于通過工作負載選擇器選擇的目標工作負載，不管服務有哪些偵聽器。流量選擇器配置使您能夠根據某個特定端口來微調選擇器，并指定工作負載模式。

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: httpbin-rust-test
  namespace: httpbin
spec:
  selector:
    matchLabels:
      app: httpbin
  # Define traffic selector match conditions
  # All conditions must evaluate to true for the plugin to be applied
  match:
    # Define the workload mode, valid options are: SERVER, CLIENT, CLIENT_AND_SERVER
    - mode: SERVER
    # Define port numbers to match. If not specified, all ports are matched
    - ports:
      - number: 80
  url: oci://docker.io/dhawton/wasm-rust-test:v1

有了上述WasmPlugin資源面向httpbin工作負載的端口80服務，我們可以將簡單的Wasm過濾器部署到httpbin的Envoy代理中，該代理從事非常基本的日志任務，等待HTTP請求進入。發現路徑匹配后，插件將在暫停Envoy過濾器的其余部分之前返回418狀態碼和ASCII字符組成的ASCII字符。下列是Wasm過濾器的邏輯：

match self.get_http_request_header(":path") {
    Some(path) if path == "/get" => {
        info!("on_http_request_headers: {} - /get intercepted", self.context_id);
        self.send_http_response(
            418,
            vec![("x-powered-by", "rust"), ("content-type", "text/plain")],
            Some(TEAPOT_ASCII),
        );
        Action::Pause
    }
    _ => Action::Continue,
}

部署WasmPlugin配置后，我們可以看到端口80上httpbin的/get端點的curl被Wasm過濾器攔截，無需重新啟動httpbin部署。

我們如何才能演示選擇性匹配？我們將運用下列配置（將端口號80改成81）來演示Wasm過濾器未被運用于httpbin流量：

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: httpbin-rust-test
  namespace: httpbin
spec:
  selector:
    matchLabels:
      app: httpbin
  match:
    - ports:
      - number: 81
  url: oci://docker.io/dhawton/wasm-rust-test:v1