为何Kubernetes自然适合微服务？

最近在反思，为何在支撑容器平台和微服务的竞争中，Kubernetes会取得最终的胜出。由于在不少角度来说三大容器平台从功能角度来讲，最后简直是一摸同样，具体的比较能够参考本人前面的两篇文章。

《Docker, Kubernetes, DCOS 不谈信仰谈技术》

《容器平台选型的十大模式：Docker、DC/OS、K8S谁与当先？》

通过一段时间的思索，并采访了从早期就开始实践Kubernetes的网易云架构师们，从而有了今天的分享。

1、从企业上云的三大架构看容器平台的三种视角

一切都从企业上云的三大架构开始。

如图所示，企业上的三大架构为IT架构，应用架构和数据架构，在不一样的公司，不一样的人，不一样的角色，关注的重点不一样。

对于大部分的企业来说，上云的诉求是从IT部门发起的，发起人每每是运维部门，他们关注计算，网络，存储，试图经过云计算服务来减轻CAPEX和OPEX。

有的公司有ToC的业务，于是累积了大量的用户数据，公司的运营须要经过这部分数据进行大数据分析和数字化运营，于是在这些企业里面每每还须要关注数据架构。

从事互联网应用的企业，每每首先关注的是应用架构，是否可以知足终端客户的需求，带给客户良好的用户体验，业务量每每会在短时间内出现爆炸式的增加，于是关注高并发应用架构，并但愿这个架构能够快速迭代，从而抢占风口。

在容器出现以前，这三种架构每每经过虚拟机云平台的方式解决。 当容器出现以后，容器的各类良好的特性让人眼前一亮，他的轻量级、封装、标准、易迁移、易交付的特性，使得容器技术迅速被普遍使用。

然而一千我的心中有一千个哈姆雷特，因为原来工做的关系，三类角色分别从自身的角度看到了容器的优点给本身带来的便捷。

对于原来在机房里面管计算、网络、存储的IT运维工程师来说，容器更像是一种轻量级的运维模式，在他们看来，容器和虚拟机的最大的区别就是轻量级，启动速度快，他们每每引觉得豪的推出虚拟机模式的容器。

对于数据架构来说，他们天天都在执行各类各样的数据计算任务，容器相对于原来的JVM，是一种隔离性较好，资源利用率高的任务执行模式。

从应用架构的角度出发，容器是微服务的交付形式，容器不只仅是作部署的，而是作交付的，CI/CD中的D的。

因此这三种视角的人，在使用容器和选择容器平台时方法会不同。

2、Kubernetes才是微服务和DevOps的桥梁

Swarm：IT运维工程师

从IT运维工程师的角度来看：容器主要是轻量级、启动快。并且自动重启，自动关联。弹性伸缩的技术，使得IT运维工程师彷佛不用再加班。

Swarm的设计显然更加符合传统IT工程师的管理模式。

他们但愿可以清晰地看到容器在不一样机器的分布和状态，能够根据须要很方便地SSH到一个容器里面去查看状况。

容器最好可以原地重启，而非随机调度一个新的容器，这样原来在容器里面安装的一切都是有的。

能够很方便的将某个运行的容器打一个镜像，而非从Dockerfile开始，这样之后启动就能够复用在这个容器里面手动作的100项工做。

容器平台的集成性要好，用这个平台原本是为了简化运维的，若是容器平台自己就很复杂，像Kubernetes这种自己就这么多进程，还须要考虑它的高可用和运维成本，这个不划算，一点都没有比原来省事，并且成本还提升了。

最好薄薄得一层，像一个云管理平台同样，只不过更加方便作跨云管理，毕竟容器镜像很容易跨云迁移。

Swarm的使用方式比较让IT工程师以熟悉的味道，其实OpenStack所作的事情它都能作，速度还快。

Swarm的问题

然而容器做为轻量级虚拟机，暴露出去给客户使用，不管是外部客户，仍是公司内的开发，而非IT人员本身使用的时候，他们觉得和虚拟机同样，可是发现了不同的部分，就会不少的抱怨。

