└── HTML ├── 00 开篇词 _ 打通“容器技术”的任督二脉.html ├── 01 预习篇 · 小鲸鱼大事记（一）：初出茅庐.html ├── 02 预习篇 · 小鲸鱼大事记（二）：崭露头角.html ├── 03 预习篇 · 小鲸鱼大事记（三）：群雄并起.html ├── 04 预习篇 · 小鲸鱼大事记（四）：尘埃落定.html ├── 05 白话容器基础（一）：从进程说开去.html ├── 06 白话容器基础（二）：隔离与限制.html ├── 07 白话容器基础（三）：深入理解容器镜像.html ├── 08 白话容器基础（四）：重新认识Docker容器.html ├── 09 从容器到容器云：谈谈Kubernetes的本质.html ├── 10 Kubernetes一键部署利器：kubeadm.html ├── 11 从0到1：搭建一个完整的Kubernetes集群.html ├── 12 牛刀小试：我的第一个容器化应用.html ├── 13 为什么我们需要Pod？.html ├── 14 深入解析Pod对象（一）：基本概念.html ├── 15 深入解析Pod对象（二）：使用进阶.html ├── 16 编排其实很简单：谈谈“控制器”模型.html ├── 17 经典PaaS的记忆：作业副本与水平扩展.html ├── 18 深入理解StatefulSet（一）：拓扑状态.html ├── 19 深入理解StatefulSet（二）：存储状态.html ├── 20 深入理解StatefulSet（三）：有状态应用实践.html ├── 21 容器化守护进程的意义：DaemonSet.html ├── 22 撬动离线业务：Job与CronJob.html ├── 23 声明式API与Kubernetes编程范式.html ├── 24 深入解析声明式API（一）：API对象的奥秘.html ├── 25 深入解析声明式API（二）：编写自定义控制器.html ├── 26 基于角色的权限控制：RBAC.html ├── 27 聪明的微创新：Operator工作原理解读.html ├── 28 PV、PVC、StorageClass，这些到底在说啥？.html ├── 29 PV、PVC体系是不是多此一举？从本地持久化卷谈起.html ├── 30 编写自己的存储插件：FlexVolume与CSI.html ├── 31 容器存储实践：CSI插件编写指南.html ├── 32 浅谈容器网络.html ├── 33 深入解析容器跨主机网络.html ├── 34 Kubernetes网络模型与CNI网络插件.html ├── 35 解读Kubernetes三层网络方案.html ├── 36 为什么说Kubernetes只有soft multi-tenancy？.html ├── 37 找到容器不容易：Service、DNS与服务发现.html ├── 38 从外界连通Service与Service调试“三板斧”.html ├── 39 谈谈Service与Ingress.html ├── 40 Kubernetes的资源模型与资源管理.html ├── 41 十字路口上的Kubernetes默认调度器.html ├── 42 Kubernetes默认调度器调度策略解析.html ├── 43 Kubernetes默认调度器的优先级与抢占机制.html ├── 44 Kubernetes GPU管理与Device Plugin机制.html ├── 45 幕后英雄：SIG-Node与CRI.html ├── 46 解读 CRI 与 容器运行时.html ├── 47 绝不仅仅是安全：Kata Containers 与 gVisor.html ├── 48 Prometheus、Metrics Server与Kubernetes监控体系.html ├── 49 Custom Metrics 让Auto Scaling不再“食之无味”.html ├── 50 让日志无处可逃：容器日志收集与管理.html ├── 51 谈谈Kubernetes开源社区和未来走向.html ├── 52 答疑：在问题中解决问题，在思考中产生思考.html └── 53 结束语 Kubernetes：赢开发者赢天下.html /HTML/02 预习篇 · 小鲸鱼大事记（二）：崭露头角.html: -------------------------------------------------------------------------------- 1 | 极客时间 | 深入剖析Kubernetes
讲堂 深入剖析Kubernetes 文章详情

17 | 02 | 预习篇 · 小鲸鱼大事记（二）：崭露头角 18 |

2018-08-29 张磊

02 | 预习篇 · 小鲸鱼大事记（二）：崭露头角

朗读人：张磊    06′50′′ | 3.14M

你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之崭露头角。

19 |

在上一篇文章中，我说到，伴随着 PaaS 概念的逐步普及，以 Cloud Foundry 为代表的经典 PaaS 项目，开始进入基础设施领域的视野，平台化和 PaaS 化成了这个生态中的一个最为重要的进化趋势。

20 |

就在对开源 PaaS 项目落地的不断尝试中，这个领域的从业者们发现了 PaaS 中最为棘手也最亟待解决的一个问题：究竟如何给应用打包？

21 |

遗憾的是，无论是 Cloud Foundry、OpenShift，还是 Clodify，面对这个问题都没能给出一个完美的答案，反而在竞争中走向了碎片化的歧途。

22 |

而就在这时，一个并不引人瞩目的 PaaS 创业公司 dotCloud，却选择了开源自家的一个容器项目 Docker。更出人意料的是，就是这样一个普通到不能再普通的技术，却开启了一个名为“Docker”的全新时代。

23 |

你可能会有疑问，Docker 项目的崛起，是不是偶然呢？

24 |

事实上，这个以“鲸鱼”为注册商标的技术创业公司，最重要的战略之一就是：坚持把“开发者”群体放在至高无上的位置。

