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

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

Pod 无法删除

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

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

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

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

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

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

节点常见错误

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

网络常见错误

1. Ingress/Istio Gateway 返回值

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

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

Which ingress controller?
Timeout between client and ingress controller, or between ingress controller and backend service/pod?
HTTP/504 generated by the ingress controller, proven by logs from the ingress controller?
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 等客户端工具异常

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。

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

–eviction-hard和eviction-soft: 对应旧参数–image-gc-high-threshold，这两个参数配置镜像 GC 及驱逐的触发阈值。磁盘使用率的阈值默认为 85%
1. 区别在于 eviction-hard 是立即驱逐，而 eviction-soft 在超过 eviction-soft-grace-period 之后才驱逐。
--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管理经验
504 Gateway Timeout when accessing workload via ingress
Kubernetes Failure Stories