例如自修复功能，重启以后，原来SSH进去手动安装的软件不见了，甚至放在硬盘上的文件也不见了，并且应用没有放在Entrypoint里面自动启动，自修复以后进程没有跑起来，还须要手动进去启动进程，客户会抱怨你这个自修复功能有啥用？

例若有的用户会ps一下，发现有个进程他不认识，因而直接kill掉了，结果是Entrypoint的进程，整个容器直接就挂了，客户抱怨大家的容器太不稳定，总是挂。

容器自动调度的时候，IP是不保持的，因此每每重启原来的IP就没了，不少用户会提需求，这个能不能保持啊，原来配置文件里面都配置的这个IP的，挂了重启就变了，这个怎么用啊，还不如用虚拟机，至少没那么容易挂。

容器的系统盘，也即操做系统的那个盘每每大小是固定的，虽然前期能够配置，后期很难改变，并且没办法每一个用户能够选择系统盘的大小。有的用户会抱怨，咱们原来原本就不少东西直接放在系统盘的，这个都不能调整，叫什么云计算的弹性啊。

若是给客户说容器挂载数据盘，容器都启动起来了，有的客户想像云主机同样，再挂载一个盘，容器比较难作到，也会被客户骂。

若是容器的使用者不知道他们在用容器，当虚拟机来用，他们会以为很难用，这个平台一点都很差。

Swarm上手虽然相对比较容易，可是当出现问题的时候，做为运维容器平台的人，会发现问题比较难解决。

Swarm内置的功能太多，都耦合在了一块儿，一旦出现错误，不容易debug。若是当前的功能不能知足需求，很难定制化。不少功能都是耦合在Manager里面的，对Manager的操做和重启影响面太大。

Mesos：数据运维工程师

从大数据平台运维的角度来说，如何更快的调度大数据处理任务，在有限的时间和空间里面，更快的跑更多的任务，是一个很是重要的要素。

因此当咱们评估大数据平台牛不牛的时候，每每以单位时间内跑的任务数目以及可以处理的数据量来衡量。

从数据运维的角度来说，Mesos是一个很好的调度器，既然可以跑任务，也就可以跑容器，Spark和Mesos自然的集成，有了容器以后，能够用更加细粒度的任务执行方式。

在没有细粒度的任务调度以前，任务的执行过程是这样的。任务的执行须要Master的节点来管理整个任务的执行过程，须要Worker节点来执行一个个子任务。在整个总任务的一开始，就分配好Master和全部的Work所占用的资源，将环境配置好，等在那里执行子任务，没有子任务执行的时候，这个环境的资源都是预留在那里的，显然不是每一个Work老是所有跑满的，存在不少的资源浪费。

在细粒度的模式下，在整个总任务开始的时候，只会为Master分配好资源，不给Worker分配任何的资源，当须要执行一个子任务的时候，Master才临时向Mesos申请资源，环境没有准备好怎么办？好在有Docker，启动一个Docker，环境就都有了，在里面跑子任务。在没有任务的时候，全部的节点上的资源都是可被其余任务使用的，大大提高了资源利用效率。

这是Mesos的最大的优点，在Mesos的论文中，最重要阐述的就是资源利用率的提高，而Mesos的双层调度算法是核心。

原来大数据运维工程师出身的，会比较容易选择Mesos做为容器管理平台。只不过原来是跑短任务，加上marathon就能跑长任务。可是后来Spark将细粒度的模式deprecated掉了，由于效率仍是比较差。

Mesos的问题

调度在大数据领域是核心中的核心，在容器平台中是重要的，可是不是所有。因此容器还须要编排，须要各类外围组件，让容器跑起来运行长任务，而且相互访问。Marathon只是万里长征的第一步。

因此早期用Marathon + Mesos的厂商，可能是裸用Marathon和Mesos的，因为周边不全，于是要作各类的封装，各家不一样。你们有兴趣能够到社区上去看裸用Marathon和Mesos的厂商，各有各的负载均衡方案，各有各的服务发现方案。

