在Kubernetes（K8s）运维中，可能会遇到多种问题，例如Pod无法创建或启动、服务创建失败、节点无法加入集群等等。为了帮助大家发现并及时解决，站长百科为大家详细分享了Kubernetes运维中常见的问题以及解决办法。
一、Kubernetes常见问题及解决方法
1、Pod无法创建或启动
问题：Pod无法创建或启动，可能是由于YAML文件配置错误、资源限制问题或者网络问题导致的。
解决方案：
- 使用kubectl describe pod <pod-name>查看Pod的详细信息和状态；
- 使用kubectl logs <pod-name>查看Pod的日志，帮助诊断问题；
- 检查YAML文件的配置，确保没有语法错误或配置不当；
- 调整资源限制（CPU和内存）以满足Pod的需求。
2、服务创建失败
问题：服务创建失败，可能是Kubernetes API服务器的问题或资源限制问题导致的。
解决方案：
- 使用kubectl get services查看所有服务，确保服务没有创建重复；
- 使用kubectl describe service <service-name>查看服务的详细信息和状态；
- 检查集群的资源使用情况，确保有足够的资源供服务使用。
3、节点无法加入集群
问题：节点无法加入集群，可能是网络问题、证书问题或配置问题导致的。
解决方案：
- 检查节点的网络连接，确保节点可以访问Kubernetes集群；
- 检查节点的证书和配置，确保它们正确无误；
- 使用kubeadm join命令重新尝试将节点加入集群。
4、资源不足
问题：集群资源不足，导致Pod无法被调度或运行。
解决方案：
- 使用kubectl top nodes和kubectl top pods查看节点和Pod的资源使用情况；
- 考虑增加集群节点以扩展资源；
- 调整Pod的资源请求和限制，以更合理地利用资源。
5、容器间通信问题
问题：容器间无法通信，可能是网络设置错误或者服务发现机制问题导致的。
解决方案：
- 使用kubectl get endpoints <service-name>查看服务的Endpoints是否正确；
- 检查网络插件（如Calico、Flannel等）的配置和状态；
- 确保Pod的网络设置（如命名空间、标签等）正确无误。
6、安全策略问题
问题：安全策略设置错误或RBAC权限问题导致无法访问或操作资源。
解决方案：
- 使用kubectl auth can-i <verb> <resource> <namespace> –as=<username>检查用户的权限；
- 审查和调整RBAC角色和角色绑定，确保用户具有正确的权限；
- 审查安全策略设置，确保它们符合安全要求。
二、Kubernetes排错案例
1、背景：收到测试环境集群告警，登陆 K8s 集群进行排查
2、故障定位
（1）查看 Pod
查看 kube-system node2 节点 calico pod 异常。
查看详细信息，查看node2节点没有存储空间，cgroup泄露。
（2）查看存储
登陆 node2 查看服务器存储信息，目前空间还很充足。
集群使用到的分布式存储为ceph，因此查看ceph集群状态。
三、操作
1、ceph修复
目前查看到 ceph 集群异常，可能导致 node2 节点 cgroup 泄露异常，进行手动修复ceph集群。
数据的不一致性（inconsistent）指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败（scrub error）。
CEPH 在存储的过程中，由于特殊原因，可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况，这也会导致清理失败。
由图可知，pg编号1.7c 存在问题，进行修复。
pg修复
ceph pg repair 1.7c
进行修复后，稍等一会，再次进行查看，ceph 集群已经修复
2、进行 Pod 修复
对异常pod进行删除，由于有控制器，会重新拉起最新的 Pod。
查看 Pod 还是和之前一样，分析可能由于ceph异常，导致node2节点cgroup泄露，网上检索重新编译
Google 一番后发现存在的可能有：
- Kubelet 宿主机的 Linux 内核过低 – Linux version 3.10.0-862.el7.x86_64
- 可以通过禁用kmem解决
- 查看系统内核却是低版本
3、故障再次定位
最后，因为在启动容器的时候 runc 的逻辑会默认打开容器的 kmem accounting，导致3.10内核可能的泄漏问题。
在此需要对no space left的服务器进行 reboot重启，即可解决问题，出现问题的可能为段时间内删除大量的pod所致。
初步思路，可以在今后的集群管理汇总，对服务器进行维修，通过删除节点，并对节点进行 reboot 处理。
4、对 node2 节点进行维护
（1）标记 node2 为不可调度
kubectl cordon node02
（2）驱逐 node2 节点上的 Pod
kubectl drain node02 —delete-local-data —ignore-daemonsets —force
- –delete-local-data 删除本地数据，即使emptyDir也将删除；
- –ignore-daemonsets 忽略 DeamonSet，否则 DeamonSet 被删除后，仍会自动重建；
- –force 不加 force 参数只会删除该 node 节点上的 ReplicationController， ReplicaSet，DaemonSet，StatefulSet or Job，加上后所有 pod 都将删除；
目前查看基本 node2 的 pod 均已剔除完毕。
此时与默认迁移不同的是，Pod 会先重建再终止，此时的服务中断时间=重建时间+服务启动时间+ readiness探针检测正常时间，必须等到1/1 Running服务才会正常。因此在单副本时迁移时，服务终端是不可避免的。
（3）对 node02 进行重启
重启后 node02 已经修复完成。
对 node02 进行恢复，恢复 node02 可以正常调度
kubectl uncordon node02
后期可以对部署 K8s 集群内核进行升级。集群内可能 Pod 的异常，由于底层存储或者其他原因导致，需要具体定位到问题进行针对性修复。
