​译者 | 布加迪

审校 | 孙淑娟

虽然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

如果我们运行同样的curl，应该会看到上面的WasmPlugin资源并没有影响端口80上的httpbin工作负载，因此我们得到httpbin的预期响应。

结语

Istio 1.16是社区发布的另一个令人兴奋的版本。还有其他许多的改进在本文没有介绍，请参阅​​版本变更说明​​以查看所有其他改进，包括：支持MAGLEV负载均衡算法、支持使用OpenTelemetry跟踪提供程序以及Telemetry API以及新的远程配置文件等。

原文标题：​​Istio 1.16 is out, what does it mean for ambient mesh and you?​​，作者：Lin Sun和Daniel Hawton​