本篇作为上一篇mysql指引（三）：mysql线程处理模型 的一个短篇补充，站在某种角度简要来说明下线程与操作系统的联系，以及和容器与K8S的联系做对比看下。
图中，直接忽略了进程，认为线程是操作系统调度的最小单位。
站在设计者的角度，当编写好程序后，不论是否显示的创建线程，我们的所有代码肯定是运行在同一个线程或者多个线程上的（视代码如何编写）。当程序运行起来后，就和我们无关了。
站在线程的角度，设计者对于线程的作用就是声明了线程的功能，即给这个线程指派了任务。但是这个线程具体如何执行，如何完成这些任务，就需要操作系统的管理。
站在操作系统的角度，线程就是系统要管理的最小工作单元。操作系统要尽力保证利用目前的硬件资源（CPU、内存等）来执行这些线程，也就是通过硬件资源的调度，来让线程认为它是独立运行的，即认为是独享这些硬件资源。
站在这样的角度，再回顾上文提到的 One-Thread-Per-Connection 模型，每个连接都创建一个线程来管理。那么操作系统需要管理这么多的线程，但是硬件资源就这么点，线程单元却有这么多个，操作系统需要耗费非常大的精力来保证管理和调度的正常运行。
但是采用了其他并发模型，线程数大大减少，操作系统的管理和调度压力也会变小，线程工作单元也会更加高效。
同理，对于近三年大热的K8S 和 Docker 容器来说，他俩之间的关系也可以套用到这张图中，简单的套用见下图：
所以我们也可以把 K8S 称作为 云操作系统 。跑在K8S上的应用也可以叫做云原生应用。
K8S负责对容器进行管理，负责对资源进行调度，也就是让容器应用认为独享了资源，所以也可以叫做 容器编排 。
而设计者开发好容器应用后，只需要告诉K8S这个容器该以何种方式运行在K8S集群上，比如运行两个副本等。设计者设计运行规则的这步就是 声明式编排，制定好运行计划，然后 K8S 按照计划去运行。
这样看来，会大大解放设计者的运维工作，并且可以更好的调度各种云端资源。
大大解放设计者的运维工作，并且可以更好的调度各种云端资源。
未来K8S只会越来越主流，越来越好。