因此后来有了DCOS，也就是在Marathon和Mesos以外，加了大量的周边组件，补充一个容器平台应有的功能，可是很惋惜，不少厂商都本身定制过了，仍是裸用Marathon和Mesos的比较多。

并且Mesos虽然调度牛，可是只解决一部分调度，另外一部分靠用户本身写framework以及里面的调度，有时候还须要开发Executor，这个开发起来仍是很复杂的，学习成本也比较高。

虽而后来的DCOS功能也比较全了，可是感受没有如Kubernetes同样使用统一的语言，而是采起大杂烩的方式。在DCOS的整个生态中，Marathon是Scala写的，Mesos是C++写的，Admin Router是Nginx+lua，Mesos-DNS是Go，Marathon-lb是Python，Minuteman是Erlang，这样太复杂了吧，林林总总，出现了Bug的话，比较难本身修复。

Kubernetes

而Kubernetes不一样，初看Kubernetes的人以为他是个奇葩所在，容器还没建立出来，概念先来一大堆，文档先读一大把，编排文件也复杂，组件也多，让不少人望而却步。我就想建立一个容器玩玩，怎么这么多的前置条件。若是你将Kubernetes的概念放在界面上，让客户去建立容器，必定会被客户骂。

在开发人员角度，使用Kubernetes绝对不是像使用虚拟机同样，开发除了写代码，作构建，作测试，还须要知道本身的应用是跑在容器上的，而不是当甩手掌柜。开发人员须要知道，容器是和原来的部署方式不同的存在，你须要区分有状态和无状态，容器挂了起来，就会按照镜像还原了。开发人员须要写Dockerfile，须要关心环境的交付，须要了解太多原来不了解的东西。实话实说，一点都不方便。

在运维人员角度，使用Kubernetes也绝对不是像运维虚拟机同样，我交付出来了环境，应用之间互相怎么调用，我才无论，我就管网络通不通。在运维眼中作了过多他不应关心的事情，例如服务的发现，配置中心，熔断降级，这都应该是代码层面关心的事情，应该是SpringCloud和Dubbo关心的事情，为何要到容器平台层来关心这个。

Kubernetes + Docker，倒是Dev和Ops融合的一个桥梁。

Docker是微服务的交付工具，微服务以后，服务太多了，单靠运维根本管不过来，并且很容易出错，这就须要研发开始关心环境交付这件事情。例如配置改了什么，建立了哪些目录，如何配置权限，只有开发最清楚，这些信息一方面很难经过文档的方式，又及时又准确的同步到运维部门来，就算是同步过来了，运维部门的维护量也很是的大。

因此，有了容器，最大的改变是环境交付的提早，是每一个开发多花5%的时间，去换取运维200%的劳动，而且提升稳定性。

而另外一方面，原本运维只管交付资源，给你个虚拟机，虚拟机里面的应用如何相互访问我无论，大家爱咋地咋地，有了Kubernetes之后，运维层要关注服务发现，配置中心，熔断降级。

二者融合在了一块儿。

在微服务化的研发的角度来说，Kubernetes虽然复杂，可是设计的都是有道理的，符合微服务的思想。

3、微服务化的十个设计要点

微服务有哪些要点呢？第一张图是SpringCloud的整个生态。

第二张图是微服务的12要素以及在网易云的实践。

第三张图是构建一个高并发的微服务，须要考虑的全部的点。（打个广告，这是一门课程，即将上线。）

接下来细说微服务的设计要点。

设计要点一：API网关。

在实施微服务的过程当中，难免要面临服务的聚合与拆分，当后端服务的拆分相对比较频繁的时候，做为手机App来说，每每须要一个统一的入口，将不一样的请求路由到不一样的服务，不管后面如何拆分与聚合，对于手机端来说都是透明的。

有了API网关之后，简单的数据聚合能够在网关层完成，这样就不用在手机App端完成，从而手机App耗电量较小，用户体验较好。

