我很高兴呈现 Istio 的最新版本— Istio 1.19。这篇博客将概述此版本中的更新内容。
我们的前一篇博客强调了 Gateway API 将 Kubernetes 和服务网格中的入口网关统一的潜力,为跨命名空间的流量支持打开了大门。有了 Istio 的官方支持,Gateway API 成为了焦点。它不仅用于北 - 南流量(网格的入口和出口),现在还扩展到东 - 西流量的领域,也就是网格内部的流量。
在 Kubernetes 中,服务承担多项职责,从服务发现和 DNS 到工作负载选择、路由和负载均衡。然而,对这些功能的控制一直有限,工作负载选择是显著的例外。Gateway API 改变了这一局面,让你可以控制服务路由。这与 Istio 的 VirtualService 有一些重叠,因为两者都对流量路由有影响。以下是三种情况的简介:
Gateway API 与 Istio 的这种动态结合不仅精细化了服务网络,也巩固了 Istio 在 Kubernetes 生态系统中的地位。
在当前的实验阶段(v0.8.0 版本),服务网格的 Gateway API 引入了一种新的方法来配置 Kubernetes 中的服务网格支持。它直接将单个路由资源(如 HTTPRoute)与服务资源关联起来,简化了配置过程。
以下是一些关键点:
实验阶段:在 v0.8.0 版本中,服务网格的 Gateway API 仍处于实验阶段。建议不要在生产环境中使用。
服务与路由关联:在配置服务网格时,与使用 Gateway 和 GatewayClass 资源不同,单个路由资源直接与服务资源关联。
服务的前端和后端:服务的前端包括其名称和集群 IP,后端由其端点 IP 的集合组成。这种区分使得在网格内进行路由无需引入冗余资源。
路由附加到服务:将路由附加到服务上以将配置应用到指向该服务的任何流量。如果没有附加路由,流量会遵循网格的默认行为。
命名空间关系:
组合路由:在单个命名空间中的同一服务的多个路由,无论是生产者路由还是消费者路由,都将根据 Gateway API 路由合并规则进行合并。这意味着在同一命名空间中为多个消费者定义不同的消费者路由是不可能的。
请求流程:
请记住,在实验阶段,服务网格的 Gateway API 可能会有更多的变化,不建议在生产环境中使用。
但等等,还有更多!我们的旅程并没有结束 - 使用 API 的入口流量支持正快速向通用可用性 (GA) 进发,预计还会有更多动态的发展!
让我们进一步探讨这个版本中的其他增强功能。
Istio 团队一直在不断优化 ambient mesh,这是一种创新的部署模型,提供了一个替代传统 sidecar 方法的选择。如果你还没有探索 ambient,现在是深入了解介绍博客的好时机。
在这次更新中,我们强化了对ServiceEntry
、WorkloadEntry
、PeerAuthentication
以及 DNS 代理的支持。并且,修复了一些 bug,增强了可靠性,以确保无缝的体验。
请记住,ambient mesh 在这个版本中处于 alpha 阶段。Istio 社区热切期待你的反馈,以推动它向 Beta 阶段前进。
简单易用是关键,特别是在处理虚拟机和多集群设置的时候。在这个版本中,我们在WorkloadEntry
资源中使地址字段变为可选。这个看似小小的调整将大大简化你的工作流程。
你现在可以为你的 Istio 入口网关的 TLS 设置配置OPTIONAL_MUTUAL
,提供可选的客户端证书验证的灵活性。此外,你可以通过MeshConfig
微调你偏好的非 Istio mTLS 流量使用的密码套件。
有了这些更新,Istio 1.19 赋予你在管理你的服务网格时更大的控制、灵活性和安全性。
欢迎你探索这些增强功能,并与 Istio 社区分享你的体验。更多详细信息,请参考官方发布说明。
祝你网格愉快!
本博客最初在tetrate.io上发布。
最后更新于 2024/10/08