K8S常见错误、原因及处理方法

心已赠人 2023-10-03 11:12 93阅读 0赞

1.  OOMKilled: Pod 的内存使用超出了 resources.limits 中的限制，被强制杀死。
2.  CrashLoopBackoff: Pod 进入 **崩溃-重启**循环，重启间隔时间从 10 20 40 80 一直翻倍到上限 300 秒，然后以 300 秒为间隔无限重启。
3.  Pod 一直 Pending: 这说明没有任何节点能满足 Pod 的要求，容器无法被调度。比如端口被别的容器用 hostPort 占用，节点有污点等。
4.  [FailedCreateSandBox: Failed create pod sandbox: rpc error: code = DeadlineExceeded desc = context deadline exceeded][FailedCreateSandBox_ Failed create pod sandbox_ rpc error_ code _ DeadlineExceeded desc _ context deadline exceeded]：很可能是 CNI 网络插件的问题（比如 ip 地址溢出），
5.  [SandboxChanged: Pod sandbox changed, it will be killed and re-created][SandboxChanged_ Pod sandbox changed_ it will be killed and re-created]: 很可能是由于内存限制导致容器被 OOMKilled，或者其他资源不足
6.  [FailedSync: error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded][FailedSync_ error determining status_ rpc error_ code _ DeadlineExceeded desc _ context deadline exceeded]: 常和前两个错误先后出现，很可能是 CNI 网络插件的问题。
7.  开发集群，一次性部署所有服务时，各 Pod 互相争抢资源，导致 Pod 生存探针失败，不断重启，重启进一步加重资源使用。恶性循环。
    
     *  **需要给每个 Pod 加上 resources.requests，这样资源不足时，后续 Pod 会停止调度，直到资源恢复正常。**
8.  Pod 出现大量的 Failed 记录，Deployment 一直重复建立 Pod: 通过 `kubectl describe/edit pod <pod-name>` 查看 pod `Events` 和 `Status`，一般会看到失败信息，如节点异常导致 Pod 被驱逐。
9.  [Kubernetes 问题排查：Pod 状态一直 Terminating][Kubernetes _Pod _ Terminating]
10. 创建了 Deployment 后，却没有自动创建 Pod: 缺少某些创建 Pod 必要的东西，比如设定的 ServiceAccount 不存在。
11. Pod 运行失败，状态为 MatchNodeSelector: 对主节点进行关机、迁移等操作，导致主调度器下线时，会在一段时间内导致 Pod 调度失败，调度失败会报这个错。
12. Pod 仍然存在，但是 `Service` 的 Endpoints 却为空，找不到对应的 Pod IPs: 遇到过一次，是因为时间跳变（从未来的时间改回了当前时间）导致的问题。

#### Pod 无法删除 ####

可能是某些资源无法被GC，这会导致容器已经 Exited 了，但是 Pod 一直处于 Terminating 状态。

这个问题在网上能搜到很多案例,但大都只是提供了如下的强制清理命令，未分析具体原因：

kubectl delete pods <pod> --grace-period=0 --force

最近找到几篇详细的原因分析文章，值得一看：

*  [腾讯云原生 -【Pod Terminating原因追踪系列】之 containerd 中被漏掉的 runc 错误信息][-_Pod Terminating_ containerd _ runc]
 *  [腾讯云原生 -【Pod Terminating原因追踪系列之二】exec连接未关闭导致的事件阻塞][-_Pod Terminating_exec]
 *  [腾讯云原生 -【Pod Terminating原因追踪系列之三】让docker事件处理罢工的cancel状态码][-_Pod Terminating_docker_cancel]
 *  [Pod terminating - 问题排查 - KaKu Li][Pod terminating - _ - KaKu Li]

大致总结一下，主要原因来自 docker 18.06 以及 kubernetes 的 docker-shim 运行时的底层逻辑，已经在新版本被修复了。

### 节点常见错误 ###

1.  [DiskPressure][]：节点的可用空间不足。（通过`df -h` 查看，保证可用空间不小于 15%）
2.  The node was low on resource: ephemeral-storage: 同上，节点的存储空间不够了。

### 网络常见错误 ###

#### 1. Ingress/Istio Gateway 返回值 ####

1.  404：不存在该 Service/Istio Gateway
2.  503：服务不可用。原因基本都是 Service 对应的 Pods NotReady
3.  504：网关请求下游超时。主要有两种可能
    
    1.  考虑是不是 Ingress Controller 的 IP 表未更新，将请求代理到了不存在的 Pod ip，导致得不到响应。
    2.  Pod 响应太慢，代码问题。

Ingress 相关网络问题的排查流程：

1.  Which ingress controller?
2.  Timeout between client and ingress controller, or between ingress controller and backend service/pod?
3.  HTTP/504 generated by the ingress controller, proven by logs from the ingress controller?
4.  If you port-forward to skip the internet between client and ingress controller, does the timeout still happen?

### 名字空间常见错误 ###

#### 名字空间无法删除 ####

这通常是某些资源如 CR(custom resources)/存储等资源无法释放导致的。  
比如常见的 monitoring 名字空间无法删除，应该就是 CR 无法 GC 导致的。

