Kubernetes 上的服务网格技术大比较: Istio, Linkerd 和 Consul

云原生应用通常是由一组运行在容器中的分布式微服务架构起来的。目前越来越多的容器应用都是基于 Kubernetes 的，Kubernetes 已经成为了容器编排的事实标准。

大多数采用了微服务架构的公司对微服务架构的影响是没有完全理解的，其中之一就是为服务的延展。就像城市周围的郊区一样，部署的小服务数量在呈现几何增长。在我看来这也是微服务带来的灾难性问题之一。  微服务的大量增加对如何统一标准化管理服务带来了非常大的挑战，比如多个服务/版本之间的路由、验证和授权、加密，以及在Kubernetes集群内的负载均衡等。

服务网格就是来帮助解决这些问题的，甚至可以有更多功能。就像容器把应用程序从操作系统上抽象出来，服务网格的目标就是把如何处理进程间通信再抽象出来。

What is Service Mesh 什么是服务网格

虽然服务网格技术出现在Kubernetes之前，但是激增的构建在Kubernetes之上的微服务促使了人们对服务网格解决方案的越来越有兴趣。

理解微服务最关键的一点就是要理解微服务都是严重依赖网络的。

服务网格管理服务间的网络流量。其它管理方式需要大量人工、容易出错的工作，并且在长远支持来说这种工作是一种难以忍受的负担，而服务网格提供了一种非常优雅和可扩展的方式来管理。

一般情况下，服务网格层是在Kubernetes设施之上的，让服务间的网络通信安全可靠。

可以把服务网格想成一个路由和追踪服务，用来处理邮件中要运送的包裹：保存路由规则路线，并且动态的指挥流量和包裹的路径，以此来加速交付和保证接受。

服务网格可以通过可观测性，网络和安全策略来分隔应用程序的业务逻辑。通过服务网格可以链接微服务，让微服务更安全，并且可以更好的监控微服务。

1. 连接：通过服务网格服务可以发现其它服务，并且可以相互通信。它可以智能的路由控制使服务间的流量和API调用。同时也可以支持高级的不部署方式，比如蓝绿发布，金丝雀或者滚动升级，甚至更多。

2. 安全：服务网格可以让服务间进行安全通信。可以执行安全策略来允许或者拒绝通信，比如，可以配置一个策略来拒绝来自部署环境中的客户服务访问生产服务。

3. 监控：服务网格可以让分布式的微服务系统具有可观测性。服务网格通常集成开箱即用的监控和追踪工具（比如 Kubernetes 中的 Prometheus 和 Jaeger），这些工具可以发现并可视化服务、流量、API延迟和跟踪之间的依赖关系。

针对由分布式微服务组成的复杂云原生应用程序，这些关键功能为它的整个网络行为提供了操作控制和可观察性。

当你处理大型网站或者超大规模微服务系统的时候服务网格就很关键了（比如Netflix，Amazon）。但是如我们下面看到的，在你的系统还在发展的时候，现在已经有很多像框架一样的技术来支持未来的大规模应用了。

Service Mesh Options for Kubernetes:Kubernetes 下的服务网格选择

在 Kubernetes 生态系统中有 3 个领先的服务网格竞争者。这 3 个解决方案都是开源的。每个解决方案都有它的优势和不足，对于一个要开发和管理越来越多微服务的 DevOps 团队来说，采用