有了统一的API网关，还能够进行统一的认证和鉴权，尽管服务之间的相互调用比较复杂，接口也会比较多，API网关每每只暴露必须的对外接口，而且对接口进行统一的认证和鉴权，使得内部的服务相互访问的时候，不用再进行认证和鉴权，效率会比较高。

有了统一的API网关，能够在这一层设定必定的策略，进行A/B测试，蓝绿发布，预发环境导流等等。API网关每每是无状态的，能够横向扩展，从而不会成为性能瓶颈。

设计要点二：无状态化，区分有状态的和无状态的应用。

影响应用迁移和横向扩展的重要因素就是应用的状态，无状态服务，是要把这个状态往外移，将Session数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含商务逻辑。

状态是不可避免的，例如ZooKeeper, DB，Cache等，把这些全部有状态的东西收敛在一个很是集中的集群里面。

整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。

无状态的部分能实现两点，一是跨机房随意地部署，也即迁移性，一是弹性伸缩，很容易的进行扩容。

有状态的部分，如DB，Cache，ZooKeeper有本身的高可用机制，要利用到他们本身的高可用的机制来实现这个状态的集群。

虽然说无状态化，可是当前处理的数据，仍是会在内存里面的，当前的进程挂掉数据，确定也是有一部分丢失的，为了实现这一点，服务要有重试的机制，接口要有幂等的机制，经过服务发现机制，从新调用一次后端的服务的另外一个实例就能够了。

设计要点三：数据库的横向扩展。

数据库是保存状态，最重要的也是最容易出现瓶颈的。有了分布式数据库可使得数据库的性能能够随着节点的增长线性的增长。

分布式数据库最最下面是RDS，是主备的，经过MySql的内核开发能力，咱们可以实现主备切换数据零丢失，因此数据落在这个RDS里面，是很是放心的，哪怕是挂了一个节点，切换完了之后，你的数据也是不会丢的。

再往上就是横向怎么承载大的吞吐量的问题，上面有一个的负载均衡NLB，用LVS，HAProxy, Keepalived，下面接了一层Query Server。Query Server是能够根据监控的数据进行横向的扩展的，若是出现了故障，能够随时进行替换的修复的，对于业务层是没有任何感知的。

另一个就是双机房的部署，DDB这面开发了一个数据运河NDC的组件，可使得不一样的DDB之间在不一样的机房里面进行同步，这时候不但在一个数据中内心面是分布式的，在多个数据中内心面也会有一个相似双活的一个备份，高可用性有很是好的保证。

设计要点四：缓存、缓存

在高并发场景下缓存是很是重要的。要有层次的缓存，使得数据尽可能靠近用户。数据越靠近用户能承载的并发量也越大，响应时间越小。

在手机客户端App上就应该有一层缓存，不是全部的数据都每时每刻都从后端拿，而是只拿重要的，关键的，时常变化的数据。

尤为是对于静态数据，能够过一段时间去取一次，并且也不必到数据中心去取，能够经过CDN，将数据缓存在距离客户端最近的节点上，进行就近的下载。

有的时候CDN里面没有，仍是要回到数据中心去下载，称为回源，在数据中心的最外层，咱们称为接入层，能够设置一层缓存，将大部分的请求拦截，从而不会对后台的数据库形成压力。

若是是动态数据，仍是须要访问应用，经过应用中的商务逻辑生成，或者去数据库中读取，为了减轻数据库的压力，应用可使用本地的缓存，也可使用分布式缓存，如Memcached或者Redis，使得大部分的请求读取缓存便可，没必要访问数据库。

固然动态数据还能够作必定的静态化，也即降级成静态数据，从而减小后端的压力。

设计要点五式：服务拆分和服务发现。

当系统扛不住，应用变化快的时候，每每要考虑将比较大的服务拆分为一系列小的服务。

这样首先的好处就是开发比较独立，当很是多的人在维护同一个代码仓库的时候，每每对代码的修改就会相互影响，经常会出现，我没改什么测试就不经过了，并且代码提交的时候，常常会出现冲突，须要进行代码合并，大大下降了开发的效率。

