前言：云原生的概念最近非常火爆，企业落地云原生的愿望也越发强烈。看过很多关于云原生的文章，要么云山雾罩，要么曲高和寡。 所以笔者就有了写《大话云原生》系列文章的想法，期望用最通俗、简单的语言说明白什么是云原生。那么，开始吧，这是第一篇！

这真的是一篇讲架构技术的文章，不是小说，不是口水！建议您看下去！

一、周末煮饺子

周末和老婆一起包了顿饺子，“老公，我去买瓶醋，你把饺子先煮一下吧”。我笨手笨脚准备半天，还没煮完，老婆就回来了。我看着这一锅饺子问道：“老婆，你说这饭店是怎么煮饺子的啊？每个人口味不一样，饭量也都不一样啊，想想都头疼！”

小娜同学一边用手比划一边说：“饭店当然不能像家里这么煮饺子啊，他们有一种特制的锅，就是那个、那个样子的”。我感觉自己娶了一个傻女人，“到底是哪个样子的？用手能比划出来啊？你是不是爱情公寓看多了？”。老婆听到我的抱怨，拿起手机搜索了一下：“诺，就是这个样子的，你个白痴！”

“饭店就是用这种锅煮饺子的，水是一锅水，炉是一个炉，分成多个容器，每个容器里面放入一个客人点的饺子就可以啦。”作为生活小能手的小娜同学知道的可真多。“哎我去，这不就是一个服务器启动了多个 docker 容器么？”同样作为程序员的小娜赞到：“老公，你说的还真对哈，我最近可是刚看了 docker 呢，但我还不太会用！”。

二、说说 docker 与容器

"你一个前端学什么 docker"。小娜不服气了，"哎，你别瞧不起人，我还知道 k8s 呢"。这可让我有点意外，正当我意外之时，老婆一句话差点让我喷出来："那 k8s 到底是个什么东西啊？"，我们商量好饭后她刷碗，我给她说说 docker 与 k8。

不一会就开始了饭后辅导： 饭店煮饺子本身就是一种服务（应用服务），煮饺子的锅就像一个服务器，锅里的每一个网状笼就像一个 docker 容器，通常情况下一个网状笼只煮一种饺子，就像一个 docker 容器通常只提供一个服务（微服务）。同一个服务器上的 docker 容器之间能够进行必要的隔离，避免资源冲突（不同馅的饺子煮混）。又能充分的共享服务器资源（那一锅水和供电），达到资源的合理利用，避免浪费。

小娜微笑点点头表示明白了，”那饭店规模变大，客人越来越多，就得买更多的大锅（服务器）啊？"

那是当然喽，你看哈，当服务器越来越多的时候就组成了集群。docker 容器还有一个好处就是它的标准化，标准化在这里就代表了灵活。假如一号锅突然断电了，煮饺子的师傅就可以把煮饺子的容器拔出来插入二号锅，因为容器的标准是一样的。就像 docker 容器可以灵活快速的启动，在不同的服务器上启动提供服务。

小娜同学再次的点了点头，向我投来仰慕的眼光。趁热打铁，我总结道：”docker 容器有效的实现了服务的环境封装的标准化，以及同服务器容器之间的资源隔离，资源共享“。

三、聊聊 k8s

小娜同学对于接下来的内容已经迫不及待了，"docker 我懂了，快说说 k8s"。我故弄玄虚的说到，你看哈，现在这个服务器集群+docker 容器的方式还有什么问题？我们俩讨论了一下，总结了下面这几条：

• 饭店的客流量不总是满的，大锅的个数肯定是按照最大需求买的，但是肯定有部分的时间大锅是闲置的。

• 客流量肯定是有一定的规律的吧？比如周末比工作日客流量大，下班后比上班时间客流量大。

• 假如突然来了一个旅游团进来用餐，谁来做应急管理？快速的给大锅插电？烧水？满足用餐需求？

• 如果为了避免煮出来的饺子味道混淆，是不是素馅类不同容器的放到一个大锅里面煮？肉馅的放在一起煮、海鲜馅的放在一起煮会好一些？

• 是不是得有人定期的对“大锅”和大锅里面的容器进行健康检查？

• 是不是得有一个人清楚的知道，素馅的一两饺子是唐僧的，肉馅的四两饺子是猪八戒的？

其实还有很多需要注意的问题，所有的这些都可以归纳为：任务分配或者是服务编排，或者是容器的编排问题。k8s 的主要作用就是用来解决类似这样的一些问题：

• 根据访问量大小快速的对容器进行扩容、缩容。

• 遵循一定的预定计划来执行容器编排工作、应急管理工作、健康检查工作

• 合理的编排容器，有些容器放在 CPU 密集型的服务器上，有些容器放在内存密集型容器上。合理的编排能够达到资源的最大利用率。

等等这些进行容器管理、编排的问题，都需要 k8s 来支撑，而且是自动化支撑。 说到这里，小娜同学若有所思，“我听是听明白了，但是感觉这东西好庞大、好复杂啊。搞一个应用部署不好么？为什么搞这么复杂？”

还别说，小娜同学还真问道点子上了，但这也不能一次全都讲完啊，否则明天的碗谁来刷？