容器编排
容器编排
“编排”主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。
容器编排指的就是够定义容器组织和管理规范的工具，典型的是 Docker 公司的 Compose+Swarm 组合，以及 Google 与 RedHat 公司共同主导的 Kubernetes 项目。
Docker 公司最后选择将开源项目与商业产品紧密绑定，打造了一个极 端封闭的技术生态。违背了 Docker 项目与开发者保持亲密关系的初衷。相比之下， Kubernetes 社区，正是以一种更加温和的方式，承接了 Docker 项目的未尽事业，即：以开发者为核心，构建一个相对*和开放的容器生态。
Kubernetes 项目的理论基础来自 Google 公司在 2015 年 4 月发布的 Borg 论文。
Borg
Google内部的大型集群管理系统
存在的目的：
-
在尽量不影响软件运作效率的情况下，最大限度的帮公司省钱，合理利用所有闲置资源（内存、网络等等）。
-
尽力压榨CPU计算资源。
整体架构：
scheduler调度流程：
Kubernetes
架构：
-
Controller Manager: 负责容器编排
-
API Server: 负责 API 服 务
-
Scheduler: 负责调度
-
Etcd: 整个集群的持久化数据
计算节点Node上最核心的部分，是 kubelet （命名来源Borg的Borglet）。
从架构上可以明显看处Borg对于k8s 的指导意义：Master节点如何编排、管理、调度用户提交的作业？
Kubernetes 项目要着重解决的问题：
运行在大规模集群中的各种任务之间，实际上存在着各种各样的关系。这些关系的处理，才是作 业编排和管理系统最困难的地方。
Kubernetes 项目最主要的设计思想是，从宏观的角度，以统一的方式来定义任务之间的各 种关系，并且为将来支持更多种类的关系留有余地。
在 Kubernetes 项目中所推崇的使用方法是：
首先，通过一个“编排对象”，比如 Pod、Job、CronJob 等，来描述你试图管理的应用；
然后，再为它定义一些“服务对象”，比如 Service、Secret、Horizontal Pod Autoscaler（自 动水平扩展器）等。这些对象，会负责具体的平台级功能。
这种使用方法，就是所谓的“声明式 API”。这种 API 对应的“编排对象”和“服务对象”，都是 Kubernetes 项目中的 API 对象（API Object）。