25 |

相比于其他正在企业级市场里厮杀得头破血流的经典 PaaS 项目们，Docker 项目的推广策略从一开始就呈现出一副“憨态可掬”的亲人姿态，把每一位后端技术人员（而不是他们的老板）作为主要的传播对象。

26 |

简洁的 UI，有趣的 demo，“1 分钟部署一个 WordPress 网站”“3 分钟部署一个 Nginx 集群”，这种同开发者之间与生俱来的亲近关系，使 Docker 项目迅速成为了全世界 Meetup 上最受欢迎的一颗新星。

27 |

在过去的很长一段时间里，相较于前端和互联网技术社区，服务器端技术社区一直是一个相对沉闷而小众的圈子。在这里，从事 Linux 内核开发的极客们自带“不合群”的“光环”，后端开发者们啃着多年不变的 TCP/IP 发着牢骚，运维更是天生注定的幕后英雄。

28 |

而 Docker 项目，却给后端开发者提供了走向聚光灯的机会。就比如 Cgroups 和 Namespace 这种已经存在多年却很少被人们关心的特性，在 2014 年和 2015 年竟然频繁入选各大技术会议的分享议题，就因为听众们想要知道 Docker 这个东西到底是怎么一回事儿。

29 |

而 Docker 项目之所以能取得如此高的关注，一方面正如前面我所说的那样，它解决了应用打包和发布这一困扰运维人员多年的技术难题；而另一方面，就是因为它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里。

30 |

在这种独特的氛围烘托下，你不需要精通 TCP/IP，也无需深谙 Linux 内核原理，哪怕只是一个前端或者网站的 PHP 工程师，都会对如何把自己的代码打包成一个随处可以运行的 Docker 镜像充满好奇和兴趣。

31 |

这种受众群体的变革，正是 Docker 这样一个后端开源项目取得巨大成功的关键。这也是经典 PaaS 项目想做却没有做好的一件事情：PaaS 的最终用户和受益者，一定是为这个 PaaS 编写应用的开发者们，而在 Docker 项目开源之前，PaaS 与开发者之间的关系却从未如此紧密过。

32 |

解决了应用打包这个根本性的问题，同开发者与生俱来的的亲密关系，再加上 PaaS 概念已经深入人心的完美契机，成为 Docker 这个技术上看似平淡无奇的项目一举走红的重要原因。

33 |

一时之间，“容器化”取代“PaaS 化”成为了基础设施领域最炙手可热的关键词，一个以“容器”为中心的、全新的云计算市场，正呼之欲出。而作为这个生态的一手缔造者，此时的 dotCloud 公司突然宣布将公司名称改为“Docker”。

34 |

这个举动，在当时颇受质疑。在大家印象中，Docker 只是一个开源项目的名字。可是现在，这个单词却成了 Docker 公司的注册商标，任何人在商业活动中使用这个单词，以及鲸鱼的 Logo，都会立刻受到法律警告。

35 |

那么，Docker 公司这个举动到底卖的什么药？这个问题，我不妨后面再做解读，因为相较于这件“小事儿”，Docker 公司在 2014 年发布 Swarm 项目才是真正的“大事儿”。

36 |

那么，Docker 公司为什么一定要发布 Swarm 项目呢？

37 |

通过我对 Docker 项目崛起背后原因的分析，你应该能发现这样一个有意思的事实：虽然通过“容器”这个概念完成了对经典 PaaS 项目的“降维打击”，但是 Docker 项目和 Docker 公司，兜兜转转了一年多，却还是回到了 PaaS 项目原本深耕了多年的那个战场：如何让开发者把应用部署在我的项目上。

38 |

没错，Docker 项目从发布之初就全面发力，从技术、社区、商业、市场全方位争取到的开发者群体，实际上是为此后吸引整个生态到自家“PaaS”上的一个铺垫。只不过这时，“PaaS”的定义已经全然不是 Cloud Foundry 描述的那个样子，而是变成了一套以 Docker 容器为技术核心，以 Docker 镜像为打包标准的、全新的“容器化”思路。

39 |

这，正是 Docker 项目从一开始悉心运作“容器化”理念和经营整个 Docker 生态的主要目的。

40 |

而 Swarm 项目，正是接下来承接 Docker 公司所有这些努力的关键所在。

41 |

总结

42 |

今天，我着重介绍了 Docker 项目在短时间内迅速崛起的三个重要原因：

43 |
    44 |
  1. 45 |

    Docker 镜像通过技术手段解决了 PaaS 的根本性问题；

    46 |
    2. 47 |
  2. 48 |

    Docker 容器同开发者之间有着与生俱来的密切关系；

    49 |
    3. 50 |
  3. 51 |

    PaaS 概念已经深入人心的完美契机。

    52 |
    4. 53 |
54 |

崭露头角的 Docker 公司，也终于能够以一个更加强硬的姿态来面对这个曾经无比强势，但现在却完全不知所措的云计算市场。而 2014 年底的 DockerCon 欧洲峰会，则正式拉开了 Docker 公司扩张的序幕。

55 |

思考题

56 |
    57 |
  1. 58 |

    你是否认同 dotCloud 公司改名并开启扩张道路的战略选择？

    59 |
    2. 60 |
  2. 61 |

    Docker 公司凭借“开源”和“开发者社群”这两个关键词完成崛起的过程，对你和你所在的团队有什么启发？

    62 |
    3. 63 |
