基于 Kubernetes 的 Service Mesh 简介 | 云原生社区（中国）

点击查看目录

本文为翻译文章，点击查看原文。

编者按

文章介绍了基于 Kubernetes 的服务网格，简要的说明了服务网格的作用，sidecar 的作用以及服务网格两个重要实现：Istio 与 Linkerd 的起源和结构，鼓励大家上手尝试。

ALEN KOMLJEN 2018 年 1 月 28 日，阅读时间 4 分钟

几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是，嘿，难道 Kubernetes 服务和ingress还不够么？你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些 API 只对内部网络开放，然而对于现在流行的应用来说，这并不够。API 通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做 API 版本化，做金丝雀部署，观察并记录每一个请求。这就引入了服务网格。无论你用Linkerd或是Istio，原理上都是一样的。

为什么要用服务网格？

服务网格并不是和 Kubernetes 一起出现。然而，因为有 Kubernetes，服务网格更容易被引入到你的环境中。有两个逻辑组件组成了服务网格。我们已经有了 pod 用于承载各个容器。Sidecar 是另一个绝好的例子用于扩展和加强 pod 里面的主要容器。在服务网格语境里，sidecar 是服务代理或者数据平面。

服务网格是云原生的核心组件

为了更好的理解服务网格，你需要理解代理和反向代理这两个术语。代理，用一句话说，用于接收流量并中转到其它地方。反向代理，从各个地方接收流量并转交给各个服务。这种情况下，所有的客户只和一个代理实例交流。把数据平面想象为一个反向代理。Ingress 也是 Kubernetes 里面用于暴露服务的反向代理。Ingress 可以中止 SSL，提供基于名称的路由，并且它主要就干这个事情。对于 Kubernetes 服务也是一样。如果你需要更复杂的路由该怎么做呢？

下面列举一些其它服务网格可以做的事情：

负载均衡
精细流量策略
服务发现
服务监控
追踪
路由
服务与服务的安全通信

不仅有 sidecar 代理，所有的服务网格解决方案还包含控制器，用于定义 sidecar 容器应该如何工作。服务网格的控制平面是一个集中的、管理所有的服务网格和服务代理的地方。这个控制面板记录网络信息，所以它也是一个网络监控工具。

所以，为什么要用服务网格？答案很简单，你可以做上面的任何事情并且不需要修改代码。它能够节省时间与金钱。不仅如此，更重要的是，你不能跳过测试，因为它对于初学者太复杂。甚至你可以通过Istio 故障注入模拟不同的场景，来测试系统对于失败的反应。

Linkerd2 与 Istio

在一开始，我提到过两个在 Kubernetes 上创建服务网格的著名的解决方案。未来也许还会有其它更多的解决方案。每一个产品都试图用自己的方式解决问题，相互之间肯定会有重复的地方。

Buoyant，这家公司创造了 Linkerd，同时还创造了 Conduit 服务。近期，Conduit 被合并到 Linkerd 项目，称作Linkerd2。buoyant 团队把 Linkerd 服务网格变成了一个更加通用的解决方案。它用 Java 编写，这意味着它很重。每一个 pod 会有一个或更多的容器，一个 sidecar。Linkerd2设计应用于 Kubernetes。它的开发语言包含 Go-控制平面，和 Rust-一个原生的服务代理，超级轻量、快速并安全。你可以定义重试和超时，定义编排规则，以及加密（TLS），同时还支持根据策略通过或拒绝请求。不仅如此，它还有一个很漂亮的控制台：

如果你喜欢控制台的话也可以用linkerdCLI。

Linkerd 的入门向导非常不错，你可以试一试。如果想学习更多，可以看看它的官方文档。

Istio当前支持 Kubernetes 和Nomad，将来会添加更多的功能。Istio 是一个多平台解决方案。它可以做微服务流量管理，策略应用以及聚合采样信息。Istio 也是 Go 语言编写的轻量应用，但不同于 Linkerd2，它使用Envoy来做服务代理。下图说明 Istio 中各个部分是如何组合工作的：