可手动删除 namespace 配置中的析构器（spec.finalizer，在名字空间生命周期结束前会生成的配置项），这样名字空间就会直接跳过 GC 步骤：

# 编辑名字空间的配置
    kubectl edit namespace <ns-name>
    # 将 spec.finalizers 改成空列表 []

如果上述方法也无法删除名字空间，也找不到具体的问题，就只能直接从 etcd 中删除掉它了(有风险，谨慎操作！)。方法如下：

# 登录到 etcd 容器中，执行如下命令：
    export ETCDCTL_API=3
    cd /etc/kubernetes/pki/etcd/
    # 列出所有名字空间
    etcdctl --cacert ca.crt --cert peer.crt --key peer.key get /registry/namespaces --prefix --keys-only
    
    # （谨慎操作！！！）强制删除名字空间 `monitoring`。这可能导致相关资源无法被 GC！
    etcdctl --cacert ca.crt --cert peer.crt --key peer.key del /registry/namespaces/monitoring

### kubectl/istioctl 等客户端工具异常 ###

1.  `socat not found`: kubectl 使用 `socat` 进行端口转发，集群的所有节点，以及本机都必须安装有 `socat` 工具。

### 批量清理 Evicted 记录 ###

有时候 Pod 因为节点选择器的问题，被不断调度到有问题的 Node 上，就会不断被 Evicted，导致出现大量的 Evicted Pods。  
排查完问题后，需要手动清理掉这些 Evicted Pods.

批量删除 Evicted 记录:

kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod

### 容器镜像GC、Pod驱逐以及节点压力 ###

节点压力 DiskPressure 会导致 Pod 被驱逐，也会触发容器镜像的 GC。

根据官方文档 [配置资源不足时的处理方式][Link 1]，Kubelet 提供如下用于配置容器 GC 及 Evicetion 的阈值：

1.  –eviction-hard和eviction-soft: 对应旧参数–image-gc-high-threshold，这两个参数配置镜像 GC 及驱逐的触发阈值。磁盘使用率的阈值默认为 85%
    
    1.  区别在于 `eviction-hard` 是立即驱逐，而 `eviction-soft` 在超过 `eviction-soft-grace-period` 之后才驱逐。
2.  `--eviction-minimum-reclaim`: 对应旧参数 `--image-gc-low-threshold`。这是进行资源回收（镜像GC、Pod驱逐等）后期望达到的磁盘使用率百分比。磁盘使用率的阈值默认值为 80%。

问：能否为 ImageGC 设置一个比 DiskPressure 更低的阈值？因为我们希望能自动进行镜像 GC，但是不想立即触发 Pod 驱逐。

答：这应该可以通过设置 `eviction-soft` 和长一点的 `eviction-soft-grace-period` 来实现。  
另外 `--eviction-minimum-reclaim` 也可以设小一点，清理得更干净。示例如下：

--eviction-soft=memory.available<1Gi,nodefs.available<2Gi,imagefs.available<200Gi
    --eviction-soft-grace-period=3m
    --eviction-minimum-reclaim=memory.available=0Mi,nodefs.available=1Gi,imagefs.available=2Gi

### 其他问题 ###

#### 如何重新运行一个 Job？ ####

我们有一个 Job 因为外部原因运行失败了，修复好后就需要重新运行它。

方法是：删除旧的 Job，再使用同一份配置重建 Job.

或者建议不要定义 job 的 nane，改成定义 generateName.

如果你使用的是 fluxcd 这类 GitOps 工具，就只需要手工删除旧 Pod，fluxcd 会定时自动 apply 所有配置，这就完成了 Job 的重建。

### 参考 ###

*  [Kubernetes管理经验][Kubernetes]
 *  [504 Gateway Timeout when accessing workload via ingress][]
 *  [Kubernetes Failure Stories][]

[FailedCreateSandBox_ Failed create pod sandbox_ rpc error_ code _ DeadlineExceeded desc _ context deadline exceeded]: https://www.cnblogs.com/kirito-c/p/11923824.html
[SandboxChanged_ Pod sandbox changed_ it will be killed and re-created]: https://cloud.tencent.com/developer/article/1411527
[FailedSync_ error determining status_ rpc error_ code _ DeadlineExceeded desc _ context deadline exceeded]: https://github.com/kubernetes/kubernetes/issues/55094
[Kubernetes _Pod _ Terminating]: https://zhuanlan.zhihu.com/p/70031676
[-_Pod Terminating_ containerd _ runc]: https://cloud.tencent.com/developer/article/1680612
[-_Pod Terminating_exec]: https://cloud.tencent.com/developer/article/1680613
[-_Pod Terminating_docker_cancel]: https://cloud.tencent.com/developer/article/1689486
[Pod terminating - _ - KaKu Li]: https://www.likakuli.com/posts/docker-pod-terminating/
[DiskPressure]: https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-conditions
[Link 1]: https://kubernetes.io/zh/docs/tasks/administer-cluster/out-of-resource
[Kubernetes]: https://yq.aliyun.com/articles/703971?type=2
[504 Gateway Timeout when accessing workload via ingress]: https://www.reddit.com/r/kubernetes/comments/ced0py/504_gateway_timeout_when_accessing_workload_via/
[Kubernetes Failure Stories]: https://k8s.af/