64 |

感谢收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

65 |

66 |

67 | 版权归极客邦科技所有，未经许可不得转载 68 |

写留言

精选留言

  • 与路同飞
    25
    之前不知道哪里见过一句话，无开源不生态，无生态不商业。挺有道理的
    2018-08-29
  • 日拱一卒
    10
    1. 公司改名无可厚非，项目开源和商业牟利不应该是冲突的。
    2. Docker带来的启示：任何项目或者技术都应该是以用户为中心，找准目标人群，深挖用户痛点，通过用户最能接受的方式，去解决问题。
    2018-08-29
    作者回复

    说的一点没错，用户才是项目和技术的衣食父母，脱离群众要不得

    2018-08-29

  • eason2017
    5
    已经迫不及待的想直入主题啦……
    2018-08-29
  • Cloud*
    4
    这个改名真是太正确了，一下品牌就火了。开源永远都是最好的选择，首先得让开发者认可你，才能走得长远。
    2018-08-29
  • JRich
    3
    精彩，终于理清了docker和paas历史，感觉自己跟上了容器时代发展
    2018-08-29
  • cxyfreedom
    2
    如果按天时地利人和三方面来说，总结的第一点就是地利，第二点是人和，第三点就是天时。另外改名这事，我觉得这是作为一个运营公司从商业角度需要考虑的，没什么问题。
    2018-09-01
  • atompi
    2
    希望能够一直“坚持把‘开发者’群体放在至高无上的位置”
    2018-08-29
  • Anker
    1
    互联网公司的玩法，需要寻找商业化的点子，改名字肯定可以吸引更多的人关注，使用的人多了，流量上来了，就有机会变现。
    2018-09-04
  • 岁月～静好
    1
    看评论也能了解很多东西😁
    2018-08-29
  • blackpiglet
    1
    对于 dotcloud 改名和扩张，我想当时他们可能没有其他选择，毕竟是创业公司，是有盈的压力的。docker 的开源不易带来直接的收入，所以必然要有下一步。
    2018-08-29
  • 张春源
    1
    改不改名无所谓，前面提到了镜像是核心，应该在镜像这层上加以限制。掌控核心竞争力，获取市场！
    2018-08-29
  • abs
    0
    请问下swarm和k8s有什么关联和区别？为什么我知道很多公司用k8s，却很少听说有公司用swarm的？
    2018-09-08
    作者回复

    其实就是主流方案与非主流方案的区别。至于为啥kubernetes 变成主流了，咱们专栏前四篇讲的就是这个故事

    2018-09-08

  • JellyBool
    0
    改名太正确了，一个好的名字就成功了10%
    2018-09-06
  • Hurt
    0
    早早早
    2018-08-29
-------------------------------------------------------------------------------- /HTML/03 预习篇 · 小鲸鱼大事记（三）：群雄并起.html: -------------------------------------------------------------------------------- 1 | 极客时间 | 深入剖析Kubernetes
讲堂 深入剖析Kubernetes 文章详情

17 | 03 | 预习篇 · 小鲸鱼大事记（三）：群雄并起 18 |

2018-08-30 张磊

03 | 预习篇 · 小鲸鱼大事记（三）：群雄并起

朗读人：张磊    10′41′′ | 4.90M

你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之群雄并起。

19 |

在上一篇文章中，我剖析了 Docker 项目迅速走红背后的技术与非技术原因，也介绍了 Docker 公司开启平台化战略的野心。可是，Docker 公司为什么在 Docker 项目已经取得巨大成功之后，却执意要重新走回那条已经让无数先驱们尘沙折戟的 PaaS 之路呢？

20 |

实际上，Docker 项目一日千里的发展势头，一直伴随着公司管理层和股东们的阵阵担忧。他们心里明白，虽然 Docker 项目备受追捧，但用户们最终要部署的，还是他们的网站、服务、数据库，甚至是云计算业务。

21 |

这就意味着，只有那些能够为用户提供平台层能力的工具，才会真正成为开发者们关心和愿意付费的产品。而 Docker 项目这样一个只能用来创建和启停容器的小工具，最终只能充当这些平台项目的“幕后英雄”。

22 |

而谈到 Docker 项目的定位问题，就不得不说说 Docker 公司的老朋友和老对手 CoreOS 了。

23 |

CoreOS 是一个基础设施领域创业公司。 它的核心产品是一个定制化的操作系统，用户可以按照分布式集群的方式，管理所有安装了这个操作系统的节点。从而，用户在集群里部署和管理应用就像使用单机一样方便了。

24 |

Docker 项目发布后，CoreOS 公司很快就认识到可以把“容器”的概念无缝集成到自己的这套方案中，从而为用户提供更高层次的 PaaS 能力。所以，CoreOS 很早就成了 Docker 项目的贡献者，并在短时间内成为了 Docker 项目中第二重要的力量。

25 |

然而，这段短暂的蜜月期到 2014 年底就草草结束了。CoreOS 公司以强烈的措辞宣布与 Docker 公司停止合作，并直接推出了自己研制的 Rocket（后来叫 rkt）容器。

26 |

