K8s问题的排查

1. POD启动异常、部分节点无法启动pod
2. 审视集群状态
3. 追踪事件日志
4. 聚焦Pod状态
5. 检查网络连通性
6. 审视存储配置
7. 研究容器日志
8. K8S集群网络通信
9. 问题：Service 是否通过 DNS 工作？
10. 总结

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

容器里管理应用

pod是k8S中最小调度单元,POD里面的容器共享pod的空间、资源、网络、存储等。
pod管理一个容器。
pod管理多个容器。

pod出现异常的原因：

1、资源过剩：大量POD在同一个物理节点，出现资源占用太多导致物理节点宕机。
2、内存和CPU超标：pod中的应用出现内存泄露，导致pod内存迅速增多，pod kill 了影响节点正常提供服务。（解决办法：压测占用多少内存和CPU，做资源限制；）
3、网络问题：导致POD无法通信（解决办法：检查calico网络插件情况）
4、存储问题：pod挂载的共享存储连接不上导致pod启动异常(解决办法：查看共享存储是否正常,存储卷是否正常)
5、代码问题：应用程序代码在容器启动后失败（解决办法：排查应用程序代码）
6、配置问题：在部署deployment和statefulset时，资源清单编写有问题，导致pod无法正常创建(解决办法：查看资源配置的清单)
7、借助监控系统排查以上问题。

2. 审视集群状态

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

3. 追踪事件日志

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

4. 聚焦Pod状态

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

5. 检查网络连通性

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

6. 审视存储配置

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

7. 研究容器日志

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

8. K8S集群网络通信

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

• Calico网络插件支持IP地址的分配以及网络策略的调整，性能和Flannel不相上下。

• Flannel网络插件只支持IP地址分配。

• Canel是Calico和Flannel网络插件的结合体。

  
  

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

1. 同一个Pod内多个容器之间的网络通信。

2. Pod与Pod之间的网络通信。

3. Pod与Service的通信。

4. Service资源与集群外部的通信

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

  从相同 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.10
Server:         10.0.0.10
Address:        10.0.0.10#53
Name:   hostnames.default.svc.cluster.local
Address: 10.0.1.175

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

u@pod$ cat /etc/resolv.conf
nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local example.com
options 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 名称。

10. 总结

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

原文链接：https://blog.csdn.net/2201_75366661/article/details/133522298

免责声明：本文内容来源于网络，所载内容仅供参考。转载仅为学习和交流之目的，如无意中侵犯您的合法权益，请及时联系Docker中文社区！