闫健勇等
2016年中国移动率先成功地在电信领域尝试大规模地部署和应用Docker & Kubernetes平台。
容器技术不仅仅对运维的帮助很大，它对软件开发的生命周期管理也带来了很大的冲击，大大促进了DevOps理念的落地。
容器技术带来了诸多的变革。首先，Docker推动了微服务架构设计理念的落地，把一个原来很庞大的复杂的单体（单进程）应用拆成一个个基于业务功能的完全独立的小程序，并且分布式部署在一个集群中，以增加系统的稳定性、水平扩展能力，这就是微服务架构的核心思想和做法
微服务架构相对于传统单体应用来说，有两个明显的优势：第一，在开发上一个很大的团队完全可以拆成一个个小的专业团队，各自关注不同的业务功能的开发，因此系统的开发迭代、更新和升级就会变得非常敏捷；第二，由于微服务架构本身就是分布式架构，所以很容易实现系统的高可用以及快速弹性扩容能力，当某一个业务随着访问量的增大而出现性能瓶颈时，我们就能快速地对其进行弹性伸缩，增加服务实例数量，以改善整个系统的性能。
实际上微服务的理念很早就已经提出，微服务要求我们把一个完整的应用拆成一个个独立部署的微服务进程，并且部署在多个机器组成的一个集群中，每个机器上会部署很多微服务进程，不仅大大增加了系统发布、测试和部署的工作量，后续系统升级和运维管理的难度和复杂度也会大大提升
Docker大大提升了软件开发和系统运维的效率，促进了DevOps体系的成熟与发展。
Docker最大的特点是对应用的发布版做了一个标准化的封装，解决了应用的环境依赖难题，并且不再需要安装部署过程。
通过一个流水线串联并驱动整个应用的开发生命周期过程，包括源码编译、镜像打包、自动部署或升级（测试环境）、自动化测试，以及运维阶段的监控告警、自动扩容等环节，这就是DevOps的实践思路。由于在这个过程中引入了Docker技术，从而很大程度上提升了系统运维的可管控性、可度量性、可监控性等重要指标，这就是Docker带来的第二个重要变革：进一步促进了DevOps的落地和发展。因此，在容器化平台改造建设完成之后，下一个重点目标就是建设DevOps平台，以促进整个软件的开发运维流程进一步向自动化、可管控性的目标迈进。
Kubernetes中最重要的一个概念是Service，这实际上是微服务架构理念，Service就是一个微服务，背后对应一组从容器方式运行的程序实例，具备弹性扩容和自动故障恢复的能力。
Kubernetes第一次将Service的高度提升到超过Machine的地位，我们不再关注应用部署的细节，只要规划好系统是由多少种不同的Service所组成的，每种Service需要部署多少个容器（Pod）实例才能满足性能要求，其他的就交给Kubernetes引擎了，它会根据当前集群资源的使用情况给出最佳的调度方案，并且自动完成容器实例的创建和部署过程，我们无须再花费脑力进行规划。
“高度自动化”
在Kubernetes的世界里，资源调度是自动化的，程序部署是自动化的，监控是自动化的，故障恢复是自动化的，服务平滑升级只要一键，服务扩容也只要一键
4条和微服务架构理念特别接近，微服务就像把UNIX哲学应用到了分布式系统。
❑ small is beautiful（小即是美）：小的服务代码少、bug少、易测试、易维护，也更容易不断迭代完善，精致进而美妙。
❑ make each program do one thing well（一个程序只做好一件事）：一个服务只需要做好一件事，专注才能做好。 ❑ build a prototype as soon as possible（尽可能早地创建原型）：尽可能早地提供服务API，建立服务契约，达成服务间沟通的一致性约定，至于实现和完善可以慢慢地做。 ❑ choose portability over efficiency（可移植性比效率更重要）：服务间的轻量级交互协议在
那么微服务有哪些特征？ 首先，每个微服务都在自己的进程中；其次，服务和服务之间除了轻量级的通信机制，也就是API的调用之外，不能有其他的调用方式，不能直接访问别人服务的数据，不能直接有一个类似库表之间的调用，只能是轻量级的通信机制；最后，这些服务围绕业务能力构建，并且全部可以独立部署，可以自动化实现一个个小的构件，然后这些服务共用一个最小型的集中式管理，服务可以用适合的语言和数据库。这就是一个微服务。
只有拆分成一个个小的服务，才能更好地管理，让每个团队更灵动，从而促进团队之间的竞争
微服务、容器化、DevOps如同一个铁三角，密不可分。
而微服务架构建议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。亚马逊对此提出了一个观点：You build it, you run it（谁构建，谁运行）。开发团队对软件在生产环境中的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每日的交流反馈，来自客户的直接反馈有助于开发者提升服务的品质。
就是说在需求阶段就要把测试做好，按照接口的约定模拟测试和服务，并且后续按照约定彼此独立上线、独立测试，尽快回路、尽快回馈、尽快反馈，这些都是微服务要关注的问题。
真正效率的提升是通过站立会来具体实现的，形式上要求项目组在每天的固定时间、固定地点、固定15分钟组织站立会。
首先，建议项目引入看板，通过看板来展示项目组每个人的任务和完成状态。
Scrum团队所有成员轮流回答以下3个问题： 1）我昨天完成了什么工作。 2）今天我打算做什么工作。 3）我在工作中遇到了什么困难，这也是最关键的。
Cgroups的作用，就是限制进程所使用的资源配额。Cgroups是谷歌发明的，谷歌想用最节省资源的方式将一个主机的资源被多个进程分享复用，但虚拟机是非常耗费资源的，所以虚拟机的这条路走不通，于是谷歌发明了Cgroups。
Cgroups实现资源配额管理，Namespace实现资源隔离，两者的结合相当于虚拟机。
Kubernetes这个开源项目可以有力地推动开发者使用谷歌的云计算服务平台GCE（Google Compute Engine），谷歌逐渐开始意识到开源环境推进云战略的重要性，哪怕把它最大的秘密部分开源化也在所不惜。
而我们有完整的拼图。我们有10年的经验，知道怎么把碎片拼到一起。”
Kubernetes的目的是要让容器能用于企业的生产环境，使容器集群的配置标准化，让分布式应用的开发和部署更加容易。同时，谷歌也希望Kubernetes能够成为鼓励用户使用谷歌云服务的舵手。
2015年Kubernetes一经推出，
Kubernetes本身也是一个分布式系统，它的总体架构由一个Master节点和多个计算节点（Node）组成。
在每个Node上都有两个代理组件：Kubelet和Proxy。
Kubelet就像一位称职的“保姆”，负责本机上面各容器的全生命周期管理，从创建开始，到运行状态的跟踪，再到销毁、删除或者重启等工作。Kubelet会与Master持续保持通信，一方面接收Master节点下发到本节点的任务并进行处理；另一方面会不断报告本机的任务执行情况给Master，然后等待下一步指令。
Proxy则完全是针对分布式容器应用而设计的一个智能的负载均衡器，它是Kubernetes核心Service概念的具体实现。一个分布式应用一般都是由一组功能相同的容器组成的，将这组容器封装起来形成的逻辑概念就称为Service（详见5.2.2节“3.Service”小节中的说明）。Proxy实现的主要功能就是将客户端对Service的访问请求转发到后端正确的容器上去。
在Kubernetes中，Service是最核心的资源对象之一，Kubernetes里的每个Service其实就是微服务架构中的一个个“微服务”，而Pod、RC等资源对象其实都是为实现Service而提供底层的基础支持的。
也能运行定时任务、并行计算等批处理任务。Kubernetes引入Job资源对象来管理批处理任务。