这次决裂的根本原因，正是源于 Docker 公司对 Docker 项目定位的不满足。Docker 公司解决这种不满足的方法就是，让 Docker 项目提供更多的平台层能力，即向 PaaS 项目进化。而这，显然与 CoreOS 公司的核心产品和战略发生了严重冲突。

27 |

也就是说，Docker 公司在 2014 年就已经定好了平台化的发展方向，并且绝对不会跟 CoreOS 在平台层面开展任何合作。这样看来，Docker 公司在 2014 年 12 月的 DockerCon 上发布 Swarm 的举动，也就一点都不突然了。

28 |

相较于 CoreOS 是依托于一系列开源项目（比如 Container Linux 操作系统、Fleet 作业调度工具、systemd 进程管理和 rkt 容器），一层层搭建起来的平台产品，Swarm 项目则是以一个完整的整体来对外提供集群管理功能。而 Swarm 的最大亮点，则是它完全使用 Docker 项目原本的容器管理 API 来完成集群管理，比如：

29 |
    30 |
  • 单机 Docker 项目：
    • 31 |
32 | 
$ docker run " 我的容器
复制代码
33 |
    34 |
  • 多机 Docker 项目：
    • 35 |
36 | 
$ docker run -H " 我的 Swarm 集群 API 地址 " " 我的容器 "
复制代码
37 |

所以在部署了 Swarm 的多机环境下，用户只需要使用原先的 Docker 指令创建一个容器，这个请求就会被 Swarm 拦截下来处理，然后通过具体的调度算法找到一个合适的 Docker Daemon 运行起来。

38 |

这个操作方式简洁明了，对于已经了解过 Docker 命令行的开发者们也很容易掌握。所以，这样一个“原生”的 Docker 容器集群管理项目一经发布，就受到了已有 Docker 用户群的热捧。而相比之下，CoreOS 的解决方案就显得非常另类，更不用说用户还要去接受完全让人摸不着头脑、新造的容器项目 rkt 了。

39 |

当然，Swarm 项目只是 Docker 公司重新定义“PaaS”的关键一环而已。在 2014 年到 2015 年这段时间里，Docker 项目的迅速走红催生出了一个非常繁荣的“Docker 生态”。在这个生态里，围绕着 Docker 在各个层次进行集成和创新的项目层出不穷。

40 |

而此时已经大红大紫到“不差钱”的Docker 公司，开始及时地借助这波浪潮通过并购来完善自己的平台层能力。其中一个最成功的案例，莫过于对 Fig 项目的收购。

41 |

要知道，Fig 项目基本上只是靠两个人全职开发和维护的，可它却是当时 GitHub 上热度堪比 Docker 项目的明星。

42 |

Fig 项目之所以受欢迎，在于它在开发者面前第一次提出了“容器编排”（Container Orchestration）的概念。

43 |

其实，“编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。

44 |

而容器时代，“编排”显然就是对 Docker 容器的一系列定义、配置和创建动作的管理。而 Fig 的工作实际上非常简单：假如现在用户需要部署的是应用容器 A、数据库容器 B、负载均衡容器 C，那么 Fig 就允许用户把 A、B、C 三个容器定义在一个配置文件中，并且可以指定它们之间的关联关系，比如容器 A 需要访问数据库容器 B。

45 |

接下来，你只需要执行一条非常简单的指令：

46 | 
$ fig up
复制代码
47 |

Fig 就会把这些容器的定义和配置交给 Docker API 按照访问逻辑依次创建，你的一系列容器就都启动了；而容器 A 与 B 之间的关联关系，也会交给 Docker 的 Link 功能通过写入 hosts 文件的方式进行配置。更重要的是，你还可以在 Fig 的配置文件里定义各种容器的副本个数等编排参数，再加上 Swarm 的集群管理能力，一个活脱脱的 PaaS 呼之欲出。

48 |

Fig 项目被收购后改名为 Compose，它成了 Docker 公司到目前为止第二大受欢迎的项目，一直到今天也依然被很多人使用。

49 |

当时的这个容器生态里，还有很多令人眼前一亮的开源项目或公司。比如，专门负责处理容器网络的 SocketPlane 项目（后来被 Docker 公司收购），专门负责处理容器存储的 Flocker 项目（后来被 EMC 公司收购），专门给 Docker 集群做图形化管理界面和对外提供云服务的 Tutum 项目（后来被 Docker 公司收购）等等。

50 |

一时之间，整个后端和云计算领域的聪明才俊都汇集在了这个“小鲸鱼”的周围，为 Docker 生态的蓬勃发展献上了自己的智慧。

51 |

而除了这个异常繁荣的、围绕着 Docker 项目和公司的生态之外，还有一个势力在当时也是风头无两，这就是老牌集群管理项目 Mesos 和它背后的创业公司 Mesosphere。

52 |

Mesos 作为 Berkeley 主导的大数据套件之一，是大数据火热时最受欢迎的资源管理项目，也是跟 Yarn 项目杀得难舍难分的实力派选手。

53 |

不过，大数据所关注的计算密集型离线业务，其实并不像常规的 Web 服务那样适合用容器进行托管和扩容，也没有对应用打包的强烈需求，所以 Hadoop、Spark 等项目到现在也没在容器技术上投下更大的赌注；但是对于 Mesos 来说，天生的两层调度机制让它非常容易从大数据领域抽身，转而去支持受众更加广泛的 PaaS 业务。

54 |

