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创建请求后，生成一个包含创建信息的yaml3，apiserver将yaml信息写入etcd数据库4，根据scheduler调度器为pod分配node主机5，node kubelet检测到有新的Pod调度过来，通过container runtime运行该pod6，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无法正常终止
