本文获得jameskelly.net授权翻译发表，转载需要注明来自公众号EAWorld。
作者：James Kelly
译者：月满西楼
原题：Are Service Meshes the Next-Gen SDN?
全文7500字，阅读约需要18分钟
2017年6月28日更新: 了解更多关于Service mesh、代理和Istio的精彩内容，敬请收听由谷歌Istio工程师们发布在SE Daily上的新播客[1]。
2017年6月26日更新: 获取Service mesh的重要背景信息(对很多人来说，这可能是个非常新的概念)，敬请收听来自Linkerd创始人在SE Daily上的播客[2]。
在微服务架构的新时代里，无论你是采用容器栈还是FAAS（functions-as-a-Service）服务栈，或是两者都在用，网络开始变得越来越重要，原因如下:
-
微服务应用程序组件通过网络相互解耦。他们通过远程过程调用(RPC)API实现了重新整合，这些API已经从RPC从CORBA、RMI等等这些以前使用SOAP和REST的web服务, 发展到如今的Apache Thrift[3]和更时髦的 gRPC[4]（这是一个Google开源的,基于http2的高性能、安全的RPC框架，是CNCF的新项目）。RPC已经存在了很长时间, 然而现在的网络实际上已经具备足够快的处理速度，可以把它作为通用的应用程序组件之间的通信手段，以使得单体应用可以被颠覆，这些单体应用的服务模块以前总是和API通信紧密捆绑在一起，这些API通常基于各类库的文件包，甚至包含大家可能还有印象的，更复杂难懂的IPC（进程间通信，Inter-Process Communication）。
-
每个微服务组件通过复制实例[5]来进行扩展。微服务的前端是个负载平衡器，它本身就是一个网络组件，但是除此之外，服务需要通过DNS和服务发现查找它们的依赖服务。
为了提升处理规模，提高可靠性，每个微服务实例通常都是应用程序状态和存储相解耦的。状态也被保存在网络上。例如，通过API将状态保存在对象存储、数据库、k/v存储、流队列或消息队列中。也有存储在带有 老旧文件系统的老旧磁盘的例子，但这些磁盘本身可能也是虚拟的网络挂载的磁盘分区。这些用来存储状态的可供调用的API和RPC本身其实也是微服务的系统，而用这种存储方式事实上也可能是最佳的磁盘利用方式。当然，这里面还包含了大量的分布式存储技巧，以应对任何请求，这些技巧通常也是通过网络来实现的。
希望我们可以在“为什么网络是微服务的一个关键”这一点上达成共识。如果您对此很熟悉，那么也许您已经对云原生的SDN解决方案和Service mesh多少有些了解。
Service mesh的概念和实现是相当新颖的。这个话题也获得了很多关注，因为它可以解决上面提到的网络层面面临的一些主要挑战(特别是第1和2点)，当然，Service mesh实际能处理的事情比这要多得多，特别是以下两种Service mesh:CNCF的官方新项目Linkerd和最近发布的Istio。
由于此前我已经写过关于一篇SDN用于容器栈的文章：用于Kubernetes 和 OpenShift容器管理平台的OpenContrail（OpenContrail for Kubernetes and OpenShift），在此就不作深入探讨了。同时，我也不打算对Service mesh做一个详细的介绍，只会在比较时略提一二。
在下文中我还会添加一些参考资料，并试着通过对比的方式来组织我的博客内容，这样你就可以跳过那些你不关心的技术细节，然后仔细 读一读那些对你来说关系重大的部分。
为了让内容更具趣味性，让我们先看一下Services mesh的一些情况和特性，并将它们与SDN解决方案进行比较，这个SDN解决方案主要指的是OpenContrail, 以便我们回答标题中提出的问题：Services mesh能否成为下一代SDN?
一、自动化SDN和Service Mesh
首先，让我们看一下在使用SDN和Service mesh所使用的各种上下文环境中，自动化的三个主要方面:可编程性、配置和安装。
可编程性（Programmability）
当谈及自动化时，可编程性显然是必须的。真正优秀的SDN是不受网络硬件限制的，许多SDN就像OpenContrail一样，提供了一个附带API[6]的逻辑上的集中控制层。上面所介绍的两种主要的Service mesh，Istio和 Linkerd也都是这么处理的，他们遵循类似于SDN架构模式，具备中心控制层和分布式的转发层代理。但也有所区别，虽然Istio有一个集中控制层API[7]，但Linkerd通过它的Namerd组件 提供一个API[8]来适应更加复杂的分布式环境。可能大多数人会觉得这两种Service mesh的gRPC API比OpenContrail 的RESTful API更现代化、更有优势，但事实上 OpenContrail 的RESTful API与Istio的静态原始（still-primordial）API功能相比，可以更好地实现扩展（built-out）和测试。
配置
除API以外，Service mesh与SDN更大的区别在于如何访问功能。 它引入了YAML来进行配置，并通过CLI将配置进行交付。我猜大多数人都会认为这是一个比SDN更具优势的地方(至少OpenContrail目前还没有这一特点)。就网络接口（web-based interface）而言，service mesh像其他许多SDN一样，确实提供了这些功能。 但要考虑这一点：OpenContrail的网络接口在经历5年的研发之后，虽然 已经变得相当复杂，但仍旧丝毫不过时，并且对企业应用比较友好。
展望“Network as code”的发展趋势，CLI和YAML在可编程和版本控制方面确实比OpenContrail 的API调用更容易操作。在OpenStack云计算管理平台项目环境中，OpenContrail可以用基于YAML格式的 Heat[9]模板配置，但是这与基于容器的K8s（Kubernetes的简写）和OpenShift容器集群管理系统没有太大关系。在K8s容器集群管理系统中，OpenContrail SDN配置被注释为K8s对象。它做了刻意的简化，所以只展示了OpenContrail功能的一小部分。通过K8s TPRs[10]、ConfigMaps或通过一些OpenContrail本身的注释器能完成哪些工作，还需拭目以待。
安装
Linkerd刚开始运行时，背后有Buoyant的整个团队做支撑，这意味着每位用户都可以得到相关技术支持，业界对这一点倒也是见仁见智。采用Kubernetes在 DaemonSet[11]的模型中进行部署，很容易就能上手。
Istio是最新发布的Service mesh，但它已经有了Helm charts，可以通过Kubernetes容器集群管理系统进行快速部署，感谢我们在Deis的伙伴们，比如@lachlanevenson[12]已经完成了一些精彩的演示视频（链接在文末）。另一方面，使用Istio则意味着把它的Envoy代理作为一个sidecar[13]捆绑到每个Kubernetes Pod中。这是一个额外的步骤，但是可以通过kube-inject[14]命令来实现，而且不会有其他不良影响。先不考虑Sidecar DaemonSet之间的对比[15]，他们之间的绑定正碰撞出魔力的火花，同时，这对理解后面的调试很重要。
再说说SDN，它们是完全不同的wrt部署。OpenContrail正在开发一种用于简单部署的初级版Helm chart，与此同时，社区还提供了一些Ansible playbook组件和其他类似的配置管理解决方案。
OpenContrail与Istio和Linkerd有一个共同点，它们都是基于容器进行部署的。但不同的是，每个节点上的OpenContrail转发代理都是一个用户空间组件和内核模块(基于DPDK或SmartNIC)。它们被容器化了，但是内核模块只是用于安装目的，用以引导insmod安装。内核模块这部分可能会让人觉得有点矛盾，内核模块明显地简化性能和与网络堆栈的集成，但是它所使用的资源不是基于容器的，因此没有资源方面的限制，所以资源管理与用户空间sidecar进程是不同的。无论如何，这与使用kube-proxy或任何基于IP tables的网络连接都是一样的，与OpenContrail的虚拟路由器（vRouter）作用对等。
二、SDN与Service meshs：
在DevOps方面的注意事项
在考虑到微服务架构时，我们一定要牢记其复杂性远不止此。有时还需要考虑DevOps的开发、测试、预发 和生产环节，以及持续集成、交付和反馈。让我们来看看其中的一些注意事项:
多租户/多环境
在共享集群中，代码不应该集中注意在诸如操作员或应用程序开发/测试环境这种运维环境上下文中。要实现这一点，我们需要隔离机制。虽然Kubernetes系统的Namespace（命名空间）和RBAC(Role-Based Access Control，基于角色的访问控制)对隔离机制很有帮助，但是仍然还需要做很多事情。下面我会快速回顾下对OpenContrail和Service mesh中路由方面的理解，以便更好地详细分析上下文（contexts）隔离的一些注意事项。
< background >
OpenContrail for K8s概述: overlay network是一种常见的SDN隔离方式。它允许我们在网络上创建彼此独立，带有不同封装标记的虚拟网络，并且通常也能在转发代理中创建。这是OpenContrail能实现的常见情况，不过OpenContrail也允许更高级别的命名空间，像一些域、租户和项目的封装程序[16]。
域和域之间彼此隔离，域内的项目间彼此隔离，项目中的虚拟网络间彼此隔离。这种结构层次很好地映射了租户和开发/测试/ 预发/生产环境，这样，我们就可以使用一个虚拟网络来隔离每项微服务。为了能有选择性地跨域和跨项目地连接网络，应该制定这样的策略并将其应用到需要连接的网络上，它选择指定方向、网络名称、端口和服务链来进行插入(例如，有状态的防火墙服务)。
在Kubernetes系统中创建这些域、项目和网络的方式是基于注释的。OpenContrail将namespace映射到它们自己的OpenContrail项目或虚拟网络中，因此微服务可以有选择性的在一个大的网络上相互联系(类似于默认的集群行为)。但这里会存在安全隐患，因此OpenContrail也可以强制执行ACL规则，并通过实现一个隔离的以安全为目标的微服务来使这些规则的创建自动化，实现这一微服务的方式，可以是基于K8s对象注解，也可以是实现一个执行OpenContrail安全组和规则的Kubernetes NetworkPolicy[17]对象。
在K8s部署、作业或服务等对象上的另一种代码注解则指定整个OpenContrail域、项目和虚拟网络。就我个人而言，我认为最好的方法是设计一个层次结构，来匹配DevOps团队和环境结构，这个环境结构可充分利用域、项目和网络分割的OpenContrail模型。不幸的是，与之相比 ，全局默认拒绝规则和日益增长的白名单更简单、也被更为频繁使用，尽管这些规则会让你的集群变成“瑞士奶酪”（可参考瑞士奶酪模型原理的相关资料）。我只能祝你在管理的过程中“玩得愉快”:/
SDN overlay是在第2，3，4层,也就是说当在节点上接收到数据包时，（以OpenContrail为例）虚拟路由器vRouter也将接收分配给它的数据包，并通过内部接口(VXLAN ID或MPLS LSP编号)来确定域/租户,项目和网络。基本上，这个编号标识了哪个路由表将用作内部目标地址的lookup context，然后(待定的ACL)数据包会按CNI[18]标准被传递给正确的容器/pod接口。
Service mesh背景:Istio的Envoy和Linkerd的模型之所以可作为每项微服务的基础，是因为在微服务的前端设置了一个应用层（layer-7 ）路由器和代理。所有的流量都在这个代理处被截获，并在节点之间传递。可以说，它也是在更高层级上的overlay。
从概念上讲，除了overlay协议通常是HTTP或HTTP2，及其附加的TLS，Istio Envoy和Linkerd的应用层overlay与SDN的overlay是相同的。在Linkerd的DaemonSet部署模式中，主机只有一个IP地址，Linkerd将代理所有的流量。它在概念上类似于SDN的vRouter，但后者只是在某些端口上处理HTTP流量，而不是处理所有的流量。流量路由和目标解析是由继承自Finagle的delegation tables (dtabs)格式完成的。在Linkerd或Istio Envoy(通常是sidecar)的Sidecar部署模型中，代理实际上处于与每个微服务相同的容器网络环境中，因为它位于相同的pod。在应用程序和网络之间存在一些IP tables技巧。在Istio Pilot(控制层)和Envoy(数据层)中，流量路由和目标解析主要基于Kubernetes的服务名称。
< /background >
在这个背景下，再来写一些关于多租户的含义。
需要注意的是，在SDN设置中，租户、环境和应用程序(网络)的classification发生在vRouter中。而在Service mesh代理中，需要一个CNI解决方案，以便最开始就将数据包引入到pod中。
在Linkerd中，是使用用包括租户、环境和服务Dtabs路由规则[19]。Dtabs似乎提供了一个很好的方法来解决这个问题，使其变得可管理。
在Istio Envoy较为常用的sidecar模式下,很可能流量流入的POD已经有一个与它相关联的K8s namespace（命名空间），因此我们可以在Istio规则[20]之外映射一个租户或环境,对于Envoy来说，只需要专注于解析一个容器的服务名称和端口。
看起来OpenContrail可以很好地匹配隔离团队的层次结构，并分隔出RBAC和路由上下文。Linkerd dtab也许更更灵活，能创建出用户想要的尽可能多的路由解释层，但需要一个更强大的RBAC，来允许在团队租户之间拆分dtabs，最终来保障安全性和协调性。Istio在隔离租户和环境方面则并没有起到太大的作用。也许这已经超出了它的能力范围，这也能理解，因为Envoy总是作为一个sidecar容器而存在，底层的多租户网络可以让流量进入sidecar的pod。
另一个观点是,虽然服务发现（service discovery）已经被添加到service mesh解决方案中,但它在SDN的运用中仍然相当重要,并且包括DNS的系统(OpenContrail)在多租户的方式下可以帮助管理命名解析，以及提供在用户划分的区间进行IP地址管理(如加入用户本身的IP地址)。这超出了Service mesh的范围，但对于多团队以及开发/测试/ 预发/生产环境来说，有一个相同的IP地址管理池和子网还是可取的。
部署和负载均衡
当提到部署和持续交付(CD)时，SDN的可编程特性很有帮助，但Service mesh有个更为明显的优势，因为其本身就是用持续交付(CD)的理念设计的。
通过SDN进行蓝绿部署[21]，浮动IP的功能很有用。基本上，我们可以切换到绿色版本(把虚拟IP浮动到新版本的微服务中)，然后一旦需要的话，又可以将其安全地返回到蓝色版本。而在持续交付或者把预发环境切换到非活动部署时，我们仍可以使用不同的浮动IP地址来访问它。OpenContrail可以处理叠加的浮动IP，让你想怎么玩就怎么玩。
Service mesh路由规则也能实现同样的功能，但是它是基于一个额外的HTTP层级的路由切换，来指向一个新的后端版本（代码示例[22]）。Service mesh更进一步允许的是流量累加（代码示例[23]），最开始，分配少量流量，最后是全部全部流量，这将有效地提供一个面向流量负载的金丝雀部署，这和Kubernetes滚动升级或者金丝雀部署策略[24]截然不同，Kubernetes的金丝雀策略是基于实例计数，依赖于实例间的负载均衡来进行流量分区操作。
说说负载平衡。默认情况下，微服务实例之间的负载均衡，是借助K8s kube-proxy控制器通过IP tables的编程来实现的。通过OpenContrail的vRouter，使用其自己的ECMP负载均衡和NAT，取代内核级IP tables的方式，在性能和规模上有一定的优势。
Service mesh也可以处理这样的负载均衡。但支持更广泛的功能，比如像EWMA[25]这方面的负载平衡方案，再比如在速度不理想的情况下，Service mesh也能从负载平衡池中踢掉一个实例。
当然，Service mesh也可以处理 HTTP前端入口的负载平衡。Linkerd和Istio整合了K8s Ingress作为入口控制器。虽然大多数的SDN似乎都没有这个功能，但是OpenContrail有一个基于haproxy（一个开源的TCP代理项目）的解决方案。不同之处在于，OpenContrail还没有支持SSL/TLS，但有一些替代方案，比如nginx，来实施纯粹软件定义的负载均衡。
可靠性工程
是的，我把SRE和持续响应归类在DevOps的类目下。在这一领域，Service mesh更具有应用程序感知性（application-aware），这也不意外，因为其本身在可靠性方面就做得更为深入。
当提到可靠优化和工程性能时，我们可以得出的一个观点是，EWMA和这种先进的负载平衡策略将有助于避免或抛出缓慢实例，从而改善尾延迟(tail latency)。再此可参考Buoyant公司的一篇关于性能的文章[26]，它比较直接地讨论了延迟方面的性能问题。Envoy 和Linkerd毕竟都是TCP代理，在网络环境下解压和重新打包TCP流极其缓慢(我个人可以证明这一点，我曾亲自参与过一个为了广告目的进行HTTP头部注入的项目)。无论如何，处理器已经发展得非常成熟，Envoy 和Linkerd也可能是目前速度最快的TCP代理。总是有一些谨慎的人执着于避免延迟增加，我认为上面引用的文章中所提到的试验会带给用户一些启发，尽管它们会带来更多的延迟和步骤，但因为它们同时也增加了智能的部分，两相权衡，反而使得整体的延迟速度提高了！
目前大家的共识是，Service mesh能够解决的问题多于它们引发的问题，比如延迟。你的具体情况是否也一样?正如一些人所说的，“这得看情况”。如同基于DPI的防火墙，这种类型的流量处理应用程序在给定的功能设置或负载下可能都会有很高的延迟和吞吐量，但是在开启某些特性或负载下，性能则会有很大的不同。这并不是一个公平的比较，但是SDN转发代理所做的轻量级无状态处理总是比这样的代理快得多，特别是在OpenContrail中，有一些智能NIC网卡供应商在硬件上实现了vRouter 。
另一个更需要关注的，关于可靠性的问题是安全性。当我想到TCP代理时，我马上会想到要防止DoS攻击，因为它们为跟踪每个会话创建了大量的状态。通过使用TLS，Service mesh很好地解决了这个问题。虽然Linkerd也可以支持这一点，但Istio的方法更容易，因为它有一个Istio Auth密钥管理控制器。这是非常重要的进步，不仅可以确保网络上的通信安全(这一点SDN也可以通过IPsec等方式做到)，还可以为每项微服务建立强大的基于身份的AAA认证。值得注意的是，这些代理可以将网络协议更改为可配置的任何设置，而不用管它是否从应用程序中初始化为这个协议。因此，可以将HTTP请求作为TLS内置的HTTP2发送到网络上。
最后说说融断机制。如果不对大量分析和应用程序跟踪信息进行解读，并将其反馈到SDN的API中，我不认为一个SDN解决方案可以很好地做到这点。即使从理论上讲可以实现，但作为一种内置功能[27]，Service mesh已经实现了这一点，可以很好处理故障，防止它们恶化演变。
测试和调试
这是一个很重要的话题，但实际上并没有一个特性级别的全面比较，所以我将对此进行单独讨论。
Services mesh为微服务网格中的内部通信提供了面向RPC的应用程序视图。通过跟踪应用程序中的通信路径，这些信息对于监控、运维可视化和调试过程都非常有用。Linkerd整合了Zipkin系统和一些其他工具来进行跟踪和度量，与某些特定语言的跟踪库不同，它可以在任何语言环境下工作。
Service mesh还支持基于HTTP Header操控的单一请求（per-request）路由来进行测试。此外，Istio还提供了故障注入来模拟应用程序中出现的错误。
SDN的解决方案则不同。与CNI供应商的其他选择相比，OpenContrail在这方面已经做得相当成熟。OpenContrail可以根据需要运行像Wireshark这样的数据包抓捕和嗅探器，它的综合分析引擎和可视化工具可以暴露流量记录和其他流量的统计数据。除了在更高网络层级上的调试之外，还有一些有意思的安全应用程序被用来审计ACL拒绝日志。最后，只要流量是在物理网络，而不是云平台上运行的，OpenContrail就可以告知其端到端的流量路径。以上这些都可能有助于调试，但是这类信息对面对面（vis-à-vis）的应用程序要间接得多，而且可能更适合于NetOps。
三、遗留系统和其他互联
Service mesh在很多方面看起来都不错，但要注意的一个问题是，它们是如何允许或阻止微服务连接到遗留服务或其他前端没有代理的服务。
如果在S3中存储状态或调用云服务，那么这是一个外部调用。如果要回调像Oracle数据库这样的遗留应用程序，也一样。如果调用的是另一个没有部署在Service mesh上的微服务的RPC(例如，它在虚拟机而不在容器中)，还是一样。如果微服务希望处理非TCP流量，那么也不会通过Service mesh来处理(例如，DNS是UDP流量，ping是ICMP)。
在运用Istio时，可以用一个服务别名来设置出口（egress）[28]连接，但是这可能需要对应用程序进行更改，因此直接的pass-thru可能是一个更简单的选项。同样，还有很多TCP流量的变体不是HTTP，也不直接支持基于HTTP的高级协议。常见的例子有ssh和邮件协议。
还有一个问题是，一旦CNI协议接纳了Service mesh，那么他将如何处理每个pod的多个IP和多个网络接口。
当然，你的应用中肯定还会有一些不太适合这种网格的通信。在这些情况下，你不仅需要规划如何允许这种通信，还需要考虑如何安全地进行，这时可能需要使用一个底层的SDN解决方案，比如像OpenContrail这种可以适配OpenStack、VMware和裸金属（metal）设施的解决方案。
四、你怎么看
回到标题中提到的问题:Service mesh能否成为下一代SDN?
一方面:是的!因为他们通过在微服务之间实现micro-segmentation和RPC的安全性，从而吸收了一些SDN所具有的价值。Service mesh可以通过改进的基于TLS的安全和对每个微服务的身份分配来实现这一点。此外，Service mesh还添加了高级应用程序感知的负载均衡和故障处理，如果没有应用程序分析和代码重构，这对于SDN就很难实现。
另一方面:不能！因为Service mesh位于CNI和容器连接的顶层。他们处在SDN的上层，所以仍然需要一个坚实的基础。此外，大多数团队在运用micro-segmentation和多租户的SDN解决方案时，都需要多重安全隔离，不允许有任何性能损耗。除了容器，SDN解决方案还可以跨集群、堆栈和运行时进行连接，并能满足对延迟的各种需求。
但不管怎样，Service mesh都是一款全新的、酷炫的网络玩具。它们提供的价值远远超出了它们所包含的网络和安全价值，我想我们很快就会看到它们在每一个微服务架构和堆栈中的运用。
五、更多的问题
希望这篇不会完结的博客中的内容，能够引发你对SDN或Service mesh的思考 ，希望你能分享你的观点或疑问。技术预测的反面模式(Anti-pattern)是认为我们已经做到了，所以在此又提出了一些更开放的问题:
我们是否应该把service mesh和Linkerd融合在Istio框架中，作为Envoy的另一种选择?如果应该这样,为什么?
我们应该把OpenContrail和Service mesh融合在一起吗，具体应该怎样做?
六、关于Service mesh的学习资源
Istio博客:https://istio.io/blog/
Buoyant博客:https://blog.buoyant.io/
Istio和 Kubernetes演示视频（来自Lachie）:https://www.youtube.com/watch?v=ePwd5bK2Cuo&list=PLbj_Bz58yLCw09JYfG2xbFMi5-jN89LfB
Istio Service Mesh 播客: https://softwareengineeringdaily.com/2017/06/27/istio-service-mesh-with-varun-talwar-and-louis-ryan/
Linkerd Service Mesh播客: https://softwareengineeringdaily.com/2017/06/26/service-mesh-with-william-morgan/
关于Linkerd 的Scaling Twitter 播客: https://softwareengineeringdaily.com/2016/06/22/scaling-twitter-buoyant-ios-william-morgan/
关于Envoy 的服务代理（Service Proxying）播客: https://softwareengineeringdaily.com/2017/02/14/service-proxying-with-matt-klein/
Envoy 和 Linkerd间的对比: https://lyft.github.io/envoy/docs/intro/comparison.html#id7
原文链接：http://jameskelly.net/blog/2017/6/19/are-service-meshes-the-next-gen-sdn
文中的注解如下：
[1] https://softwareengineeringdaily.com/2017/06/27/istio-service-mesh-with-varun-talwar-and-louis-ryan/
[2] https://softwareengineeringdaily.com/2017/06/26/service-mesh-with-william-morgan/
[3] https://thrift.apache.org/
[4] https://grpc.io/
[5] https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
[6] http://www.opencontrail.org/documentation/api/r4.0/
[7] https://istio.io/docs/concepts/what-is-istio/overview.html#architecture
[8] https://buoyant.io/2017/05/24/a-service-mesh-for-kubernetes-part-x-the-service-mesh-api/
[9] https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#hot-spec
[10] https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-third-party-resource/
[11] https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/
[12] https://twitter.com/LachlanEvenson
[13] http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns.html
[14] https://istio.io/docs/tasks/integrating-services-into-istio.html
[15] https://linkerd.io/getting-started/k8s/
[16] http://www.opencontrail.org/opencontrail-architecture-documentation/#section3_2
[17] https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy/
[18] https://github.com/containernetworking/cni
[19] https://linkerd.io/advanced/routing/
[20] https://istio.io/docs/concepts/traffic-management/rules-configuration.html
[21] https://martinfowler.com/bliki/BlueGreenDeployment.html
[22] https://istio.io/docs/concepts/traffic-management/rules-configuration.html#split-traffic-between-service-versions
[23] https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/
[24] https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments
[25] https://buoyant.io/2016/03/16/beyond-round-robin-load-balancing-for-latency/
[26] https://buoyant.io/2017/01/31/making-things-faster-by-adding-more-steps/
[27] https://istio.io/docs/concepts/traffic-management/handling-failures.html
[28] https://istio.io/docs/tasks/egress.html
普元云计算微课堂持续进行中......
阅读原文：http://mp.weixin.qq.com/s?timestamp=1513760857&src=3&ver=1&signature=Mg91eJK1w*tTtc5VHYW7YsS1ZmPMnCBwQGyiocaMD6euCJZGuvpCNyDPyPmGjUvZf-4uSQwwLzuYGEBZePgn22wTysn5MkHDzjZXcwcGEpadvVjm-G2T3ffI25cSn1PzBl97x5QkOhkh*K8CyZwmib2hCIOJL9o0keI-gTRYF1Y=&devicetype=Windows-QQBrowser&version=61030004&pass_ticket=qMx7ntinAtmqhVn+C23mCuwc9ZRyUp20kIusGgbFLi0=&uin=MTc1MDA1NjU1&ascene=1
