前言
云原生的概念最近非常火爆，企业落地云原生的愿望也越发强烈。看过很多关于云原生的文章，要么云山雾罩，要么曲高和寡。 所以笔者就有了写《大话云原生》系列文章的想法，期望用最通俗、简单的语言说明白云原生生态系统内的组成及应用关系。那么，开始吧，这是第一篇！
这真的是一篇讲架构技术的文章，不是小说！建议您看下去！
一、周末煮饺子聊到容器问题
周末和老婆一起包了顿饺子，“老公，我去买瓶醋，你把饺子先煮一下吧”。我笨手笨脚准备半天，还没煮完，老婆就回来了。我看着这一锅饺子问道：“老婆，你说这 饭店是怎么煮饺子的啊？ 每个人口味不一样，饭量也都不一样啊，想想都头疼！”
小娜同学一边用手比划一边说：“饭店当然不能像家里这么煮饺子啊，他们有一种特制的锅，就是那个、那个样子的”。
我感觉自己娶了一个傻女人，“到底是哪个样子的？用手能比划出来啊？你是不是爱情公寓看多了？”。老婆听到我的抱怨，拿起手机搜索了一下：“诺，就是这个样子的，你个白痴！”
“饭店就是用这种锅煮饺子的，水是一锅水，炉是一个炉，分成多个容器，每个容器里面放入一个客人点的饺子就可以啦。”作为生活小能手的小娜同学知道的可真多。
“哎我去，这不就是一个服务器启动了多个docker容器么？”同样作为程序员的小娜赞到：“老公，你说的还真对哈，我最近可是刚看了docker呢，但我还不太会用！”。
二、说说docker与煮饺子的容器
“你一个前端学什么docker”。小娜不服气了，“哎，你别瞧不起人，我还知道k8s呢”。这可让我有点意外，正当我意外之时，老婆一句话差点让我喷出来：“那k8s到底是个什么东西啊？”，我们商量好饭后她刷碗，我给她说说docker与k8。
不一会就开始了饭后辅导： 饭店煮饺子本身就是一种服务（应用服务），煮饺子的锅就像一个服务器，锅里的每一个网状笼就像一个docker容器，通常情况下一个网状笼只煮一种饺子，就像一个docker容器通常只提供一个服务（微服务）。同一个服务器上的docker容器之间能够进行必要的隔离，避免资源冲突（不同馅的饺子煮混）。又能充分的共享服务器资源（那一锅水和供电），达到资源的合理利用，避免浪费。
小娜微笑点点头表示明白了，”那饭店规模变大，客人越来越多，就得买更多的大锅（服务器）啊？"
那是当然喽，你看哈，当服务器越来越多的时候就组成了集群。docker容器还有一个好处就是它的标准化，标准化在这里就代表了部署灵活性。假如一号锅突然断电了，煮饺子的师傅就可以把煮饺子的容器拔出来插入二号锅，因为容器的标准是一样的。就像docker容器可以灵活快速的启动，在不同的服务器上启动提供服务。
小娜同学再次的点了点头，向我投来仰慕的眼光。趁热打铁，我总结道：”docker容器有效的实现了服务的环境封装的标准化，以及同服务器容器之间的环境隔离，资源共享“。
三、聊聊集群煮饺子（k8s）
小娜同学对于接下来的内容已经迫不及待了，“docker我懂了，快说说k8s”。我故弄玄虚的说到，你看哈，现在这个饭店的集群容器煮饺子的模式还需要解决哪些问题？我们俩讨论了一下，总结了下面这几条：
- 饭店的客流量不总是满的，大锅的个数肯定是按照最大需求买的，但是肯定有部分的时间大锅是闲置的。
- 客流量肯定是有一定的规律的吧？比如周末比工作日客流量大，下班后比上班时间客流量大。
- 假如突然来了一个旅游团进来用餐，谁来做应急管理？快速的给大锅插电？烧水？满足用餐需求？
- 如果为了避免煮出来的饺子味道混淆，是不是素馅类不同容器的放到一个大锅里面煮？肉馅的放在一起煮、海鲜馅的放在一起煮会好一些？
- 是不是得有人定期的对“大锅”和大锅里面的容器进行卫生检查、运行状态(健康检查)？
- 是不是得有一个人清楚的知道，素馅的一两饺子是唐僧的，肉馅的四两饺子是猪八戒的？
其实还有很多需要注意的问题，所有的这些都可以归纳为：任务分配或者是服务编排，或者是容器的编排问题。k8s的主要作用就是用来解决类似这样的一些问题：
- 根据访问量大小快速的对容器数量进行扩容、缩容。
- 遵循一定的预定计划来执行容器编排工作、应急管理工作、健康检查工作
- 合理的编排容器，有些容器放在CPU密集型的服务器上，有些容器放在内存密集型容器上。毕竟有的容器运行的是计算型微服务，有的容器运行的是耗内存的微服务。合理的编排能够达到资源的最大利用率。
以上等等这些进行容器管理、编排的问题，都需要k8s来管理支撑，而且是自动化支撑。 说到这里，小娜同学若有所思，“我听是听明白了，但是感觉这东西好庞大、好复杂啊。开发一个应用放在一起部署不好么？为什么搞这么复杂？”
还别说，小娜同学还真问道点子上了。但这也不能一次全都讲完啊，否则明天的碗谁来刷？
以上就是煮饺子论云原生docker与kubernetes之间的关系的详细内容，更多关于云原生docker与kubernetes的资料请关注编程网其它相关文章！
