在这个专题的开篇中提到，妹子小X由于错误地回答了关于容器运行时(docker runtime)的一个问题，在应聘H厂云计算相关的岗位时，倒在了第一轮。
由于小X贿赂了方老师若干好吃的，方老师想办法问到了导致小X挂掉的面试评价：对Kubernetes的核心理念缺乏基本认知。
方老师为了让大家更好地理解容器运行时的概念，决定还是从基础讲起。
我们知道，如果小X想在Linux下，启动一个运行着ubuntu的容器，只需要如此这般——
代码语言：javascript复制tianjifang@ubuntu:~$ sudo docker pull ubuntu
tianjifang@ubuntu:~$ sudo docker run -it ubuntu这两条命令的作用是，从镜像仓库拉取ubuntu的镜像，并运行该镜像。
这样，在Linux上就启动了一个运行了ubuntu的实例。
同样地，我们还可以从docker hub拉取busybox、elasticsearch、apache httpd、mysql等不同的中间件的镜像，并在本地启动一个运行在容器中的实例。
重点：
docker等容器运行时引擎，交付的是应用的单个实例，及其所依赖的运行时库。
让我们与虚拟机进行一个对比：
如果小X希望启动一个在虚拟机环境中运行的MySQL实例，小X需要做以下步骤：
1、通过操作系统镜像创建虚拟机(假设是CentOS 8.0)；
2、给操作系统打所需的补丁，将Selinux、iptables等安全设置配置妥当；
3、部署并配置MySQL；
4、运行MySQL；
这些冗长的重复性工作通常是无法避免的。因为，虚拟机运行时系统，实际上交付的是这些东西的叠加：
应用；
应用所依赖的运行时库；
操作系统；
显然，容器比起虚拟机来，无需交付最重量级的操作系统，类似把带着包装盒的精装书变成了可以存储在kindle里面的电子书，可以方便地带着出差啦。
而有了docker后，小X只需要在Linux服务器上执行两条命令即可快速启动MySQL实例了。
类似地，小X还可以快速部署前端的nginx, 应用servlet等，从而快速交付一个B/S架构的APP。
显然，docker及docker hub生态，大大地提升了应用交付的生产力水平。
然而，让我们再次回味这句话——
docker等容器运行时引擎，交付的是应用的单个实例，及其所依赖的运行时库。
实际上，我们真正需要为用户交付的是“应用”，而并不是“应用的单个实例”！
让我们举一个栗子。
以P站为例，假设P站由nginx, tomcat和mysql三种组件构成。
某天，某条香艳而劲爆，涉及娱乐八卦和国际局势交叉领域的消息，冲上了P站的热搜榜。
这件事情导致P站的访问量飙升10倍，显然，前端运行着Nginx的容器性能显著不足，响应迅速变慢。
警报传来，工程师们本来在温泉度假村享受着长假的美好，赶紧不顾一切地穿着只有精通容器技术的人才能看见的衣服，趴在池沿，拉起更多的Nginx容器，帮助P站handle这个突发的issue。
由于小X是妹子，不方便在这种工作环境下保证快速响应前端需求，虽然哭求希望留下，还是被淘汰了。
这是一场悲剧。让我们把时光机倒回到特没谱感染新冠的前一星期——
假设小X学习了Kubernetes并且在P站部署了基于Kubernetes的生产系统，小X的心情肯定是不一样的：
明天，让我们详解为什么Kubernetes能让小X元气满满地应对xiaozhan把trump那啥了以后引发的国际形势危机——
