持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第9天，点击查看活动详情
Master节点实现细节，Borg与Kubernetes不尽相同，但出发点一致，即如何编排、管理、调度用户提交的作业。Borg完全能将Docker镜像看做一种新的应用打包方式，Borg团队过去在大规模作业管理与编排上的经验可直接“套”在k8s。
所以，一开始k8s就没像同期各种“容器云”项目，把Docker作为整个架构核心，而是另辟蹊径, 仅把它作为最底层的一个容器运行时实现。
而k8s着重Borg研究人员在论文中提到的：运行在大规模集群中的各种任务之间，实际上存在各种关系。这些关系的处理，才是作业编排和管理系统最困难的。
这种任务 <=>任务之间的关系随处可见：
- 一个Web应用与数据库之间的访问关系
- 一个负载均衡器和它的后端服务
- 一个门户应用与授权组件之间的调用关系
而且同属于一个服务单位的不同功能之间，也完全可能存在这样的关系，如
- 一个Web应用与日志搜集组件之间的文件交换关系。
而容器技术普及前，传统VM对这种关系的处理方法都比较“粗粒度”：
- 很多功能并不相关应用被一锅部署在同台虚拟机，只是因为偶尔会互相发几个HTTP请求
- 更常见的情况则是，一个应用被部署在虚拟机里之后，你还得手动维护很多跟它协作的守护进程（Daemon），用来处理它的日志搜集、灾难恢复、数据备份等辅助工作
“功能单位”划分上，容器有独到“细粒度”优势：毕竟容器的本质，只是个进程。即只要你愿意，那些原挤在同一VM里的各个应用、组件、守护进程，都可被分别做成镜像，然后运行在一个个专属容器。它们互不干涉，拥有各自资源配额，可被调度在整个集群里的任何一台机器。这正是PaaS系统最理想工作状态，即微服务思想得以落地的先决条件。
若只做到 封装微服务、调度单容器，Swarm就已绰绰有余。若再加上Compose项目，甚至还具备处理一些简单依赖关系的能力，如一个“Web容器”和它要访问的数据库“DB容器”。
Compose中可为这样的两个容器定义一个“link”，而Docker项目则会负责维护该“link”关系：Docker会在Web容器中，将DB容器的IP地址、端口等信息以环境变量的方式注入，供应用进程使用，如：
DB_NAME=/web/db
DB_PORT=tcp://172.17.0.5:5432
DB_PORT_5432_TCP=tcp://172.17.0.5:5432
DB_PORT_5432_TCP_PROTO=tcp
DB_PORT_5432_TCP_PORT=5432
DB_PORT_5432_TCP_ADDR=172.17.0.5
- 平台项目自动地处理容器间关系的典型例子 当DB容器发生变化时（比如镜像更新，被迁移至其他宿主机），这些环境变量的值会由Docker项目自动更新
