Kubernetes 和 Service Mesh 负载均衡不一致
Kubernetes 通过其 kube-proxy 支持 Pod 负载平衡和会话关联。 Kubernetes 的 kube-proxy 本质上是一个 L4 负载均衡器，因此我们不能依赖它来负载均衡 L7 传输，例如多个 gRPC 实时连接或基于 http-headers、cookie 等的负载均衡。
Service Mesh 实现如 istio 可以在 L7 级别处理这些模式，包括 gRPC。但我一直认为 Service Mesh 只是 Kubernetes 之上的另一层，具有附加功能（加密流量、蓝/绿部署等）。例如，我的假设始终是 Kubernetes 应用程序应该能够在没有 Mesh（例如用于开发/测试）或启用 Mesh 的普通 Kubernetes 上工作。在 L7 上添加这种高级流量管理打破了这一假设。我将无法再在普通 Kubernetes 上工作，我将依赖于 Istio dataplane（Envoy）的特定实现。
请告诉我我的假设是否正确或为什么不正确？互联网上关于这种类型的关注点分离的信息并不多。
Kubernetes has a support of Pod load-balancing, session affinity through its kube-proxy. Kubernetes’ kube-proxy is essentially an L4 load balancer so we cannot rely on it to load balance L7-transport, e.g. muliple gRPC live connections or load-balancing based on http-headers, cookies, etc.
Service Mesh implementation like e.g. istio can handle these patterns on L7-level including gRPC. But I always thought that Service Mesh is just another layer on top of Kubernetes with additional capabilities(encrypted traffic, blue/green deployments/etc). E.g. My assumption always was that Kubernetes applications should be able to work on both vanilla Kubernetes without Mesh (e.g. for development/testing) or with a Mesh on. Adding this advanced traffic management on L7 breaks this assumption. I won't be able to work on a vanilla Kubernetes anymore, I will be tied to a specific implementation of Istio dataplane(Envoy).
Please let know if my assumption is correct or why not? There's not much information about this type of separation of concerns on this internet.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先请允许我参考一下你的以下发言：
我对此有不同的看法，服务网格对应用程序是透明的，因此它们不会破坏其中的任何内容，而只是免费添加额外的（网络、安全、监控）功能（好吧，配置相当复杂）从网格操作员的角度来看）。像 Istio 这样的服务网格不需要占用所有 K8S 命名空间，因此您仍然可以在集群中拥有混合类型的工作负载（带或不带代理）。如果我们谈论 Istio，为了实现它们之间的完全互操作性（混合工作负载），您可以将其两个功能组合在一起：
或者，您可以编写自己的自定义 tcp_proxy EnvoyFilter 以使用 Envoy 作为 L4 网络代理。
参考文献：
https://istio.io/latest/docs/reference /config/networking/envoy-filter/
https://istio.io/latest/docs/concepts/security/#对等身份验证
https://istio.io/latest/docs/ops /配置/流量管理/协议选择/
Let me refer first to the following statement of yours:
I have different view at that, Service Meshes are transparent to the application, so they don't break anything in them, but just add an extra (network, security, monitoring) functions at no cost (ok, the cost it quite complex configuration from Mesh operator perspective). The Service Mesh like Istio doesn't need to occupy all K8S namespaces, so you can still have mixed type of workloads in your cluster (with and w/o proxies). If we speak about Istio, to enable full interoperatbility between them (mixed workloads) you may combine two its features together:
Alternatively you can write your own custom tcp_proxy EnvoyFilter to use Envoy as a L4 network proxy.
References:
https://istio.io/latest/docs/reference/config/networking/envoy-filter/
https://istio.io/latest/docs/concepts/security/#peer-authentication
https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/