因为工作需要，开始了解了 k8s 的东西。虽然到现在为止，个人使用时基本用不上，但 k8s 背后的思想还是充满趣味。所以开了新坑，主要是我了解 k8s 时的感悟。（所以不一定全都是对的）
要谈论一个东西，我总是想先聊聊它的历史。知道它为何而生，知道历史局限，抛开局限的部分，看到其内核所在，然后融会贯通，取其精华，去其糟粕。
容器为何而生？
如果说集装箱是人类伟大的奇迹，那么容器技术就是计算机软件服务的伟大奇迹。
在容器诞生前，在部署一个服务时，总会遇到这么几个问题：
- 库依赖不全
- 开发人员不了解部署环境
- 开发环境和生产环境不一致
- 依赖冲突
上面几个问题都可以简单归纳为环境依赖问题。为了解决环境依赖，我们有两个选择，一是找人专门管理环境，即招人；另一种办法就是模拟出环境，也就是容器技术和虚拟机技术(Virtual Machine)。
所谓容器，可以理解为一个轻量的虚拟机，但它与 VM 不同的是，它更轻量。可以看下图的对比。
从第一副图中，我们可以看到相比容器，VM 多了一层 Guest OS。这一块是指 VM 需要运行的系统程序。因为每一个 VM 都要运行着自己一套系统服务，因此增加了很多机器资源成本。同时，在配置这些 VM 的过程中，我们也需要更多的维护人员，同时增加了人力资源成本。
第二张图中。我们可以看到，每个虚拟机都有自己的内核，当我们宿主机发送指令到 VM 时，需要转换成对应的机器的 CPU 指令，降低效率。
还有很重要的一点，因为容器是运行在同一台机器上，它不需要像虚拟机一样，有复杂的启动流程。因此它可以很快的运行、中止、关闭。也正因为这点，k8s 才可以做到相当流畅的编排功能。
当然，这些并不意味着 VM 毫无用处。因为容器使用的是同一个宿主机，因此当出现问题时，所有的服务都面临着相同的安全风险。因此，选择容器还是 VM 还是得看自己的需求。
容器的使用中遇到了什么问题？
上面说了一堆容器的优点，不意味着容器就完美无缺。因为容器只是一种基础工具，在实际生产工作中，我们依然会遇到一些新问题。
- 如何保证一组容器正常运行
- 怎样方便的拓展，如何让容器自行拓展
- 容器拓展、重启后如何保证外部服务能正常联系
- 如何管理分布在多台机器上的容器
这些问题我会在后续的文章中一点一点地回答。
k8s 只是容器集群的管理工具
Kubernetes（常简称为K8s）是用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用。
正如 wiki 所说，k8s 不是用来替代容器，而是用于实现自动化，扩展和管理容器的系统。（你也可以把它理解为 Erlang 的 OTP）
k8s 可以通过配置文件，自动为容器找到适合的宿主机。前面提到容器时，我们默认只有一台机器。但实际上，我们可以组合多台机器，形成一个容器集群，每台机器可以有着不同的软硬件配置。当一个容器想要每次部署在有 SSD 机器上，那么 k8s 可以帮我们完成这一动作。
k8s 还可以帮我们管理容器的健康状态。有些问题会导致容器挂掉，有的问题却不会。前者我们可以利用容器服务自动重启，比如 docker –restart；后者则需要一些监控方案，比如连不上数据库，或者是 web 服务出现 500，这些并不会触发 –restart，而且问题也不明了，那么 k8s 可以帮助我们监控这些问题，重启就好了。（重启其实是修改部分计算机错误的好办法，以后我会写文章来聊聊这个问题）
当然，k8s 还有很多优点，比如可以根据机器状态自动扩缩容，服务查找，多个容器配置修改等等。这些优点会在之后的文章里做更详细的解读
但无论如何，k8s 只是管理工具，把它当成一个工具学习就好了。