2 月 9 日，Istio 宣布发布 Istio 1.9 版本。在这个版本中，我们可以看到虚拟机更广泛地被采用到服务服务网格中，而且对虚拟机的支持、对虚拟机的 cert 发放、对工作负载入口的健康检查也更加完善。Istio 最新的 1.7 和 1.8 两个版本，在让 VM 成为服务网格中一流的工作负载方面取得了很多进展，而 cert 发放则是最后需要弥补的缺口。
服务网格中的虚拟机集成
虚拟机集成是 Istio 的核心功能之一，在这个版本中，它升级到了测试版，这意味着它可以用于生产，不再是玩具。
在 Istio 服务网格中运行 Kubernetes 工作负载已经有一段时间了，在过去的几个 Istio 版本中，运行虚拟机工作负载也是如此。最新发布的 Istio 使得在服务服务网格中混合 Kubernetes 和 VM 工作负载更加容易。
常见的用例包括在数据中心的虚拟机或云环境中的虚拟机上运行应用程序。这些虚拟机要么运行传统的，要么运行第三方应用 / 服务。其中一些应用 / 服务不会在短时间内消失–或者在某些情况下，永远不会消失！其中一些虚拟机工作负载是应用现代化历程的一部分，包括转向微服务或 RESTful 服务，部署为分布式服务，其中一些在容器中运行。在这个应用现代化历程中，其中一些虚拟机运行单体工作负载，直到它们被分解为微服务：在虚拟机中运行这些应用提供了一条通往目标 RESTful 服务或 API 的路径，并使过渡更加平稳。
通过这样的渐进式方法，您可以开始将运行在虚拟机中的现有应用程序上岗到服务网格中。然后，随着你建立起你的服务服务网格实践，你可以逐渐将这些单体应用分解为服务，并更轻松地将它们部署在多个集群、云和混合环境中。Istio 可以使用 WorkloadEntry、WorkloadSelector 和 WorkloadGroup 来帮助您实现这一点，管理服务网格中的虚拟机，以促进您的应用现代化历程中更有保障的过渡。
与 Kubernetes Service API 保持一致
通过 Kubernetes 服务 API，基础设施提供商和平台运营商可以为不同的目的设置多个 Controller。因此，它将 Gateway 与 Envoy 解耦，方便了 Istio 中不同反向代理后端的使用。
Istio 从 1.6 版本开始就积极与 Kubernetes SIG-NETWORK 组合作，使用 Kubernetes Service API 来替代现有的 Gateway 声明，并将服务网格中的服务对外暴露。以前，你需要创建一个 VirtualService 来绑定到 Gateway 上，以便将服务暴露在服务网格之外。现在，您可以使用 GatewayClass、Gateway 和 Route。GatewayClass 定义了一组共享共同配置和行为的 Gateways。这类似于 IngressClass 的 Ingress 和 StorageClass 的 PersistentVolumes。Route 类似于 VirtualService 中的 Route 配置。你可以参考 Istio 文档来尝试这个功能，但要注意这个功能还处于实验阶段。
总结
Istio 1.9 让每个功能的状态更加清晰，这也有助于增强用户使用的信心。经过最近几次大的改动，相信 Istio 的 API 会在进一步的发展中变得更加稳定。
将服务服务网格扩展到虚拟机，一直是 Tetrate 成立的重要使命之一。Tetrate 提供 Istio 支持，以及为多集群、多租户和多云构建的基于 Istio 的优质服务网状管理平台。
资源
- Istio 1.9 版本：https://istio.io/latest/news/releases/1.9.x/announcing-1.9/
- Tetrate Service Bridge：https:/tetrate.io/tetrate-service-bridge
- GetIstio，Tetrate 测试过的开源 Istio 发行版：https://getistio.io
- 联系 Tetrate 了解更多信息