其他分享
首页 > 其他分享> > k8s运维之pod排错

k8s运维之pod排错

作者:互联网

k8s运维之pod排错


K8S是一个开源的,用于管理云平台中多个主机上的容器化应用,Kubernetes的目标是让部署容器化变得简单并且高效

K8S的核心优势:
 1,基于yaml文件实现容器的自动创建、删除
 2,更快速实现业务的弹性横向扩容
 3,动态发现新扩容的容器并自动对用户提供访问
 4,更简单、更快速的实现业务代码升级和回滚

一般来说pod处于异常状态,都可以执行以下命令查看pod状态
kubectl get pod <pod-name> -o yaml   #查看pod配置
kubcctl get pod <pod-name> -o wide   #查看pod运行节点等信息 
kubectl describe pod <pod-name>      #查看pod事件
kubectl logs <pod-name>              #查看pod日志


Pod 简介

 1. pod是k8s中的最小单元
 2. 一个pod中可以运行一个容器,也可以运行多个容器
 3. 运行多个容器的话,这些容器是一起被调度的
 4. Pod的生命周期是短暂的,不会自愈,是用完就销毁的实体
 5. 一般我们是通过Controller来创建和管理pod的
 
Pod生命周期:初始化容器、启动前操作、就绪探针、存活探针、删除pod操作

K8S中 Pod 创建过程
1,客户端向apiserver发起一个create pod请求
2,apiserver接收到pod创建请求后,生成一个包含创建信息的yaml
3,apiserver将yaml信息写入etcd数据库
4,根据scheduler调度器为pod分配node主机
5,node kubelet检测到有新的Pod调度过来,通过container runtime运行该pod
6,kubelet 获得pod状态,并更新到apiserver中


Pod一直处于Pending状态


pending说明pod还没调度到某个Node上面

 可以通过以下命令查看
 kubectl describe pod <pod-name>  

可能原因:
 1,资源不足,集群内所有的 Node 都不满足该 Pod 请求的CPU、内存或者临时存储空间等资源。解决方法是降低资源使用率,可以删除不用的Pod或者添加新的Node节点``  kubectl describe node  #可以查看node资源情况     2,HostPort 端口已被占用,通常推荐使用 Service 对外开放服务端口    3,不满足 nodeSelector 如果Pod包含nodeSelector 指定了节点需要包含的 label,调度器将只会考虑将 Pod 调度到包含这些 label 的Node上,如果没有 Node 有这些 label或者有这些 label的 Node 其它条件不满足也将会无法调度 4,不满足 affinity nodeAffinity: 节点亲和性,可以看成是增强版的 nodeSelector,用于限制 Pod 只允许被调度到某一部分 Node podAffinity: Pod亲和性,用于将一些有关联的Pod调度到同一个地方,可以是指同一个节点或同一个可用区的节点等 podAntiAffinity: Pod反亲和性,用于避免将某一类Pod调度到同一个地方避免单点故障,比如将集群 DNS 服务的 Pod 副本都调度到不同节点,避免一个节点挂了造成整个集群DNS解析失败,使得业务中断


Pod 一直处于 Waiting 或 ContainerCreating 状态


首先还是通过以下命令查看:
kubectl describe pod

可能原因:

1,镜像拉取失败,比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大,拉取超时等2,CNI 网络错误,一般需要检查 CNI 网络插件的配置,比如无法配置 Pod 、无法分配 IP 地址3,容器无法启动,需要检查是否打包了正确的镜像或者是否配置了正确的容器参数4,容器依赖的存储卷无法创建

 

Pod 处于 ImagePullBackOff 状态


这通常是镜像名称配置错误等导致镜像无法拉取。使用 docker pull <image> 来验证镜像是否可以正常拉取。

Pod 处于 Terminating 或 Unknown 状态
Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod,而是将其标记为 Terminating 或 Unknown 状态

想要删除这些状态的 Pod 有三种方法:

1,从集群中删除该Node。使用公有云时,kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中,需要管理员手动删除 Node(如 kubectl delete node <node-name>。

2,Node恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态,进而再决定删除或者继续运行这些 Pod。

3,用户强制删除。用户可以执行 kubectl delete pods <pod> --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态(比如 Node 所在 VM 或物理机已经关机),否则不建议使用该方法。特别是StatefulSet 管理的 Pod,强制删除容易导致脑裂或者数据丢失等问题

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


Pod 一直处于 CrashLoopBackOff 状态


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

可能是: 容器进程退出,健康检查失败退出等方法有: kubectl get pod <pod-name> -o yamlkubectl describe pod <pod-name>kubectl logs <pod-name> kubectl exec -it <pod-name> bash  #进去容器查看kubectl get pod <pod-name> -o wide #查看pod运行在哪个node上,去查看node系统日志



Pod 处于 Error 状态


Error 状态说明 Pod 启动过程中发生了错误

可能原因:
1,依赖的 ConfigMap、Secret 或者 PV 等不存在
2,请求的资源超过了管理员设置的限制,比如超过了 LimitRange 等
3,容器无权操作集群内的资源,比如开启 RBAC 后,需要为 ServiceAccount 配置角色绑定

 

集群处于 NotReady状态

 

kubectl get nodes

kubectl describe node

kubectl logs -n kube-system

journalctl -l -u kubelet

Node 处于 NotReady 状态,大部分是由于 PLEG(Pod Lifecycle Event Generator)问题导致的
社区 issue 目前还处于未解决状态

常见的问题及修复方法为:

Kubelet 未启动或者异常挂起:重新启动Kubelet
CNI 网络插件未部署:部署CNI插件
Docker :重启Docker
磁盘空间不足:清理磁盘空间,比如镜像、文件等
** 集群排错**
排查集群状态异常问题通常从 Node 和 Kubernetes 服务的状态出发
常见原因有: 
 虚拟机或物理机宕机
 Kubernetes 服务未正常启动
 操作失误(配置错误等)

kube-apiserver无法启动:
 会导致集群不可访问,已有的pod正常运行
  
etcd集群异常:
 apiserver无法正常读写集群状态,kubelet无法周期性更新状态

kube-controller-manager/kube-scheduler异常:
 控制器无法工作,导致deployment、service等异常,新创建的pod无法调度

Node机器无法启动或kubelet无法启动:
 node上的pod无法正常运行
 已经运行的pod无法正常终止

标签:Node,kubectl,删除,容器,排错,Pod,k8s,pod
来源: https://www.cnblogs.com/xiaohaoge/p/16552705.html