本文章只介绍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 无法正常终止

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