在 Intenseye，我们 follow(跟随) trends(趋势) & hype(最被炒作) 的技术，并在使用时应用最佳实践。我们在用 Scala、Go、Python 等编写的 Kubernetes 上运行了数百个 pod，其中大多数使用 gRPC。
gRPC 是一种现代开源高性能远程过程调用 (RPC) 框架，它使用 HTTP/2 进行传输。HTTP/2 支持通过单个 TCP 连接发出多个请求以减少往返次数。这就是问题出现的地方；负载均衡。建立连接后，所有请求都将固定到单个目标 Pod。因此，我们不会有平衡的负载。我们需要一个 L7 感知负载均衡器，而不是 L4。稍后您可以从这里阅读问题的详细信息。
https://linkerd.io/2018/11/14/grpc-load-balancing-on-kubernetes-without-tears
我们正在为另一个问题寻求解决方案；微服务之间的安全传输。我们有数十个组件，总共运行数百个 Pod。在它们之间一一配置 TLS 令人生畏，而且会很耗时。
我们还需要一个监控系统和来自所有这些组件和微服务的流量指标(traffic metrics)。我们想观察成功/失败(success/failure)率、Pod 的 RPS、谁与谁交谈的频率等。
我们有这三个问题的单一解决方案：Service Mesh
什么是 Service Mesh？
服务网格是一种工具，通过在平台层而不是应用程序层插入这些功能，为应用程序添加可观察性(
observability)、安全性(security)和可靠性(reliability)功能。(servicemesh.es)
服务网格通常作为与应用程序代码一起部署的一组可扩展的网络代理来实现；一种称为边车的模式。这些代理处理微服务之间的通信，并允许控制流量并获得整个系统的洞察力。Service Mesh 提供了很棒的功能，例如流量指标(traffic metrics)、熔断(circuit breaking)、mTLS、流量拆分(traffic split)、重试和超时(retry & timeout)、A/B 路由(routing)等。
source: servicemesh.es
我们开始挖掘服务网格的细节并评估对我们很重要的功能，我们如何从中受益等。由于服务网格会影响延迟和资源消耗，因此也必须衡量这些缺点。由于我们有 500 多个 Pod，因此资源成本将是 500 x sidecar。另外，我们在与时间赛跑，所以延迟应该是最小的。
经过一些研究和 PoC，我们决定在 Istio、Consul 和 Linkerd2 之间使用 Linkerd2。我必须说，servicemesh.es 帮助我们获得了有关服务网格的知识并比较了它们之间的功能。
除了我们正在寻求的功能之外，与 Istio 和 Consul 相比，我们选择 Linkerd2 有 3 个原因。（L7 LB、mTLS、traffic metrics 等）：
- 轻量级（低
CPU和内存消耗） - 低延迟
- 延迟感知
LB
Istio 有很多不错的功能（感谢 Envoy 代理），但我们并不需要所有这些功能。与 Linkerd2 相比，它的 sidecar 代理 CPU 和内存消耗也很高。Consul 使用相同的 sidecar 代理，因此我们也将其删除。这里详细解释了为什么 Linkerd2 使用它自己的代理而不是 Envoy。另外，Linkerd2 非常好用。Istio 的文档实在太多了。
https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/
Linkerd和“Cardi B”押韵。 “d”要分开发音，如“Linker-DEE”。 https://linkerd.io/faq/index.html#how-do-i-pronounce-linkerd
解决方案
问题 1：gRPC 负载平衡
without mesh / with mesh
正如您在图中所见，有些 pods 像替罪羊，有些像树懒。网格后，一切都很好。
问题 2：mTLS
感谢 Linkerd2 的 mTLS 功能，我们像 Thanos(灭霸) 一样，像弹指一样保护了微服务之间的内部通信。 Linkerd2 每 24 小时自动轮换一次证书。您也可以使用 cert-manager 来轮换颁发者证书和私钥。
问题 3：流量监控
Linkerd2 与 Prometheus 和 Grafana 捆绑在一起，但您可以自带实例并通过官方文档对其进行配置。我们遵循文档并开始使用我们现有的实例。现在我们从每个网格化的 pod 中获得了很好的指标，并且我们对集群有了更好的可观察性。
结论
感谢 Linkerd2，我们解决了我们的问题，从此过上了幸福的生活。 文档非常清晰，入门页面很容易理解（ 他们有演示应用程序。）当然，并非一切都是光明的。我们在网格划分 pod 时或网格后遇到的问题很少，但我们也解决了这些问题。甚至我们在 GitHub 上打开了一个问题并得到了帮助。
所以这篇文章是我们服务网格之旅的第一部分，它是关于“什么是服务网格以及我们为什么选择 Linkerd2？” 在第二部分，我们将讨论我们面临的问题以及我们如何解决这些问题。
References
- servicemesh
- https://servicemesh.es
- linkerd
- https://linkerd.io
- Service Mesh w/Linkerd2 | pt. 1
- https://blog.intenseye.com/service-mesh-with-linkerd2-part-1
