目录

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

  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:很可能是 CNI 网络插件的问题(比如 ip 地址溢出),
  5. 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: 常和前两个错误先后出现,很可能是 CNI 网络插件的问题。
  7. 开发集群,一次性部署所有服务时,各 Pod 互相争抢资源,导致 Pod 生存探针失败,不断重启,重启进一步加重资源使用。恶性循环。
    • 需要给每个 Pod 加上 resources.requests,这样资源不足时,后续 Pod 会停止调度,直到资源恢复正常。
  8. Pod 出现大量的 Failed 记录,Deployment 一直重复建立 Pod: 通过 kubectl describe/edit pod <pod-name> 查看 pod EventsStatus,一般会看到失败信息,如节点异常导致 Pod 被驱逐。
  9. Kubernetes 问题排查:Pod 状态一直 Terminating
  10. 创建了 Deployment 后,却没有自动创建 Pod: 缺少某些创建 Pod 必要的东西,比如设定的 ServiceAccount 不存在。
  11. Pod 运行失败,状态为 MatchNodeSelector: 对主节点进行关机、迁移等操作,导致主调度器下线时,会在一段时间内导致 Pod 调度失败,调度失败会报这个错。
  12. Pod 仍然存在,但是 Service 的 Endpoints 却为空,找不到对应的 Pod IPs: 遇到过一次,是因为时间跳变(从未来的时间改回了当前时间)导致的问题。

Pod 无法删除

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

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

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

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

大致总结一下,主要原因来自 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 步骤:

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

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

1
2
3
4
5
6
7
8
# 登录到 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 记录:

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

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

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

根据官方文档 配置资源不足时的处理方式,Kubelet 提供如下用于配置容器 GC 及 Evicetion 的阈值:

  1. --eviction-hardeviction-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 也可以设小一点,清理得更干净。示例如下:

1
2
3
--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.

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

参考