在这种思路的指导下，Mesosphere 公司发布了一个名为 Marathon 的项目，而这个项目很快就成为了 Docker Swarm 的一个有力竞争对手。

55 |

虽然不能提供像 Swarm 那样的原生 Docker API，Mesos 社区却拥有一个独特的竞争力：超大规模集群的管理经验。

56 |

早在几年前，Mesos 就已经通过了万台节点的验证，2014 年之后又被广泛使用在 eBay 等大型互联网公司的生产环境中。而这次通过 Marathon 实现了诸如应用托管和负载均衡的 PaaS 功能之后，Mesos+Marathon 的组合实际上进化成了一个高度成熟的 PaaS 项目，同时还能很好地支持大数据业务。

57 |

所以，在这波容器化浪潮中，Mesosphere 公司不失时机地提出了一个名叫“DC/OS”（数据中心操作系统）的口号和产品，旨在使用户能够像管理一台机器那样管理一个万级别的物理机集群，并且使用 Docker 容器在这个集群里自由地部署应用。而这，对很多大型企业来说具有着非同寻常的吸引力。

58 |

这时，如果你再去审视当时的容器技术生态，就不难发现 CoreOS 公司竟然显得有些尴尬了。它的 rkt 容器完全打不开局面，Fleet 集群管理项目更是少有人问津，CoreOS 完全被 Docker 公司压制了。

59 |

而处境同样不容乐观的似乎还有 RedHat，作为 Docker 项目早期的重要贡献者，RedHat 也是因为对 Docker 公司平台化战略不满而愤愤退出。但此时，它竟只剩下 OpenShift 这个跟 Cloud Foundry 同时代的经典 PaaS 一张牌可以打，跟 Docker Swarm 和转型后的 Mesos 完全不在同一个“竞技水平”之上。

60 |

那么，事实果真如此吗？

61 |

2014 年注定是一个神奇的年份。就在这一年的 6 月，基础设施领域的翘楚 Google 公司突然发力，正式宣告了一个名叫 Kubernetes 项目的诞生。而这个项目，不仅挽救了当时的 CoreOS 和 RedHat，还如同当年 Docker 项目的横空出世一样，再一次改变了整个容器市场的格局。

62 |

总结

63 |

我分享了 Docker 公司平台化战略的来龙去脉，阐述了 Docker Swarm 项目发布的意义和它背后的设计思想，介绍了 Fig（后来的 Compose）项目如何成为了继 Docker 之后最受瞩目的新星。

64 |

同时，我也和你一起回顾了 2014~2015 年间如火如荼的容器化浪潮里群雄并起的繁荣姿态。在这次生态大爆发中，Docker 公司和 Mesosphere 公司，依托自身优势率先占据了有利位置。

65 |

但是，更强大的挑战者们，即将在不久后纷至沓来。

66 |

思考题

67 |

你所在团队有没有在 2014~2015 年 Docker 热潮中，推出过相关的容器产品或者项目？现在结局如何呢？

68 |

欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

69 |

70 |

71 | 版权归极客邦科技所有，未经许可不得转载 72 |

写留言

精选留言

  • 修炼
    40
    技术一流 还这么会写文章！
    2018-08-30
  • 王江华
    6
    不错，了解docker的来龙去脉，也了解了历史，期待更新
    2018-08-30
  • Backkom
    4
    docker生态维护的很好，这也是发展迅猛的重要原因，得开发者得天下，一如android的发展
    2018-08-30
  • blackpiglet
    2
    我是在15年中接触的docker 和 k8s, 当时公司的目标是做出一个集成 ci cd 的 paas 平台，并统一内部所有项目的开发流程。
    但是投入不大，毕竟小公司，16年我就离开了，不清楚现在产品是否还健在。
    现在回想起来，那时候有了docker 人人都想搞paas，至于公司实际是否需要，考虑的到没有那么仔细。这和现在微服务这波很像。
    2018-08-30
    作者回复

    人人都爱pass，但落地嘛就是另一回事儿了

    2018-08-31

  • @特
    2
    PaaS发展史真的是波澜壮阔。我是2015年底才接触Docker的，2016年初接触mesos和马拉松。结果还没一个月我们项目就黄了，直接换成redhat的解决方案，接下来就入了openshift的坑出不去了😂 那个时候openshift已经出到1.2了。
    2018-08-30
    作者回复

    不妨尝试多学习kubernetes 的基础，openshift作为一个封装 自然也就简单多了

    2018-08-30

  • 李金洋
    1
    老师觉得下一个容器平台的搅局者会是一个什么类型的公司，或者说解决了当前容器圈的什么痛点。感觉k8s已经成为容器圈的标准了，但是复杂性真的挺高
    2018-09-06
    作者回复

    linux复杂性也很高

    2018-09-07

  • 子非鱼
    1
    真是群雄并起，竞争激烈啊，而反观国内…！
    2018-08-31
    作者回复

    国内也很激烈，不过是在商业维度。

    2018-08-31

  • eason2017
    1
    终于到k8s了
    2018-08-30
    作者回复

    别急，咱们先聊容器

    2018-08-31

  • 猿工匠
    1
    过瘾，期待更新😁
    2018-08-30
  • fhchina
    1
    想要了解后续的标准化过程中，Docker分拆出的开源产品与标准的关系与历程，感觉又多又乱
    2018-08-30
  • 尖端科技
    1
    张老师，请教一下docker是否合适用来部署使用gpu这种资源的程序？docker部署的程序是适用于任何的程序部署？有没有啥限制？
    2018-08-30
    作者回复

    在学习了容器技术基础之后，相信你自己自己就能回答这个问题了

    2018-08-30

  • 码字的路人
    0
    很好的了解了 2014-2015的 DOCKER的历程，更好的了解了 什么叫容器 以及一些 容器使用的工具等。
    2018-10-08
  • song
    0
    mesos的两级调度是什么意思，怎么理解，是哪两级？
    2018-10-01
    作者回复

    framework加scheduler，可以看下mesos论文

    2018-10-01

  • 憨先生
    0
    公司是去年开始开发平台级服务，也引入了容器docker的概念，目前一切都还好
    2018-09-27
  • wilson
    0
    目前公司做语音评测，对cpu和内存要求较高，尤其是cpu，敢问，可用docker来跑这种应用吗？
    2018-09-23
    作者回复

    适合

    2018-09-23

  • Kame
    0
    15接触docker，由于各种原因吧、最终没能上生产、只是测试开发，现在k8s出来了，又可以重新搞起
    2018-09-17
  • 换个ID过日子
    0
    看得我热血沸腾！
    2018-09-13
    作者回复

    那就换热血为动力！

    2018-09-13

  • 糖饼饼屋
    0
    14-15年的时候，团队推出过paas项目，技术选型是docker+mesos+ marathon，哎结果不到两年，k8s就已经如火如荼，资源调度技术组件不换都不行……
    2018-09-08
  • sprzhing
    0
    文风很像浪潮之巅，读起来感觉不错
    2018-08-30
  • Cair8
    0
    不过瘾啊，想一口气了解清楚
    2018-08-30
  • 欧文雪
    0
    占个沙发
    2018-08-30
  • 成都福哥
    0
    太少了，不过瘾～～一口气看完了三篇。期待第四篇～～
    2018-08-30