另一个好处就是上线独立，物流模块对接了一家新的快递公司，须要连同下单一块儿上线，这是很是不合理的行为，我没改还要我重启，我没改还让我发布，我没改还要我开会，都是应该拆分的时机。

另外再就是高并发时段的扩容，每每只有最关键的下单和支付流程是核心，只要将关键的交易链路进行扩容便可，若是这时候附带不少其余的服务，扩容即便不经济的，也是颇有风险的。

再就是容灾和降级，在大促的时候，可能须要牺牲一部分的边角功能，可是若是全部的代码耦合在一块儿，很难将边角的部分功能进行降级。

固然拆分完毕之后，应用之间的关系就更加复杂了，于是须要服务发现的机制，来管理应用相互的关系，实现自动的修复，自动的关联，自动的负载均衡，自动的容错切换。

设计要点六：服务编排与弹性伸缩

当服务拆分了，进程就会很是的多，于是须要服务编排，来管理服务之间的依赖关系，以及将服务的部署代码化，也就是咱们常说的基础设施即代码。这样对于服务的发布，更新，回滚，扩容，缩容，均可以经过修改编排文件来实现，从而增长了可追溯性，易管理性，和自动化的能力。

既然编排文件也能够用代码仓库进行管理，就能够实现一百个服务中，更新其中五个服务，只要修改编排文件中的五个服务的配置就能够，当编排文件提交的时候，代码仓库自动触发自动部署升级脚本，从而更新线上的环境，当发现新的环境有问题的时候，固然但愿将这五个服务原子性的回滚，若是没有编排文件，须要人工记录此次升级了哪五个服务。有了编排文件，只要在代码仓库里面revert，就回滚到上一个版本了。全部的操做在代码仓库里面都是能够看到的。

设计要点七：统一配置中心

服务拆分之后，服务的数量很是的多，若是全部的配置都以配置文件的方式，放在应用本地的话，很是难以管理，能够想象当有几百上千个进程中，有一个配置出现了问题，你很难将它找出来，于是须要有统一的配置中心，来管理全部的配置，进行统一的配置下发。

在微服务中，配置每每分为几类，一类是几乎不变的配置，这种配置能够直接打在容器镜像里面，第二类是启动时就会肯定的配置，这种配置每每经过环境变量，在容器启动的时候传进去，第三类就是统一的配置，须要经过配置中心进行下发，例如在大促的状况下，有些功能须要降级，哪些功能能够降级，哪些功能不能降级，均可以在配置文件中统一的配置。

设计要点八：统一的日志中心

一样是进程数目很是多的时候，很难对成千上百个容器，一个一个登陆进去查看日志，因此须要统一的日志中心来收集日志，为了使收集到的日志容易分析，对于日志的规范，须要有必定的要求，当全部的服务都遵照统一的日志规范的时候，在日志中心就能够对一个交易流程进行统一的追溯。例如在最后的日志搜索引擎中，搜索交易号，就可以看到在哪一个过程出现了错误或者异常。

设计要点九：熔断，限流，降级

服务要有熔断，限流，降级的能力，当一个服务调用另一个服务，出现超时的时候，应及时的返回，而非阻塞在那个地方，从而影响其余用户的交易，能够返回默认的托底数据。

当一个服务发现被调用的服务，由于过于繁忙，线程池满，链接池满，或者老是出错，则应该及时熔断，防止由于下一个服务的错误或繁忙，致使本服务的不正常，从而逐渐往前传导，致使整个应用的雪崩。

当发现整个系统的确负载太高的时候，能够选择降级某些功能或某些调用，保证最重要的交易流程的经过，以及最重要的资源所有用于保证最核心的流程。

还有一种手段就是限流，当既设置了熔断策略，也设置了降级策略，经过全链路的压力测试，应该可以知道整个系统的支撑能力，于是就须要制定限流策略，保证系统在测试过的支撑能力范围内进行服务，超出支撑能力范围的，可拒绝服务。当你下单的时候，系统弹出对话框说“系统忙，请重试”，并不表明系统挂了，而是说明系统是正常工做的，只不过限流策略起到了做用。

