我们从来没有遇到这种事情：以前不管使用什么系统，即使出现各种运行错误，也很容易处理。但是，现在我们需要建立专门的章节，来学习 Kubernetes 相关的排错与调试内容（也许是我们以前使用的东西太简单了）。而且在 Kubernetes 官方文档中关于排错调试的内容远多余我们用过的其他服务，从来没见过哪个工具服务有这么多排错及调试相关的文档 ：-）。不过这也很正常，虽然 Kubernetes 的很多新概念，但是底层的 Docker IPVS iptables PKI Storage 等等技术都是建立在已有技术的基础之上，这么多技术粘合在一起，出现各种错误也是相当正常的。所以 Kubernetes 的使用是件简单的事情，通过阅读官方文档即可，但是维护、排错、调试可不简单；

鉴于此，我们创建该章节，专门用来学习和记录与 Kuberntes 排错及调试相关的内容。比如 Pod 为什么处于 Pending 状态、Pod 为什么会重启、apiserver 为什么会退出、etcd 为什么会突然重新选举……各种各样的问题；

集群使用感悟

# 04/10/2019 难点不在于应用，而在于问题处理；

在应用方面，由于多数东西都存在于官方文档上，在使用方面没有太大难度。通过阅读官方文档，可以顺利进行使用，无非是用的好、用的坏、是否是最佳实践方面的问题；

真正难的地方在于维护及问题处理。要想处理集群发生的问题，尤其是突发问题，就要深入理解系统各组件之间的协作关系。与以往我们使用的程序不同，它更像是一个集成系统。我们以往使用的应用，比如监控、日志等等，架构简单且常规，无非就是服务端、客户端，网络、防火墙、权限之类的技术。但是 Kubernetes 不一样，它是一个集成系统，它将很多东西柔合在一起。基础知识方面，需要掌握容器、IPVS、防火墙、证书。除了基础知识，还有 Kubernetes 内部所使用的一些概念；

随着我写下的这一段内容，我也渐渐意识到这是运维知识体系的变革。传统应用管理及问题处理，基本遵循相同的模式，客户端、服务端，不管怎么弄，都没有跳出这个模式。但是 Kubernetes 不一样，它通过各个组件来操作底层组件（防火墙、路由、存储）。以前又有多少应用程序会去操作防火墙呢？又有哪个应用程序在使用 IPVS 呢？