-------------------------------------------------------------------------------- /HTML/16 编排其实很简单：谈谈“控制器”模型.html: -------------------------------------------------------------------------------- 1 | 极客时间 | 深入剖析Kubernetes
讲堂 深入剖析Kubernetes 文章详情

17 | 16 | 编排其实很简单：谈谈“控制器”模型 18 |

2018-09-28 张磊

16 | 编排其实很简单：谈谈“控制器”模型

朗读人：张磊    07′50′′ | 3.60M

你好，我是张磊。今天我和你分享的主题是：编排其实很简单之谈谈“控制器”模型。

19 |

在上一篇文章中，我和你详细介绍了 Pod 的用法，讲解了 Pod 这个 API 对象的各个字段。而接下来，我们就一起来看看“编排”这个 Kubernetes 项目最核心的功能吧。

20 |

实际上，你可能已经有所感悟：Pod 这个看似复杂的 API 对象，实际上就是对容器的进一步抽象和封装而已。

21 |

说得更形象些，“容器”镜像虽然好用，但是容器这样一个“沙盒”的概念，对于描述应用来说，还是太过简单了。这就好比，集装箱固然好用，但是如果它四面都光秃秃的，吊车还怎么把这个集装箱吊起来并摆放好呢？

22 |

所以，Pod 对象，其实就是容器的升级版。它对容器进行了组合，添加了更多的属性和字段。这就好比给集装箱四面安装了吊环，使得 Kubernetes 这架“吊车”，可以更轻松地操作它。

23 |

而 Kubernetes 操作这些“集装箱”的逻辑，都由控制器（Controller）完成。在前面的第 12 篇文章《牛刀小试：我的第一个容器化应用》中，我们曾经使用过 Deployment 这个最基本的控制器对象。

24 |

现在，我们一起来回顾一下这个名叫 nginx-deployment 的例子：

25 | 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
复制代码
26 |

这个 Deployment 定义的编排动作非常简单，即：确保携带了 app=nginx 标签的 Pod 的个数，永远等于 spec.replicas 指定的个数，即 2 个。

27 |

这就意味着，如果在这个集群中，携带 app=nginx 标签的 Pod 的个数大于 2 的时候，就会有旧的 Pod 被删除；反之，就会有新的 Pod 被创建。

28 |

这时，你也许就会好奇：究竟是 Kubernetes 项目中的哪个组件，在执行这些操作呢？

29 |

我在前面介绍 Kubernetes 架构的时候，曾经提到过一个叫作 kube-controller-manager 的组件。

30 |

实际上，这个组件，就是一系列控制器的集合。我们可以查看一下 Kubernetes 项目的 pkg/controller 目录：

31 | 
$ cd kubernetes/pkg/controller/
$ ls -d */              
deployment/             job/                    podautoscaler/          
cloud/                  disruption/             namespace/              
replicaset/             serviceaccount/         volume/
cronjob/                garbagecollector/       nodelifecycle/          replication/            statefulset/            daemon/
...
复制代码
32 |

这个目录下面的每一个控制器，都以独有的方式负责某种编排功能。而我们的 Deployment，正是这些控制器中的一种。

33 |

实际上，这些控制器之所以被统一放在 pkg/controller 目录下，就是因为它们都遵循 Kubernetes 项目中的一个通用编排模式，即：控制循环（control loop）。

34 |

