为何 kubernetes 自然适合微服务

本文由 网易云 发布

做者：刘超，网易云首席解决方案架构师

最近总在思考，为何在支撑容器平台和微服务的竞争中，Kubernetes 会取得最终的胜出，事实上从不少角度出发三大容器平台从功能方面来看，最后简直是如出一辙。（可参考《容器平台选型的十大模式：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 的使用方式，详见这篇文章：微服务化的不一样阶段 Kubernetes 的不一样玩法

了解网易云：

网易云官网：www.163yun.com/

新用户大礼包：www.163yun.com/gift

网易云社区：sq.163yun.com/

免费试用网易云基础服务：www.163yun.com/product-clo…