机缘

本文旨在帮助朋友们能快速定位、以最简单可行只法解决遇到的问题，希望您能举一反三，篇幅有限不能详尽，见谅 (*^__^*)

内容概括：

1. 实战项目经验
   如何有效减少排查解决问题的时间？尤其是有些问题解决，需要停服务，会影响关联的业务。
2. 遇到的问题实用解法
3. 扩展延伸

一、 实战项目经验

提示：意识理念很重要，所以先要保证遵守原则不变，才能处变不惊，最高效解决问题。我总结了三原则

原则：

1. 勿求快，多想一步，多问一句 即便是感觉很小的操作，也要考虑到可能发生意料外之事，我们之前出现过几次类似问题，都是同一种方法解决的，同样的情况出现，可是这次，背景不一样，用相同的方法，不但没解决问题，还制造了新问题，欲速不达。
2. 要全面了解 正向的反馈，不利的反馈都要听，提前做些努力，想出应对之法，做的时候会特别顺畅，高效。
3. 不光多看运维文档，而且要用心观察 遇到一个问题，我们费了好大力气，花费时间不少，想最快解决，却找不到参照方法。等静下心，我发现运维文档的预案里明明就有，当时为什么就视而不见，现在想想，这类问题发生的次数少，而且平时这个文档阅读的少，而且是粗略的看。

二、遇到的问题实用解法

提示：当前创作和你的工作、学习是什么样的关系
例如：

1. 节点NotReady
   
   图1 命令返回信息显示节点异常

简单问题：可以一条命令看到，程序dead状态，直接启动即可。

1）kubelet进程异常
执行查看命令：systemctl status kubelet.service
执行启动命令：systemctl start kubelet.service

2）docker进程异常
执行命令：systemctl status docker.service
执行启动命令：systemctl start docker.service

复杂问题：需要执行多条命令，并和其他部门同事沟通确认情况，综合分析协助定位问题并解决。

依然是NodeReady报错：
第一步：执行上面两个查看服务状态命令，返回信息显示无异常；
第二步：执行kubectl describe nodes node01（异常节点名） | grep Events
在事件列信息里确认是哪里出现问题，如果显示和docker有关，则证明还是“docker进程异常”，但是状态并没有死掉。
第三步：docker为什么会异常？因场景而异，有的时候是承载docker的节点物理内存不足，导致进程被杀死，或没被杀死，不能提供正常运行及处理任务所需内存。
第四步：想办法释放节点内存，重启docker服务。

2. pod异常状态

1)镜像下载失败：ImagePullBackOff

简单问题：镜像仓库异常或pod的镜像仓库配置项不正确。
解决方法：执行kubectl describe nodes node01（异常节点名） | grep Events，进一步确认是不是这个问题，或者是不是还有其他问题。docker images本地可以查看到镜像，则需要将其执行：docker push ip:port/soft:v1.0将其推送到私有远程仓库，如果用pod控制器创建的可以删除pod，自动创建方式实现重建pod。如果还是不成功，可能也有网络问题，需要手动导入docker.tar包文件，执行docker load即可。

2）pod状态为Error、Unknown

小知识：pod稳定态为Running、Error、Unknown，其余都是中间态；稳定态是一般情况不会变化了，此状态可能原因是镜像下载的次数超了配置的次数，不再尝试重试，返回的状态。

解决方法：一般是配置问题，如：请求的资源超过了管理员设置的限制。执行下面三条命令：
kubectl get pod -o yaml 与正常的pod对比确认 Pod 的配置是否正确
kubectl describe pod 查看 Pod 的事件
kubectl logs [-c ] 查看容器日志
此外，Unknown也可能是网络问题导致。多个应用部署在不同节点需要交互。

三、扩展延伸

提示：对基础知识了解的越透彻，k8s运行逻辑越清楚，越能快速定位问题，解决问题。
例如：

1. k8s网络小知识
   
   图2 k8s网络拓扑

   从微观来分：

1）容器间通信 例如：docker与docker
2）pod间通信
3）服务到pod通信 例如：service到pod

从宏观来分：

1）pod间通信 pod1和pod2属于同主机；pod1和pod3属于跨主机
2）Node与pod间通信 Node1和pod1/pod2属于同主机；Node1和pod3属于跨主机

跨主机通信，需要借助第三方网络插件，如：Flannel等