比如，现在有一种待编排的对象 X，它有一个对应的控制器。那么，我就可以用一段 Go 语言风格的伪代码，为你描述这个控制循环：

35 | 
for {
  实际状态 := 获取集群中对象 X 的实际状态（Actual State）
  期望状态 := 获取集群中对象 X 的期望状态（Desired State）
  if 实际状态 == 期望状态{
    什么都不做
  } else {
    执行编排动作，将实际状态调整为期望状态
  }
}
复制代码
36 |

在具体实现中，实际状态往往来自于 Kubernetes 集群本身。

37 |

比如，kubelet 通过心跳汇报的容器状态和节点状态，或者监控系统中保存的应用监控数据，或者控制器主动收集的它自己感兴趣的信息，这些都是常见的实际状态的来源。

38 |

而期望状态，一般来自于用户提交的 YAML 文件。

39 |

比如，Deployment 对象中 Replicas 字段的值。很明显，这些信息往往都保存在 Etcd 中。

40 |

接下来，以 Deployment 为例，我和你简单描述一下它对控制器模型的实现：

41 |
    42 |
  1. 43 |

    Deployment 控制器从 Etcd 中获取到所有携带了“app: nginx”标签的 Pod，然后统计它们的数量，这就是实际状态；

    44 |
    2. 45 |
  2. 46 |

    Deployment 对象的 Replicas 字段的值就是期望状态；

    47 |
    3. 48 |
  3. 49 |

    Deployment 控制器将两个状态做比较，然后根据比较结果，确定是创建 Pod，还是删除已有的 Pod（具体如何操作 Pod 对象，我会在下一篇文章详细介绍）。

    50 |
    4. 51 |
52 |

可以看到，一个 Kubernetes 对象的主要编排逻辑，实际上是在第三步的“对比”阶段完成的。

53 |

这个操作，通常被叫作调谐（Reconcile）。这个调谐的过程，则被称作“Reconcile Loop”（调谐循环）或者“Sync Loop”（同步循环）。

54 |

所以，如果你以后在文档或者社区中碰到这些词，都不要担心，它们其实指的都是同一个东西：控制循环。

55 |

而调谐的最终结果，往往都是对被控制对象的某种写操作。

56 |

比如，增加 Pod，删除已有的 Pod，或者更新 Pod 的某个字段。这也是 Kubernetes 项目“面向 API 对象编程”的一个直观体现。

57 |

其实，像 Deployment 这种控制器的设计原理，就是我们前面提到过的，“用一种对象管理另一种对象”的“艺术”。

58 |

其中，这个控制器对象本身，负责定义被管理对象的期望状态。比如，Deployment 里的 replicas=2 这个字段。

59 |

而被控制对象的定义，则来自于一个“模板”。比如，Deployment 里的 template 字段。

60 |

可以看到，Deployment 这个 template 字段里的内容，跟一个标准的 Pod 对象的 API 定义，丝毫不差。而所有被这个 Deployment 管理的 Pod 实例，其实都是根据这个 template 字段的内容创建出来的。

61 |

像 Deployment 定义的 template 字段，在 Kubernetes 项目中有一个专有的名字，叫作 PodTemplate（Pod 模板）。

62 |

这个概念非常重要，因为后面我要讲解到的大多数控制器，都会使用 PodTemplate 来统一定义它所要管理的 Pod。更有意思的是，我们还会看到其他类型的对象模板，比如 Volume 的模板。

63 |

至此，我们就可以对 Deployment 以及其他类似的控制器，做一个简单总结了：

64 |

65 |

如上图所示，类似 Deployment 这样的一个控制器，实际上都是由上半部分的控制器定义（包括期望状态），加上下半部分的被控制对象的模板组成的。

66 |

这就是为什么，在所有 API 对象的 Metadata 里，都有一个字段叫作 ownerReference，用于保存当前这个 API 对象的拥有者（Owner）的信息。

67 |

那么，对于我们这个 nginx-deployment 来说，它创建出来的 Pod 的 ownerReference 就是 nginx-deployment 吗？或者说，nginx-deployment 所直接控制的，就是 Pod 对象么？

68 |

这个问题的答案，我就留到下一篇文章时再做详细解释吧。

69 |

总结

70 |

在今天这篇文章中，我以 Deployment 为例，和你详细分享了 Kubernetes 项目如何通过一个称作“控制器模式”（controller pattern）的设计方法，来统一地实现对各种不同的对象或者资源进行的编排操作。

71 |

在后面的讲解中，我还会讲到很多不同类型的容器编排功能，比如 StatefulSet、DaemonSet 等等，它们无一例外地都有这样一个甚至多个控制器的存在，并遵循控制循环（control loop）的流程，完成各自的编排逻辑。

72 |

实际上，跟 Deployment 相似，这些控制循环最后的执行结果，要么就是创建、更新一些 Pod（或者其他的 API 对象、资源），要么就是删除一些已经存在的 Pod（或者其他的 API 对象、资源）。

73 |

但也正是在这个统一的编排框架下，不同的控制器可以在具体执行过程中，设计不同的业务逻辑，从而达到不同的编排效果。

74 |

这个实现思路，正是 Kubernetes 项目进行容器编排的核心原理。在此后讲解 Kubernetes 编排功能的文章中，我都会遵循这个逻辑展开，并且带你逐步领悟控制器模式在不同的容器化作业中的实现方式。

