这篇文章主要介绍了kubernetes k8s常用问题如何排查的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇kubernetes k8s常用问题如何排查文章都会有所收获，下面我们一起来看看吧。
使用 K8s 部署我们的服务之后，为了观察 Pod 是否成功，我们都会使用下面这个命令查询 Pod 的状态。
kubectl get pods NAME READY STATUS RESTARTS AGE my-app-5d7d978fb9-2fj5m 0/1 ContainerCreating 0 10s my-app-5d7d978fb9-dbt89 0/1 ContainerCreating 0 10s
这里的 STATUS 代表了 Pod 的状态，可能会遇到的状态有下面几个：
ContainerCreating：代表容器正在创建，这是一个中间状态，随着容器创建成功会切换，但是也有可能一直卡在这里，具体问题下面会分析。
ImagePullBackOff：容器镜像拉取失败，具体原因需要结合 describe 命令再去查看。
CrashLoopBackOff：容器崩溃，一般容器崩溃，Deployment 会重新创建一个 Pod，维持副本数量，但是大概率新创建的Pod 还是会崩溃，它不会无限尝试，崩溃超过设置次数就不会再尝试重建Pod，此时Pod的状态就维持在了 CrashLoopBackOff。
Evicted: 因为节点资源不足（CPU/Mem/Storage都有可能），Pod 被驱逐会显示 Evicted 状态，K8s 会按照策略选择认为可驱逐的Pod从节点上 Kill 掉。
Running 这个代表 Pod 正常运行。
下面我们来看一下 Pod 的几个错误状态的原因，以及怎么排查解决它们。
镜像拉取失败后 Pod 的状态字段表示为 ImagePullBackOff，这个发生的情况还是很多的，原因除了我们不小心写错镜像名字之外，还有就是常用软件的一些官方镜像都在国外，比如在docker.io 或者 quay.io 的镜像仓库上，有的时候访问速度会很慢。
下面我们自己故意制造一个镜像名字写错的场景，看怎么使用 kubectl 命令进行排查。比如我在 K8s 教程里一直用的 Deployment 定义：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-go-app
spec:
replicas: 2
selector:
matchLabels:
app: go-app
template:
metadata:
labels:
app: go-app
spec:
containers:
- name: go-app-container
image: kevinyan001/kube-go-app:v0.3
resources:
limits:
memory: "200Mi"
cpu: "50m"
ports:
- containerPort: 3000
volumeMounts:
- name: app-storage
mountPath: /tmp
volumes:
- name: app-storage
emptyDir: {}我们把镜像的名字故意改错，改成 v0.5，这个镜像是我自己打的，确实还没有 0.5 版本。执行kubectl apply 后，来观察一下 Pod 的状态。
➜ kubectl apply -f deployment.yaml deployment.apps/my-go-app configured ➜ kubectl get pods NAME READY STATUS RESTARTS AGE my-go-app-5d7d978fb9-2fj5m 1/1 Running 0 3h68m my-go-app-5d7d978fb9-dbt89 1/1 Running 0 3h68m my-go-app-6b77dbbcc5-jpgbw 0/1 ContainerCreating 0 7s ➜ kubectl get pods NAME READY STATUS RESTARTS AGE my-go-app-5d7d978fb9-2fj5m 1/1 Running 0 3h68m my-go-app-5d7d978fb9-dbt89 1/1 Running 0 3h68m my-go-app-6b77dbbcc5-jpgbw 0/1 ErrImagePull 0 14s .....// 停顿1分钟，再查看Pod 的状态 ➜ kubectl get pods NAME READY STATUS RESTARTS AGE my-go-app-5d7d978fb9-2fj5m 1/1 Running 0 4h2m my-go-app-5d7d978fb9-dbt89 1/1 Running 0 4h2m my-go-app-6b77dbbcc5-jpgbw 0/1 ImagePullBackOff 0 3m11s
上面我们更新了 deployment 之后，观察到 Pod 的状态变化过程是：
ContainerCreating ===> ErrImagePull ===> ImagePullBackOff
首先 deployment 更新 Pod 时是滚动更新，要先把新 Pod 创建出来后能对旧版本 Pod 完成替换。接下来由于镜像拉取错误会反馈一个中间状态 ErrImagePull，此时会再次尝试拉取，如果确定镜像拉取不下来后，最后反馈一个失败的终态 ImagePullBackOff。
怎么排查是什么导致的拉取失败呢？通过 kubectl describe pod {pod-name} 查看它的事件记录
➜ kubectl describe pod my-go-app-6b77dbbcc5-jpgbw Name: my-go-app-6b77dbbcc5-jpgbw Namespace: default Priority: 0 ... Controlled By: ReplicaSet/my-go-app-6b77dbbcc5 Containers: go-app-container: Container ID: Image: kevinyan001/kube-go-app:v0.5 Image ID: Port: 3000/TCP Host Port: 0/TCP State: Waiting Reason: ErrImagePull Ready: False ... Node-Selectors: <none> Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300s Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m12s default-scheduler Successfully assigned default/my-go-app-6b77dbbcc5-jpgbw to docker-desktop Normal Pulling 27s (x4 over 2m12s) kubelet Pulling image "kevinyan001/kube-go-app:v0.5" Warning Failed 20s (x4 over 2m4s) kubelet Failed to pull image "kevinyan001/kube-go-app:v0.5": rpc error: code = Unknown desc = Error response from daemon: manifest for kevinyan001/kube-go-app:v0.5 not found: manifest unknown: manifest unknown Warning Failed 20s (x4 over 2m4s) kubelet Error: ErrImagePull Normal BackOff 4s (x5 over 2m4s) kubelet Back-off pulling image "kevinyan001/kube-go-app:v0.5" Warning Failed 4s (x5 over 2m4s) kubelet Error: ImagePullBackOff
Pod 事件记录里，清楚记录了 Pod 从开始到最后经历的状态变化，以及是什么导致状态变化的，其中失败事件里清楚的给出了我们原因，就是镜像找不到。
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 20s (x4 over 2m4s) kubelet Failed to pull image "kevinyan001/kube-go-app:v0.5": rpc error: code = Unknown desc = Error response from daemon: manifest for kevinyan001/kube-go-app:v0.5 not found: manifest unknown: manifest unknown Warning Failed 20s (x4 over 2m4s) kubelet Error: ErrImagePull Normal BackOff 4s (x5 over 2m4s) kubelet Back-off pulling image "kevinyan001/kube-go-app:v0.5" Warning Failed 4s (x5 over 2m4s) kubelet Error: ImagePullBackOff
还有一种是网络原因，或者镜像仓库没有权限拒绝拉取请求，导致无法拉取成功。因为我这里网络环境、加速器之类的好不容易都配好了，就不给大家演示这两种情况了。
不过排查方式也是一样，使用kubectl describe 命令查看 Pod 的事件，并且使用 docker pull 尝试主动的拉取一下镜像试试，如果确实网络问题拉取不下来的，可以考虑翻墙，或者使用国内的加速节点。
配置加速器，可以考虑使用阿里云的免费加速器，配置文档在下面，需要注册阿里云账号才能使用加速器
https://help.aliyun.com/product/60716.html
再来看这种错误，这种一般是容器里运行的程序内部出问题导致的容器连续崩溃出现的问题。最后反馈到 Pod 状态上是 CrashLoopBackOff 状态。
演示容器运行中崩溃的情况有点难，不过好在我之前介绍 Go 服务自动采样的时候，做过一个镜像
以下内容引用我之前的文章：Go 服务进行自动采样性能分析的方案设计与实现
我做了个docker 镜像方便进行试验，镜像已经上传到了Docker Hub上，大家感兴趣的可以Down下来自己在电脑上快速试验一下。
通过以下命令即可快速体验。
docker run --name go-profile-demo -v /tmp:/tmp -p 10030:80 --rm -d kevinyan001/go-profiling
容器里Go服务提供的路由如下
所以我们把上面的 deployment Pod 模版里的镜像换成这个 kevinyan001/go-profiling，再通过提供的路由手动制造 OOM，来故意制造容器崩溃的情况。
修改Pod 使用的容器镜像
#执行 kubectl apply -f deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-go-app spec: replicas: 2 selector: matchLabels: app: go-app template: metadata: labels: app: go-app spec: containers: - name: go-app-container image: kevinyan001/go-profiling:latest resources: limits: memory: "200Mi" cpu: "50m"
创建个 SVC 让Pod能接受外部流量
#执行 kubectl apply -f service.yaml apiVersion: v1 kind: Service metadata: name: app-service spec: type: NodePort selector: app: go-app ports: - name: http protocol: TCP nodePort: 30080 port: 80 targetPort: 80
程序中提供的路由如下：
访问 http://127.0.0.1:30080/1gb-slice 让容器内存溢出，因为 Deployment 会重启崩溃的 Pod，所以这里非常考验手速：） 估计狂点一分钟，Deployment 就放弃治疗休息会儿再重启 Pod，这时 Pod 的状态成功变成了：
➜ kubectl get pods NAME READY STATUS RESTARTS AGE my-go-app-598f697676-f5jfp 0/1 CrashLoopBackOff 2 (18s ago) 5m37s my-go-app-598f697676-tps7n 0/1 CrashLoopBackOff 2 (23s ago) 5m35s
这个时候我们使用 kubectl describe pod 看崩溃 Pod 的详细信息，会看到容器内程序返回的错误码
➜ kubectl describe pod my-go-app-598f697676-tps7n Name: my-go-app-598f697676-tps7n Namespace: default Port: 3000/TCP Host Port: 0/TCP State: Running Started: Sun, 20 Mar 2022 16:09:29 +0800 Last State: Terminated Reason: Error Exit Code: 137 Started: Sun, 20 Mar 2022 16:08:56 +0800 Finished: Sun, 20 Mar 2022 16:09:05 +0800
不过要深入排查 Pod 内容器的问题，需要另一个命令 kubectl logs {pod-name} 的协助。
kubectl logs my-go-app-598f697676-tps7n
如果恰巧这个 Pod 被重启了，查不出来任何东西，可以通过增加 — previous 参数选项，查看之前容器的日志。
kubectl logs my-go-app-598f697676-tps7n --previous
首先声明，这个问题研发解决不了，但是你发挥一下自己YY的能力：当群里报警、运维@你赶紧看的时候，你来个反杀，告诉他资源不够了赶紧扩容，是不是能装到^_^…
扯远了，现在回正题。集群里资源紧张的时候，K8s 会优先驱逐优先级低的 Pod，被驱逐的 Pod 的状态会是 Evicted，这个情况没办法在本地模拟，贴一个在公司K8s集群遇到这种情况的截图。
kubectl get pod 查看Pod状态
上图可以看到有一个Pod 的状态变成了 Evicted。
再来用describe 看下详细信息
kubectl describe pod 查看Pod 的详细信息和事件记录
不好意思，历史久远，上面的图太模糊了，图中的Message 一栏里有给出如下信息：
Status: Faild Reason: Evicted Message: The node wan low on resource: xxx-storage. Container xxx using xxxKi, which exceeds its request of ....
一般来说，大多数常见的部署失败都可以使用这些命令进行排查和调试：
kubectl get pods
kubectl describe pod <podname>
kubectl logs <podname>
kubectl logs <podname> --previous
当然，有的时候想看 Pod 的配置信息，还可以使用
kubectl get pod <podname> -o=yaml
验证一下Pod的配置是不是跟我们提交上去的一样，以及一些其他的额外信息。
get 和 describe 这两个命令除了能看 Pod 的状态和信息记录外，也能看其他资源的状态和信息。
kubectl get pod|svc|deploy|sts|configmap <xxx-name> kubectl describe pod|svc|deploy|sts|configmap <xxx-name>
关于“kubernetes k8s常用问题如何排查”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“kubernetes k8s常用问题如何排查”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注亿速云行业资讯频道。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
