k8s运维之pod排错
k8s运维之pod排错
K8S是一个开源的，用于管理云平台中多个主机上的容器化应用，Kubernetes的目标是让部署容器化变得简单并且高效
K8S的核心优势：
1，基于yaml文件实现容器的自动创建、删除
2，更快速实现业务的弹性横向扩容
3，动态发现新扩容的容器并自动对用户提供访问
4，更简单、更快速的实现业务代码升级和回滚
一般来说pod处于异常状态，都可以执行以下命令查看pod状态
kubectl get pod -o yaml #查看pod配置
kubcctl get pod -o wide #查看pod运行节点等信息
kubectl describe pod #查看pod事件
kubectl logs #查看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
可能原因：
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 来验证镜像是否可以正常拉取。
Pod 处于 Terminating 或 Unknown 状态
Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态
想要删除这些状态的 Pod 有三种方法：1，从集群中删除该Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node 。2，Node恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。3，用户强制删除。用户可以执行 kubectl delete pods --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题4，处于 Terminating 状态的 Pod 在 Kubelet 恢复正常运行后一般会自动删除。但有时也会出现无法删除的情况，并且通过 kubectl delete pods --grace-period=0 --force 也无法强制删除。此时一般是由于 finalizers 导致的，通过 kubectl edit 将 finalizers 删除即可解决。
Pod 一直处于 CrashLoopBackOff 状态
CrashLoopBackOff 状态说明容器曾经启动了，但又异常退出了。此时 Pod 的 Restart (重启次数) 通常是大于 0 的，可以先查看一下容器的日志
可能是： 容器进程退出，健康检查失败退出等方法有： kubectl get pod -o yamlkubectl describe pod kubectl logs kubectl exec -it bash #进去容器查看kubectl get pod -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无法正常终止