75 |

思考题

76 |

你能否说出，Kubernetes 使用的这个“控制器模式”，跟我们平常所说的“事件驱动”，有什么区别和联系吗？

77 |

感谢你的收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

78 |

79 |

80 | 版权归极客邦科技所有，未经许可不得转载 81 |

写留言

精选留言

  • jasine
    22
    除了上面朋友提到的主动与被动区别，事件往往是一次性的，如果操作失败比较难处理，但是控制器是循环一直在尝试的，更符合kubernetes申明式API，最终达到与申明一致，这样理解对吗
    2018-09-28
    作者回复

    厉害。这个就说到点子上了。

    2018-09-28

  • melon
    5
    相当于select和epoll的区别
    2018-09-28
    作者回复

    太专业啦

    2018-09-28

  • 小小笑儿
    4
    deployment会创建rs,然后由rs创建pod,所以pod的owner应该是rs？
    2018-09-28
    作者回复

    明白人。

    2018-09-28

  • Anker
    3
    控制器模型是在一个循环中主动收集各个pod的运行状态，预先知道自己要处理哪些模块，然后比较状态来触发对应的操作，有点像有序同步操作。
    事件驱动模型是一个异步回调过程，各个模块向控制器注册好事件方法，当模块自己检测到事件发生了，则将事件添加到控制器处理队列，控制器不关心各个模块状态，只关心队列中是否有事件。
    请指正。
    2018-09-28
  • Vincen
    2
    后面文章会讲watch机制吗？
    2018-09-28
    作者回复

    会的

    2018-09-28

  • 包子
    2
    控制器主动获取pod状态，在这个集群中，有那么多pod，某个pod在某一时刻状态有变，怎样及时通知到控制器呢？
    2018-09-28
    作者回复

    informer机制，后面会讲到

    2018-09-28

  • 蜗牛
    1
    有一个疑问没太弄清楚, 比如Deployment, 是我创建一个Deployment 就会生成一个对应的 Deployment-Controller 实例来管理该它 还是整个k8s系统只有一个 Deployement-Controller 来同一管理该系统的所有Deployment呢?
    2018-10-07
    作者回复

    当然只有一个controller

    2018-10-08

  • Spark
    1
    老师，我是初学者，这个课程让我获益匪浅，但每次都有很多问题想问但无人解答。请问能不能建一个交流群，大家共同讨论学习。
    2018-09-29
    作者回复

    极客时间好像马上要上线这个功能

    2018-09-29

  • 龙坤
    1
    老师，大概可以这样理解吧。一个是主动，一个被动
    “事件驱动”，对于控制器来说是被动，只要触发事件则执行，对执行后不负责，无论成功与否，没有对一次操作的后续进行“监控”
    “控制器模式”，对于控制器来说是主动的，自身在不断地获取信息，起到事后“监控”作用，知道同步完成，实际状态与期望状态一致
    2018-09-28
    作者回复

    基本正确。

    2018-09-28

  • A-
    1
    我理解：
    事件驱动是被动的：被控制对象要自己去判断是否需要被编排，调度。实时将事件通知给控制器。
    控制器模式是主动的：被控制对象只需要实时同步自己的状态(实际由kubelet做的)，具体的判断逻辑由控制去做。
    不对请指正
    2018-09-28
    作者回复

    基本正确，还可以再深入

    2018-09-28

  • jimmy
    0
    命令式api和声明式api的区别
    2018-10-18
  • Jeff.W
    0
    唯一的不变就是变化本身，你所看到的稳定不变的状态，都是有人在默默付出的。pod的稳定状态，背后控制器的默默奉献～
    2018-10-15
  • chf007
    0
    我可以先写Pod，再写Deployment，不写 template，只靠标签控制 Pod 么？

    K8s只靠标签进行match控制，如果万一写错便签会不会直接调度了以前就存在的Pod，但是 不是我想要操作的 Pod 呢？

    2018-10-10
    作者回复

    不可以，控制器需要使用模版。的确会有重合的可能。

    2018-10-10

  • 广宇
    0
    控制器的作用是确保对象处在所定义的状态上，这跟很多运维自动化工具中的概念是类似的，确保一致性，不一致的要回归收敛到一致。
    2018-10-06
  • 北卡
    0
    对于十一还在上班的我，摸鱼时间看这套教程让我感到了莫大的快乐。
    2018-10-02
  • Leon廖
    0
    “事件驱动”是一种宽松的侧重于事件的传播通知模式，并不涉及对通知处理模式的定义。而控制器模式定义了对预期状态和期望状态的通用处理模式。控制器模式可以利用“事件驱动”模式来收集状态信息。
    2018-09-30
  • 陈华
    0
    终于追上来了，哈哈哈哈，
    2018-09-30
  • eason2017
    0
    一口气跟上来了，哈哈😄，十一蜗居好好咀嚼一下
    2018-09-30
    作者回复

    劳逸结合

    2018-09-30

  • 付盼星
    0
    老师，用deployment部署之后，副本数还可以再调整么？
    2018-09-29
    作者回复

    看下一篇的内容

    2018-09-29

  • 择动
    0
    老师，明白人说明白之后，我想明白deployment的owner又是谁？
    2018-09-28
    作者回复

    这个字段可以为nil啊

    2018-09-28

--------------------------------------------------------------------------------