K8s运维中常见的问题以及解决办法！（稳啦！！！！！）

在Kubernetes（K8s）运维中，可能会遇到多种问题。今天就给你盘点一些常见问题，以及举例说明k8s排错实战过程，希望对你有帮助~~~

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集群配置和遇到的具体问题。

在进行任何更改之前

请确保你了解这些命令和更改的潜在影响！！！！

k8s排错实战举例！！！！

一 背景

收到测试环境集群告警，登陆 K8s 集群进行排查

二 故障定位

2.1 查看 Pod

查看 kube-system node2 节点 calico pod 异常。

查看详细信息，查看node2节点没有存储空间，cgroup泄露。

2.2 查看存储

登陆 node2 查看服务器存储信息，目前空间还很充足。

集群使用到的分布式存储为ceph，因此查看ceph集群状态。

三 操作

3.1 ceph修复

目前查看到 ceph 集群异常，可能导致 node2 节点 cgroup 泄露异常，进行手动修复ceph集群。

数据的不一致性（inconsistent）指对象的大小不正确、恢复结束后某副本出现了对象丢失的情况。数据的不一致性会导致清理失败（scrub error）。

CEPH 在存储的过程中，由于特殊原因，可能遇到对象信息大小和物理磁盘上实际大小数据不一致的情况，这也会导致清理失败。

由图可知，pg编号1.7c 存在问题，进行修复。

• pg修复

ceph pg repair 1.7c

进行修复后，稍等一会，再次进行查看，ceph 集群已经修复

3.2 进行 Pod 修复

对异常pod进行删除，由于有控制器，会重新拉起最新的 Pod。

查看 Pod 还是和之前一样，分析可能由于ceph异常，导致node2节点cgroup泄露，网上检索重新编译

Google 一番后发现存在的可能有：

• Kubelet 宿主机的 Linux 内核过低 - Linux version 3.10.0-862.el7.x86_64

• 可以通过禁用kmem解决

查看系统内核却是低版本

3.3 故障再次定位

最后，因为在启动容器的时候 runc 的逻辑会默认打开容器的 kmem accounting，导致3.10内核可能的泄漏问题

在此需要对no space left的服务器进行 reboot重启，即可解决问题，出现问题的可能为段时间内删除大量的pod所致。

初步思路，可以在今后的集群管理汇总，对服务器进行维修，通过删除节点，并对节点进行 reboot 处理。

3.4 对 node2 节点进行维护

3.4.1 标记 node2 为不可调度

kubectl cordon node02

3.4.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.4.3 对 node02 进行重启

重启后 node02 已经修复完成。

对 node02 进行恢复

• 恢复 node02 可以正常调度

kubectl uncordon node02

四 反思

后期可以对部署 K8s 集群内核进行升级。

集群内可能 Pod 的异常，由于底层存储或者其他原因导致，需要具体定位到问题进行针对性修复

加油哦~~~宝~~