专栏首页网管叨bi叨想在研发群里装?先学会这几个排查K8s问题的办法

想在研发群里装?先学会这几个排查K8s问题的办法

新手学习 K8s 最大的难度感觉是在起步动手实践的时候,Pod 没有正常启动起来,或者运行了一段时间 Pod 自己崩溃了。那么是什么问题导致了它没运行起来,又或者是什么因素导致了它的崩溃,这到底是道德的沦丧还是人性的扭曲。。。不好意思,拿错脚本了。

今天这篇文章我们一起学习总结几个使用 K8s 时常见的错误现象以及排查这些现象背后问题的方法。

学会这些,保证你能在研发组里、运维面前装到

装不成,被打脸,也别来找我,因为我也经常被……诶,发奋图强,争取下次装到。

Pod 的那些状态

使用 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          3h58m
my-go-app-5d7d978fb9-dbt89   1/1     Running             0          3h58m
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          3h58m
my-go-app-5d7d978fb9-dbt89   1/1     Running        0          3h58m
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          4h1m
my-go-app-5d7d978fb9-dbt89   1/1     Running            0          4h1m
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 尝试主动的拉取一下镜像试试,如果确实网络问题拉取不下来的,可以使用国内的加速节点。

启动后容器崩溃

再来看这种错误,这种一般是容器里运行的程序内部出问题导致的容器连续崩溃出现的问题。最后反馈到 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状态

kubectl get pod

上图可以看到有一个Pod 的状态变成了 Evicted。

再来用describe 看下详细信息

kubectl describe pod 查看Pod 的详细信息和事件记录

执行kubectl describe 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>

这些就留给大家后面自己体验吧。

- END -

文章分享自微信公众号:
网管叨bi叨

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

作者:KevinYan11
原始发表时间:2022-03-22
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 经典烧脑故障--之山路十八弯

    早上9点左右,接到业务侧同事反馈交易订单无法打开,无法交易,就是我们上面的a服务和b服务!~

    IT运维技术圈
  • 深圳某游戏研发公司给每个工位都装监控,网友:简直离谱!

    点击上方蓝色字体,选择“设为星标” 回复”学习资料“获取学习宝典 整理:程序员的那些事 “一对一”的监控摄像头 7 月 12 日,网传深圳一公司办公室内,每...

    猿天地
  • 深圳某游戏研发公司给每个工位都装监控,网友:堪比坐牢!

    这是「进击的Coder」的第 693 篇分享 整理:程序员的那些事 “ 阅读本文大概需要 5 分钟。 ” “一对一”的监控摄像头 7 月 12 日,网传深圳一...

    崔庆才
  • 深圳某游戏研发公司给每个工位都装监控,网友:堪比坐牢!

    推荐阅读: 《我,35岁了。》 《美女裸聊一时爽,裸聊结束火葬场!》 整理:程序员的那些事 “一对一”的监控摄像头 7 月 12 日,网传深圳一公司办公室内,每...

    纯洁的微笑
  • 简直离谱!这个研发公司竟然给每个工位都装了监控。。硬核防摸鱼!

    点击关注公众号,Java干货及时送达 整理:程序员的那些事 “一对一”的监控摄像头。。 7 月 12 日,网传深圳一公司办公室内,每个工位上方都安装有监控摄像...

    Java技术栈
  • 这么笨的史丹利,是怎么学会这该死的k8s容器化的?

    今天和大家聊一聊k8s到底该怎么学。其实,遇到这个问题的朋友是真的不少。有刚入行的新手朋友,也有已经在行业里摸爬滚打了小10年的朋友。不管原因几何,但总归能侧面...

    运维部落
  • 【警惕】K8S下Telnet失效陷阱

    追踪nginx和业务程序日志后,我们基本能定位到是 redis 服务不可用和后端的一台nginx容器无法连接导致问题。我们的简易架构图如下:

    运维部落
  • Kubernetes 入门&进阶实战

    作者:oonamao毛江云,腾讯 CSIG 应用开发工程师 写在前面 笔者今年 9 月从端侧开发转到后台开发,第一个系统开发任务就强依赖了 K8S,加之项目任务...

    腾讯技术工程官方号
  • GIAC 2020 全球互联网架构大会演讲实录:基于TarsGo的微服务技术架构实践

    2020年8月14日-15日,GIAC 2020 全球互联网架构大会于上周五正式在深圳开幕。 GIAC(GLOBAL INTERNET ARCHITECTU...

    腾讯技术工程官方号
  • 给迷茫的计算机系大学生的一封信 JAVA

    看这标题,我突然词穷了!我不知道我该去说什么!说你们这群大学生,别玩了?还是,你们这却大学生好好努力吧!我似乎不配说,因为我的大学,也是浑浑噩噩,就那样过去了!...

    止术
  • NVIDIA Jetson TX2新手手册:一场当没有人告诉你该做什么你要能够知道该做什么的无畏冒险

    吉浦迅用户专用 感谢你带给我们各种惊喜 【序言】 2017年,NVIDIA正式全球开始发售新一代嵌入式高性能计算平台Jetson TX2,相比起上一代 Jets...

    GPUS Lady
  • 一次奇怪的的bug排查过程

    公司对底层基础库进行了重构,线上稳定跑了几天,在查看订单系统的log时,有几条error信息非常的奇怪,

    lpxxn
  • 10分钟看懂Docker和kubernetes

    2010年,几个搞IT的年轻人,在美国旧金山成立了一家名叫“dotCloud”的公司。

    kubernetes中文社区
  • 云原生的发展路线中考虑过我的未来吗?

    本文仅用于简单普及,达到的目的是给没接触过或者很少接触过这方面的人一点感觉,阅读起来会比较轻松,作者深知短篇幅文章是不可能真正教会什么的,所以也不会出现 RTF...

    公众号: 云原生生态圈
  • 记一次线上偶现的循环依赖问题

    前情回顾 一探 Spring 的循环依赖,源码详细分析 → 真的非要三级缓存吗 中讲到了循环依赖问题 同样说明了 Spring 只能解决 setter 方式的循...

    程序猿DD
  • 我建议你别基于k8s用写应用 No.178

    最近一个月大蕉断更了,主要就在做一些跟 k8s 相关的事情,就在昨天刚刚交付产品了一个版本,这几周几乎把大蕉榨干了。但是大蕉从来不是一个怕事的人,干就完了,一个...

    大蕉
  • Hadoop 对象存储 Ozone

    Apache Hadoop 项目至今已经有十多年的历史了,作为大数据的基石,自从投放之社区之后就引来了不少的眼球,进而也孕育出了众多的Apache项目,例如HB...

    Fayson
  • 深圳某游戏研发公司给每个工位都装监控,网友:堪比坐牢!

    在前几日,网传深圳一公司办公室内,每个工位上方都安装有监控摄像头。 从爆料的图片可以看出,摄像头直对电脑屏幕,员工的操作可以被清晰拍到。 这操作,把网友都...

    用户1737318

扫码关注腾讯云开发者

领取腾讯云代金券