多年来,Istio 一直提供一种可选方案来部署 “Egress Gateway[1]”,这是一种功能强大的机制,可将出站流量经由一个 Gateway 统一转发,以便对其实施各类策略,包括授权、审计、可观测性等等。 尽管功能强大,但长期以来,设置 egress gateway 一直相当复杂。即便只是最基本的场景:将来自特定域名的流量通过 egress gateway 转发,都需要先后配置 5 个不同的 Istio 对象(参见 官方文档[2]),更不用说后续还要为流量添加各种高级策略了。 凭借 Istio 的 Ambient 模式与 Gloo Mesh,现在配置 egress gateway 的过程变得更加轻松,同时还能为网格中的流量提供更优的功能与管理。让我们在这篇博客中深入探讨一下。
Istio 依赖 Kubernetes 来进行服务发现,这通常意味着必须在 Kubernetes 集群中部署微服务并使用 Kubernetes 服务发现。然而,很多现有的微服务项目还在使用如 Consul、Eureka 这样的第三方服务注册表,本文将探讨如何将这些现有的微服务的注册表与 Istio 集成。
本文介绍了如何在 Istio 中使用头部信息进行路由,而无需修改应用程序内部。通过使用 Istio 的路由功能和头部匹配,可以实现基于头部信息的请求路由,同时展示了如何使用 delegate 功能和 sourceLabels 特性。
本博文解析了在 Istio 服务网格中服务端获取客户端源 IP 的挑战,并提供了解决方案。将探讨以下问题: • 数据包传输中源 IP 丢失的原因; • 如何确定客户端源 IP; • 在南北向和东西向请求中传递源 IP 的策略; • 针对 HTTP 和 TCP 协议的处理方法。
本文讨论我们如何在工作负载中扩展 Istio Sidecar,以及如何考虑 Sidecar 资源与应用程序紧密耦合的关系。 目前有很多关于 Istio 新的 Ambient Mesh[2] 的讨论。这种部署服务网格的新方法放弃了 Sidecar,而采用了两个新组件,ztunnel,一个用于处理核心 L4 网络问题的每节点组件,以及(如果需要)waypoint proxy 来处理 L7 问题。
本文介绍了在 Kubernetes 和 Istio 中使用 gRPC 负载均衡的行为。首先,通过创建命名空间、部署资源和配置文件来准备环境。然后,介绍了没有 Istio 的情况下,gRPC 服务的负载均衡行为。接下来,介绍了如何使用 Istio 创建虚拟服务和目标规则来实现负载均衡。还讨论了 ConnectionPoolSetting 对负载均衡行为的影响。最后,介绍了如何通过入口网关访问 gRPC 服务,并提供了验证步骤。