2

Kubernetes 通过其kube-proxy. Kubernetes 的 kube-proxy 本质上是一个 L4 负载均衡器，因此我们不能依赖它来负载均衡 L7-transport，例如多个 gRPC 实时连接或基于 http-headers、cookie 等的负载均衡。

像istio这样的服务网格实现可以在 L7 级别处理这些模式，包括 gRPC。但我一直认为 Service Mesh 只是 Kubernetes 之上的另一层，具有额外的功能（加密流量、蓝/绿部署等）。例如，我的假设始终是 Kubernetes 应用程序应该能够在没有 Mesh（例如用于开发/测试）或打开 Mesh 的情况下在 vanilla Kubernetes 上工作。在 L7 上添加这种高级流量管理打破了这一假设。我将无法再在普通 Kubernetes 上工作，我将被绑定到 Istio 数据平面（Envoy）的特定实现。

请告诉我我的假设是否正确或为什么不正确？在这个互联网上没有太多关于这种类型的关注点分离的信息。

4

1 回答 1

1

首先让我参考您的以下陈述：

我的假设始终是 Kubernetes 应用程序应该能够在没有 Mesh（例如用于开发/测试）或打开 Mesh 的情况下在 vanilla Kubernetes 上工作。在 L7 上添加这种高级流量管理打破了这一假设。

我对此有不同的看法，Service Mesh 对应用程序是透明的，因此它们不会破坏其中的任何内容，而只是免费添加额外的（网络、安全、监控）功能（好吧，代价是相当复杂的配置从网格操作员的角度来看）。像 Istio 这样的 Service Mesh 不需要占用所有 K8S 命名空间，因此您仍然可以在集群中拥有混合类型的工作负载（使用和不使用代理）。如果我们谈论 Istio，为了实现它们之间的完全互操作性（混合工作负载），您可以将它的两个特性结合在一起：

  • 对等身份验证设置为 PERMISSIVE，以便没有边车（代理）的工作负载可以接受双向 TLS 和纯文本流量。
  • 手动协议选择，例如，如果您更喜欢您的应用程序使用原始 TCP 而不是 Envoy 本身确定的应用程序协议（例如 http） - 以避免代理为拦截的请求注入额外的装饰。

或者，您可以编写自己的自定义 tcp_proxy EnvoyFilter 以将 Envoy 用作 L4 网络代理。

参考：

https://istio.io/latest/docs/reference/config/networking/envoy-filter/ https://istio.io/latest/docs/concepts/security/#peer-authentication https://istio.io/最新的/docs/ops/configuration/traffic-management/protocol-selection/

于 2022-02-24T08:37:39.927 回答