设计要点十：全方位的监控

当系统很是复杂的时候，要有统一的监控，主要两个方面，一个是是否健康，一个是性能瓶颈在哪里。当系统出现异常的时候，监控系统能够配合告警系统，及时的发现，通知，干预，从而保障系统的顺利运行。

当压力测试的时候，每每会遭遇瓶颈，也须要有全方位的监控来找出瓶颈点，同时可以保留现场，从而能够追溯和分析，进行全方位的优化。

4、Kubernetes自己就是微服务架构

基于上面这十个设计要点，咱们再回来看Kubernetes，会发现越看越顺眼。

首先Kubernetes自己就是微服务的架构，虽然看起来复杂，可是容易定制化，容易横向扩展。

如图黑色的部分是Kubernetes原生的部分，而蓝色的部分是网易云为了支撑大规模高并发应用而定制化的部分。

Kubernetes的API Server更像网关，提供统一的鉴权和访问接口。

众所周知，Kubernetes的租户管理相对比较弱，尤为是对于公有云场景，复杂的租户关系的管理，咱们只要定制化API Server，对接Keystone，就能够管理复杂的租户关系，而不用管其余的组件。

在Kubernetes中几乎全部的组件都是无状态化的，状态都保存在统一的etcd里面，这使得扩展性很是好，组件之间异步完成本身的任务，将结果放在etcd里面，互相不耦合。

例如图中pod的建立过程，客户端的建立仅仅是在etcd中生成一个记录，而其余的组件监听到这个事件后，也相应异步的作本身的事情，并将处理的结果一样放在etcd中，一样并非哪个组件远程调用kubelet，命令他进行容器的建立，而是发现etcd中，pod被绑定到了本身这里，方才拉起。

为了在公有云中实现租户的隔离性，咱们的策略是不一样的租户，不共享节点，这就须要Kubernetes对于IaaS层有所感知，于是须要实现本身的Controller，Kubernetes的设计使得咱们能够独立建立本身的Controller，而不是直接改代码。

API-Server做为接入层，是有本身的缓存机制的，防止全部的请求的压力直接到后端的数据库上。可是当仍然没法承载高并发请求的时候，瓶颈依然在后端的etcd存储上，这和电商应用一摸同样。固然可以想到的方式也是对etcd进行分库分表，不一样的租户保存在不一样的etcd集群中。

有了API Server作API网关，后端的服务进行定制化，对于client和kubelet是透明的。

如图是定制化的容器建立流程，因为大促和非大促期间，节点的数目相差比较大，于是不能采用事先所有建立好节点的方式，这样会形成资源的浪费，于是中间添加了网易云本身的模块Controller和IaaS的管理层，使得当建立容器资源不足的时候，动态调用IaaS的接口，动态的建立资源。这一切对于客户端和kubelet无感知。

为了解决超过3万个节点的规模问题，网易云须要对各个模块进行优化，因为每一个子模块仅仅完成本身的功能，Scheduler只管调度，Proxy只管转发，而非耦合在一块儿，于是每一个组件均可以进行独立的优化，这符合微服务中的独立功能，独立优化，互不影响。并且Kubernetes的全部组件的都是Go开发的，更加容易一些。因此Kubernetes上手慢，可是一旦须要定制化，会发现更加容易。

5、Kubernetes更加适合微服务和DevOps的设计

好了，说了K8S自己，接下来讲说K8S的理念设计，为何这么适合微服务。

前面微服务设计的十大模式，其中一个就是区分无状态和有状态，在K8S中，无状态对应deployment，有状态对应StatefulSet。

deployment主要经过副本数，解决横向扩展的问题。

