应用程序故障排查
常见问题
这里常见的问题，更新在 K8S 项目的 Github 的 常见问题 页面
故障诊断
故障排查时的第一步是给故障进行分类:
- Pods 的故障
- ReplicationControllers的故障
- Services的故障
排查 Pod 的故障
检查Pod的问题首先应该了解Pod所处的状况。下面这个命令能够获得Pod当前的状态和近期的事件列表：
1 | kubectl describe pods ${POD_NAME} |
确认清楚在Pod以及其中每一个容器的状态，是否都处于Runing？通过观察容器的已运行时间判断它是否刚刚才重新启动过？
Pod 始终处于Pending状态
如果 Pod 保持在 Pending 状态 ， 这意味着 它 无法被正常调度到一个节点上。 一般来说： 这是因为某种系统资源无法满足 Pod 的运行的需求。 我们需要观察 kubectl describe 的打印出来的内容，这里面是包括了错误的原因的:
- 系统没有足够的资源：需要清理一些不必要的 Pod ,调整 它们的 所需的资源，或者 往集群增加新的 节点。
- 用户指定了 hostPort: 通过hostPort用户能够将服务暴露到指定的主机端口上，但这样会限制Pod能够被调度运行的节点。在大多数情况下，hostPort配置都是没有必要的，用户应该采用Service的方式暴露其对外的服务。如果用户确实必须使用hostPort的功能，那么此Pod最多只能部署到和集群节点相同的数目。
Pod始终处于Waiting状态
Pod处在Waiting的状态，说明它已经被调度分配到了一个工作节点，然而它无法在那个节点上运行。同样的，在刚才kubectl describe命令的输出内容中，应该包含有更详细的错误信息。最经常导致Pod始终Waiting的原因是无法下载所需的镜像（译者注：由于国内特殊的网络环境，这类问题出现得特别普遍）.
Pod一直崩溃或运行不正常
首先查看日志:
1 | kubectl logs <Pod名称> <Pod中的容器名称> |
如果容器之前已经崩溃过，通过以下命令可以获得容器前一次运行的日志内容
1 | kubectl logs --previous <Pod名称> <Pod中的容器名称> |
此外，还可以使用exec命令在指定的容器中运行任意的调试命令。
1 | kubectl exec <Pod名称> -c <Pod中的容器名称> -- <任意命令> <命令参数列表...> |
值得指出的是，对于只有一个容器的Pod情况，-c <Pod中的容器名称> 这个参数是可以省略的。
例如查看一个运行中的Cassandra日志文件内容，可以参考下面这个命令：
1 | kubectl exec cassandra -- cat /var/log/cassandra/system.log |
