k8s集群故障问题处理

本文章只介绍k8s pod下可能出现的故障问题

k8s node master这些问题现在给 阿里云托管所以以下不会介绍这些问题 但是会精简说一下k8s集群外部所遇到的问题

集群内部问题
1 Pod 一直处于 Pending 状态
可能的原因包括
 资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、
GPU 或者临时存储空间等资源。解决方法是删除集群内不用的 Pod 或者
增加新的 Node。  HostPort 端口已被占用，通常推荐使用 Service 对外开放服务端口

2 Pod 一直处于 Waiting 或 ContainerCreating 状态
可能的原因有以下几种
 镜像拉取失败，比如
o 配置了错误的镜像
o Kubelet 无法访问镜像（国内环境访问 gcr.io 需要特殊处理）
o 私有镜像的密钥配置错误
o 镜像太大，拉取超时（可以适当调整 kubelet 的 --image-pullprogress-deadline 和 --runtime-request-timeout 选项）
 CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如
o 无法配置 Pod 网络
o 无法分配 IP 地址
 容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的
容器参数
3 Pod 处于 ImagePullBackOff 状态
这通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。这种情
况可以使用 docker pull 来验证镜像是否可以正常拉取。
4 Pod 一直处于 CrashLoopBackOff 状态

CrashLoopBackOff 状态说明容器曾经启动了，但又异常退出了。此时 Pod 的 RestartCounts
通常是大于 0 的，可以先查看一下容器的日志

这里可以发现一些容器退出的原因，比如
 容器进程退出
 健康检查失败退出
 OOMKilled

5 Pod 处于 Error 状态

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括
 依赖的 ConfigMap、Secret 或者 PV 等不存在
 请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等  违反集群的安全策略，比如违反了 PodSecurityPolicy 等  容器无权操作集群内的资源，比如开启 RBAC 后，需要为
ServiceAccount 配置角色绑定

6 Pod 处于 Terminating 或 Unknown 状态
从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM
删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除
Node（如 kubectl delete node 。  Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的
期待状态，进而再决定删除或者继续运行这些 Pod。  用户强制删除。用户可以执行 kubectl delete pods --graceperiod=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比
如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是
StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。

处于 Terminating 状态的 Pod 在 Kubelet 恢复正常运行后一般会自动删除。但有时
也会出现无法删除的情况，并且通过 kubectl delete pods --grace-period=0
–force 也无法强制删除。此时一般是由于 finalizers 导致的，通过 kubectl edit
将 finalizers 删除即可解决。

7 Pod 行为异常
这里所说的行为异常是指 Pod 没有按预期的行为执行，比如没有运行 podSpec
里面设置的命令行参数。这一般是 podSpec yaml 文件内容有误，可以尝试使
用 --validate 参数重建容器，比如

集群外部网络异常问题

介绍各种常见的网络问题以及排错方法，包括 Pod 访问异常、Service 访问异常以及网络安
全策略异常等。
 Pod 访问容器外部网络
 从容器外部访问 Pod 网络
 Pod 之间相互访问
当然，以上每种情况还都分别包括本地访问和跨主机访问两种场景，并且一般
情况下都是通过 Service 间接访问 Pod。
网络异常可能的原因比较多，常见的有
 CNI 网络插件配置错误，导致多主机网络不通，比如
o IP 网段与现有网络冲突
o 插件使用了底层网络不支持的协议
o 忘记开启 IP 转发等
 sysctl net.ipv4.ip_forward
 sysctl net.bridge.bridge-nf-call-iptables
 Pod 网络路由丢失，比如
o kubenet 要求网络中有 podCIDR 到主机 IP 地址的路由，这些路
由如果没有正确配置会导致 Pod 网络通信等问题
o 在公有云平台上，kube-controller-manager 会自动为所有 Node
配置路由，但如果配置不当（如认证授权失败、超出配额等），
也有可能导致无法配置路由
 主机内或者云平台的安全组、防火墙或者安全策略等阻止了 Pod 网络，
比如
o 非 Kubernetes 管理的 iptables 规则禁止了 Pod 网络
o 公有云平台的安全组禁止了 Pod 网络（注意 Pod 网络有可能与
Node 网络不在同一个网段）
o 交换机或者路由器的 ACL 禁止了 Pod 网络
Service 无法访问
访问 Service ClusterIP 失败时，可以首先确认是否有对应的 Endpoints
kubectl get endpoints
如果该列表为空，则有可能是该 Service 的 LabelSelector 配置错误，可以
用下面的方法确认一下

查询 Service 的 LabelSelector

查询匹配 LabelSelector 的 Pod

kubectl get pods -l key1=value1,key2=value2
如果 Endpoints 正常，可以进一步检查
 Pod 的 containerPort 与 Service 的 containerPort 是否对应
 直接访问 podIP:containerPort 是否正常
再进一步，即使上述配置都正确无误，还有其他的原因会导致 Service 无法访
问，比如
 Pod 内的容器有可能未正常运行或者没有监听在指定的 containerPort
上  CNI 网络或主机路由异常也会导致类似的问题
 kube-proxy 服务有可能未启动或者未正确配置相应的 iptables 规则，
比如正常情况下名为 hostnames 的服务会配置以下 iptables 规则
9.5 Volume 异常处理
持久化存储异常（PV、PVC、StorageClass 等）的排错方法。
一般来说，无论 PV 处于什么异常状态，都可以执行 kubectl
describe pv/pvc 命令来查看当前 PV 的事件。这些事
件通常都会有助于排查 PV 或 PVC 发生的问题。

集群外部组件问题

按照不同的组件来说，具体的原因可能包括
 kube-apiserver 无法启动会导致
o 集群不可访问
o 已有的 Pod 和服务正常运行（依赖于 Kubernetes API 的除外）
 etcd 集群异常会导致
o kube-apiserver 无法正常读写集群状态，进而导致 Kubernetes
API 访问出错
o kubelet 无法周期性更新状态
 kube-controller-manager/kube-scheduler 异常会导致
o 复制控制器、节点控制器、云服务控制器等无法工作，从而导致
Deployment、Service 等无法工作，也无法注册新的 Node 到集
群中来
o 新创建的 Pod 无法调度（总是 Pending 状态）
 Node 本身宕机或者 Kubelet 无法启动会导致
o Node 上面的 Pod 无法正常运行
o 已在运行的 Pod 无法正常终止