而StatefulSet经过一致的网络ID，一致的存储，顺序的升级，扩展，回滚等机制，能够保证有状态应用，很好地利用本身的高可用机制。由于大多数集群的高可用机制，都是能够容忍一个节点暂时挂掉的，可是不能容忍大多数节点同时挂掉。并且高可用机制虽然能够保证一个节点挂掉后回来，有必定的修复机制，可是须要知道刚才挂掉的究竟是哪一个节点，StatefulSet的机制可让容器里面的脚本有足够的信息，处理这些状况，实现哪怕是有状态，也能尽快修复。

在微服务中，比较推荐使用云平台的PaaS，例如数据库，消息总线，缓存等。可是配置也是很是复杂的，由于不一样的环境须要链接不一样的PaaS服务。

K8S里面的headless service是能够很好的解决这个问题的，只要给外部的服务建立一个headless service，指向相应的PaaS服务，而且将服务名配置到应用中。因为生产和测试环境分红Namespace，虽然配置了相同的服务名，可是不会错误访问，简化了配置。

微服务少不了服务发现，除了应用层可使用SpringCloud或者Dubbo进行服务发现，在容器平台层固然是用Service了，能够实现负载均衡，自修复，自动关联。

服务编排，原本K8S就是编排的标准，能够将yml文件放到代码仓库中进行管理，而经过deployment的副本数，能够实现弹性伸缩。

对于配置中心，K8S提供了configMap，能够在容器启动的时候，将配置注入到环境变量或者Volume里面。可是惟一的缺点是，注入到环境变量中的配置不能动态改变了，好在Volume里面的能够，只要容器中的进程有reload机制，就能够实现配置的动态下发了。

统一日志和监控每每须要在Node上部署Agent，来对日志和指标进行收集，固然每一个Node上都有，daemonset的设计，使得更容易实现。

固然目前最最火的Service Mesh，能够实现更加精细化的服务治理，进行熔断，路由，降级等策略。Service Mesh的实现每每经过sidecar的方式，拦截服务的流量，进行治理。这也得力于Pod的理念，一个Pod能够有多个容器，若是当初的设计没有Pod，直接启动的就是容器，会很是的不方便。

因此K8S的各类设计，看起来很是的冗余和复杂，入门门槛比较高，可是一旦想实现真正的微服务，K8S是能够给你各类可能的组合方式的。实践过微服务的人，每每会对这一点深有体会。

6、Kubernetes的常见的使用方式

下面咱们来看一下，微服务化的不一样阶段，Kubernetes的使用方式。

第一阶段：使用公有云虚拟机

也即没有微服务化的阶段，基本上一个进程就能搞定，两个进程作高可用，不须要使用容器，虚拟机就很是好。

第二阶段：容器做为持续集成工具

当微服务开始拆分了，如何保证拆分后功能的一致性，须要持续集成做为保证，如前面的论述，容器是很是好的持续集成工具，是解决CI/CD中D的，因此一开始用host网络就能够，这样能够保证部署方式和原来兼容。

若是想用私有云进行部署，直接部署在物理机上，在性能要求没有很高，可是又要和其余物理机很好的通讯的状况下，能够用bridge打平网络的方式比较好。经过建立网桥，将物理网卡，容器网卡都链接到一个网桥上，能够实现全部的容器和物理机在一样的一个二层网络里面。

若是性能要求比较高，例如要部署相似缓存，则可使用sr-iov网卡。

若是想实现租户的简单隔离，则每每使用各类Overlay的网络模式，这是最经常使用的部署方式。图中的数据来自网络。Flannel，Calico都是很是好的网络插件，虽然Flannel一开始使用用户态的模式性能很差，后来使用内核态，性能大大改善，使用gw模式后，和Calico性能至关。

网易云采用了Kubernetes和IaaS深度融合的方式，相似AWS的Fargate的模式，一方面可使得原来使用虚拟机的用户平滑地迁移到容器，另外一方面能够实现公有云的租户隔离。

如图是融合的网易云容器服务的架构，这个管理OpenStack和Kubernetes的管理平台，也是用的微服务架构，有API网关，熔断限流功能，拆分红不一样的服务，部署在K8S上的，因此到处是微服务。