前言

最近在读的一本书籍：《Kubernetes in Action 中文版》，豆瓣评分 9.1，恰好部门的自研 Paas 平台架构就是 Kubernetes。其实相关书籍资料非常多，比较经典的还有《Kubernetes 权威指南》，豆瓣评分也是颇高。

本文是读书笔记的第 3 节，可以回顾此前的内容：

《Kubernetes in action 读书笔记》：运维架构演进

《Kubernetes in action 读书笔记》：容器技术的发展

《Kubernetes in action 读书笔记》：Kurbernetes 横空出世

《Kubernetes in action 读书笔记》：Kurbernetes 架构设计

Kubernetes 给我们带来了哪些实实在在的好处呢？

1、k8s 给运维人员简化了应用程序部署

运维人员会更加关心应用程序运行在哪种硬件上。

举例子：应用程序在 HDDs 上面运行一般，而在 ssd 上运行良好；

• 没有使用 k8s，运维要挑选一个具有 SSD 的特点服务器节点，然后部署某个应用；

• 使用 k8s，运维只需要在容器描述上面注明“需要 SSD”的特征节点，那么 k8s 会自动部署到某一特点节点上；

2、k8s 给开发人员简化了应用程序开发

开发者在开发应用时，偶尔会查询环境变量或者 DNS 查询，来发现其他服务应用并完成通信。

k8s 给我们提供了这种便捷，开发者可以通过查询 Kubernetes API 服务器，获取必要信息和其他信息。

3、k8s 更懂硬件资源的最优部署方案

Kubernetes 能更加应用程序的资源需求描述，和每个节点的可用资源，最终选择合适的节点来跑应用程序。（人工在许多应用程序组件和服务器节点，寻找最优解是非常累的且不可控的，交给计算机更加明智）

4、k8s 更懂应用程序组件的健康检查和自我修复

举例子：前几天 test 环境的某个容器应用，由于 JVM 的内存配置太小了，导致启动之后的十分钟内出现了 OOM；等到我们去排查问题时，已经发现该节点的容器已经被重启十几次了。

从例子中可见，k8s 能够监控应用程序组件和它们运行的节点，在节点出现故障时，自动将应用重新启动或者动态部署到其他节点。（人工监控一台服务器的各种指标，是非常累而且风险不可控的，自动化是一个不错的选择）

5、k8s 更懂应用程序组件的扩容

举例子：前天下午 5 点，运维团队告诉我们服务的可用性降低了，我们火急火燎定位到某个应用的 QPS 达到了 8000，而平时只有 QPS 才 2000；组长决定了去对这个应用进行扩容，很快该应用容器扩容到了 10 个，总算 hold 住了短期的突发负载峰值。

从例子可见，如果不是使用 k8s，我们的运维同学就得重复 10 次部署应用的操作，先不说是否完全准确无误，但这里面的时间消耗就远不止 10 分钟左右的事情了。

6、总结

Kubernetes 提供了一个非常强大的容器平台，通过 Kubernetes 自动地处理故障节点，开发和运维可以睡得更好。

题外话

虽然，动态扩容能够抵挡一阵子负载峰值，但也造成了一个副作用，那就是让 Mysql 的长连接数量翻了几倍。这时候要对 Mysql 进行高可用了，这也是题外话。

7、Kubernetes 实战环节

未完，待续..