1. POD启动异常、部分节点无法启动pod

2. 审视集群状态

3. 追踪事件日志

4. 聚焦Pod状态

5. 检查网络连通性

6. 审视存储配置

7. 研究容器日志

8. K8S集群网络通信

9. 问题：Service 是否通过 DNS 工作？

10. 总结

容器里管理应用：

pod出现异常的原因：

K8S的集群状态是排查故障的关键起点。使用kubectl get nodes命令来检查节点状态。如果有节点未能就绪或出现异常状态，可能会对应用程序造成故障。确保基本组件，如etcd、kubelet和kube-proxy等，正常运行。

深入了解集群中发生的事件是解决K8S故障的重要环节。通过kubectl get events命令查看事件日志。事件日志记录了与集群中重要事件和错误相关的信息。透过事件日志的检查，能够了解K8S组件或应用程序中存在的潜在故障，并准确定位问题。

通过运行kubectl get pods --all-namespaces命令，获取集群中所有Pod的状态。若有Pod未处于运行状态（例如挂起、错误或未就绪等），很可能与容器或应用程序相关的问题有关。借助kubectl describe pod命令，获取特定Pod的详细信息，以便深入排查。

确保网络连接正常。审查服务、Pod和节点之间的网络通信是否存在问题。运行kubectl get services命令查看服务状态，使用kubectl describe service获取相关服务的详细信息。同时，验证网络策略和防火墙规则的正确配置。

如果你的应用程序使用持久性存储（例如Persistent Volumes和Storage Classes），务必确保存储配置正确。检查存储卷声明、存储类和持久卷的状态。通过kubectl get pv、kubectl get pvc和kubectl get storageclass命令，获取与存储相关的信息。

深入容器的日志能够提供关于应用程序故障的重要线索。使用kubectl logs命令查看特定Pod中容器的日志输出。如果Pod内含多个容器，你可以使用kubectl logs-c来查看特定容器的日志。

K8S集群有自己独立的内部网络，整个集群的通信都需要依赖网络插件，常见的网络插件有Calico、Flannel、Canel等等。

K8S集群中的网络通信主要有以下几种：

从相同 Namespace 下的 Pod 中运行：

u@pod$ nslookup hostnamesAddress 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      hostnamesAddress 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果失败，那么您的 Pod 和 Service 可能位于不同的 Namespace 中，请尝试使用限定命名空间的名称：

u@pod$ nslookup hostnames.defaultAddress 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.localName:      hostnames.defaultAddress 1: 10.0.1.175 hostnames.default.svc.cluster.local

如果成功，那么需要调整您的应用，使用跨命名空间的名称去访问服务，或者，在相同的 Namespace 中运行应用和 Service。如果仍然失败，请尝试一个完全限定的名称：

u@pod$ nslookup hostnames.default.svc.cluster.localAddress 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local
Name:      hostnames.default.svc.cluster.localAddress 1: 10.0.1.175 hostnames.default.svc.cluster.local

注意这里的后缀：”default.svc.cluster.local”。”default” 是我们正在操作的 Namespace。”svc” 表示这是一个 Service。”cluster.local” 是您的集群域，在您自己的集群中可能会有所不同。

您也可以在集群中的 Node 上尝试此操作：

注意：10.0.0.10 是我的 DNS Service，您的可能不同）

u@node$ nslookup hostnames.default.svc.cluster.local 10.0.0.10Server:         10.0.0.10Address:        10.0.0.10#53Name:   hostnames.default.svc.cluster.localAddress: 10.0.1.175

如果您能够使用完全限定的名称查找，但不能使用相对名称，则需要检查 /etc/resolv.conf 文件是否正确。

u@pod$ cat /etc/resolv.confnameserver 10.0.0.10search default.svc.cluster.local svc.cluster.local cluster.local example.comoptions ndots:5

nameserver 行必须指示您的集群的 DNS Service，它通过 --cluster-dns 标志传递到 kubelet。

search 行必须包含一个适当的后缀，以便查找 Service 名称。在本例中，它在本地 Namespace（default.svc.cluster.local）、所有 Namespace 中的 Service（svc.cluster.local）以及集群（cluster.local）中查找服务。根据您自己的安装情况，可能会有额外的记录（最多 6 条）。集群后缀通过 --cluster-domain 标志传递给 kubelet。本文档中，我们假定它是 “cluster.local”，但是您的可能不同，这种情况下，您应该在上面的所有命令中更改它。

options 行必须设置足够高的 ndots，以便 DNS 客户端库考虑搜索路径。在默认情况下，Kubernetes 将这个值设置为 5，这个值足够高，足以覆盖它生成的所有 DNS 名称。

当然，具体的排查方法还取决于你的集群配置、应用程序部署方式以及故障的具体现象。根据实际情况，可能需要进一步调查或采取其他排查措施。立足于这些方向，你将更有把握解决K8S故障，并确保应用程序持续稳定运行。