应用程序故障排查
常见问题
这里常见的问题,更新在 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 |