kubernetes k8s常用問題排查方法

更新時(shí)間：2022年06月25日 14:41:25 作者：kevinyan

新手學(xué)習(xí)K8s最大的難度感覺是在起步動(dòng)手實(shí)踐的時(shí)候，Pod沒有正常啟動(dòng)起來，或者運(yùn)行了一段時(shí)間Pod自己崩潰了。是什么問題導(dǎo)致了它沒運(yùn)行起來，或是什么因素導(dǎo)致了它的崩潰，本文來學(xué)習(xí)總結(jié)幾個(gè)使用 K8s時(shí)常見的錯(cuò)誤現(xiàn)象以及排查這些現(xiàn)象背后問題的方法

Pod 的那些狀態(tài)

使用 K8s 部署我們的服務(wù)之后，為了觀察 Pod 是否成功，我們都會(huì)使用下面這個(gè)命令查詢 Pod 的狀態(tài)。

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 的狀態(tài)，可能會(huì)遇到的狀態(tài)有下面幾個(gè)：

ContainerCreating：代表容器正在創(chuàng)建，這是一個(gè)中間狀態(tài)，隨著容器創(chuàng)建成功會(huì)切換，但是也有可能一直卡在這里，具體問題下面會(huì)分析。
ImagePullBackOff：容器鏡像拉取失敗，具體原因需要結(jié)合 describe 命令再去查看。
CrashLoopBackOff：容器崩潰，一般容器崩潰，Deployment 會(huì)重新創(chuàng)建一個(gè) Pod，維持副本數(shù)量，但是大概率新創(chuàng)建的Pod 還是會(huì)崩潰，它不會(huì)無限嘗試，崩潰超過設(shè)置次數(shù)就不會(huì)再嘗試重建Pod，此時(shí)Pod的狀態(tài)就維持在了 CrashLoopBackOff。
Evicted: 因?yàn)楣?jié)點(diǎn)資源不足（CPU/Mem/Storage都有可能），Pod 被驅(qū)逐會(huì)顯示 Evicted 狀態(tài)，K8s 會(huì)按照策略選擇認(rèn)為可驅(qū)逐的Pod從節(jié)點(diǎn)上 Kill 掉。
Running 這個(gè)代表 Pod 正常運(yùn)行。

下面我們來看一下 Pod 的幾個(gè)錯(cuò)誤狀態(tài)的原因，以及怎么排查解決它們。

鏡像拉取失敗

鏡像拉取失敗后 Pod 的狀態(tài)字段表示為 ImagePullBackOff，這個(gè)發(fā)生的情況還是很多的，原因除了我們不小心寫錯(cuò)鏡像名字之外，還有就是常用軟件的一些官方鏡像都在國外，比如在docker.io 或者 quay.io 的鏡像倉庫上，有的時(shí)候訪問速度會(huì)很慢。

下面我們自己故意制造一個(gè)鏡像名字寫錯(cuò)的場景，看怎么使用 kubectl 命令進(jìn)行排查。比如我在 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: {}

我們把鏡像的名字故意改錯(cuò)，改成 v0.5，這個(gè)鏡像是我自己打的，確實(shí)還沒有 0.5 版本。執(zhí)行kubectl apply 后，來觀察一下 Pod 的狀態(tài)。

? 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 的狀態(tài)
? 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 的狀態(tài)變化過程是：

ContainerCreating ===> ErrImagePull ===> ImagePullBackOff

首先 deployment 更新 Pod 時(shí)是滾動(dòng)更新，要先把新 Pod 創(chuàng)建出來后能對(duì)舊版本 Pod 完成替換。接下來由于鏡像拉取錯(cuò)誤會(huì)反饋一個(gè)中間狀態(tài) ErrImagePull，此時(shí)會(huì)再次嘗試?yán)?，如果確定鏡像拉取不下來后，最后反饋一個(gè)失敗的終態(tài) ImagePullBackOff。

怎么排查是什么導(dǎo)致的拉取失敗呢？通過 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:              &lt;none&gt;
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 從開始到最后經(jīng)歷的狀態(tài)變化，以及是什么導(dǎo)致狀態(tài)變化的，其中失敗事件里清楚的給出了我們原因，就是鏡像找不到。

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

還有一種是網(wǎng)絡(luò)原因，或者鏡像倉庫沒有權(quán)限拒絕拉取請求，導(dǎo)致無法拉取成功。因?yàn)槲疫@里網(wǎng)絡(luò)環(huán)境、加速器之類的好不容易都配好了，就不給大家演示這兩種情況了。

不過排查方式也是一樣，使用kubectl describe 命令查看 Pod 的事件，并且使用 docker pull 嘗試主動(dòng)的拉取一下鏡像試試，如果確實(shí)網(wǎng)絡(luò)問題拉取不下來的，可以考慮翻墻，或者使用國內(nèi)的加速節(jié)點(diǎn)。

配置加速器，可以考慮使用阿里云的免費(fèi)加速器，配置文檔在下面，需要注冊阿里云賬號(hào)才能使用加速器

https://help.aliyun.com/product/60716.html

啟動(dòng)后容器崩潰

再來看這種錯(cuò)誤，這種一般是容器里運(yùn)行的程序內(nèi)部出問題導(dǎo)致的容器連續(xù)崩潰出現(xiàn)的問題。最后反饋到 Pod 狀態(tài)上是 CrashLoopBackOff 狀態(tài)。

演示容器運(yùn)行中崩潰的情況有點(diǎn)難，不過好在我之前介紹 Go 服務(wù)自動(dòng)采樣的時(shí)候，做過一個(gè)鏡像

以下內(nèi)容引用我之前的文章：Go 服務(wù)進(jìn)行自動(dòng)采樣性能分析的方案設(shè)計(jì)與實(shí)現(xiàn)

我做了個(gè)docker 鏡像方便進(jìn)行試驗(yàn)，鏡像已經(jīng)上傳到了Docker Hub上，大家感興趣的可以Down下來自己在電腦上快速試驗(yàn)一下。

通過以下命令即可快速體驗(yàn)。

docker run --name go-profile-demo -v /tmp:/tmp -p 10030:80 --rm -d kevinyan001/go-profiling

容器里Go服務(wù)提供的路由如下

所以我們把上面的 deployment Pod 模版里的鏡像換成這個(gè) kevinyan001/go-profiling，再通過提供的路由手動(dòng)制造 OOM，來故意制造容器崩潰的情況。

修改Pod 使用的容器鏡像

#執(zhí)行 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"

創(chuàng)建個(gè) SVC 讓Pod能接受外部流量

#執(zhí)行 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 讓容器內(nèi)存溢出，因?yàn)?Deployment 會(huì)重啟崩潰的 Pod，所以這里非?？简?yàn)手速：）估計(jì)狂點(diǎn)一分鐘，Deployment 就放棄治療休息會(huì)兒再重啟 Pod，這時(shí) Pod 的狀態(tài)成功變成了：

? 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

這個(gè)時(shí)候我們使用 kubectl describe pod 看崩潰 Pod 的詳細(xì)信息，會(huì)看到容器內(nèi)程序返回的錯(cuò)誤碼

? 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 內(nèi)容器的問題，需要另一個(gè)命令 kubectl logs {pod-name} 的協(xié)助。

kubectl logs my-go-app-598f697676-tps7n

如果恰巧這個(gè) Pod 被重啟了，查不出來任何東西，可以通過增加 — previous 參數(shù)選項(xiàng)，查看之前容器的日志。

kubectl logs my-go-app-598f697676-tps7n --previous

容器被驅(qū)逐

首先聲明，這個(gè)問題研發(fā)解決不了，但是你發(fā)揮一下自己YY的能力：當(dāng)群里報(bào)警、運(yùn)維@你趕緊看的時(shí)候，你來個(gè)反殺，告訴他資源不夠了趕緊擴(kuò)容，是不是能裝到^_^…

扯遠(yuǎn)了，現(xiàn)在回正題。集群里資源緊張的時(shí)候，K8s 會(huì)優(yōu)先驅(qū)逐優(yōu)先級(jí)低的 Pod，被驅(qū)逐的 Pod 的狀態(tài)會(huì)是 Evicted，這個(gè)情況沒辦法在本地模擬，貼一個(gè)在公司K8s集群遇到這種情況的截圖。

kubectl get pod 查看Pod狀態(tài)

上圖可以看到有一個(gè)Pod 的狀態(tài)變成了 Evicted。

再來用describe 看下詳細(xì)信息

kubectl describe pod 查看Pod 的詳細(xì)信息和事件記錄

不好意思，歷史久遠(yuǎn)，上面的圖太模糊了，圖中的Message 一欄里有給出如下信息：

Status: Faild
Reason: Evicted
Message: The node wan low on resource: xxx-storage. Container xxx using xxxKi, 
which exceeds its request of ....

總結(jié)

一般來說，大多數(shù)常見的部署失敗都可以使用這些命令進(jìn)行排查和調(diào)試：

kubectl get pods

kubectl describe pod <podname>

kubectl logs <podname>

kubectl logs <podname> --previous

當(dāng)然，有的時(shí)候想看 Pod 的配置信息，還可以使用

kubectl get pod <podname> -o=yaml

驗(yàn)證一下Pod的配置是不是跟我們提交上去的一樣，以及一些其他的額外信息。

get 和 describe 這兩個(gè)命令除了能看 Pod 的狀態(tài)和信息記錄外，也能看其他資源的狀態(tài)和信息。

kubectl get pod|svc|deploy|sts|configmap &lt;xxx-name&gt;
kubectl describe pod|svc|deploy|sts|configmap &lt;xxx-name&gt;

這些就留給大家后面自己體驗(yàn)吧。為了方便大家在本地試驗(yàn)，在公眾號(hào)「網(wǎng)管叨bi叨」回復(fù)【k8s】能找到今天用的各種YAML的模版，感興趣的可以動(dòng)手實(shí)踐起來。

以上就是kubernetes k8s常用問題排查方法的詳細(xì)內(nèi)容，更多關(guān)于kubernetes k8s問題排查方法的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章:

亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

軟件下載

源碼下載

軟件編程

網(wǎng)絡(luò)編程

在線工具

數(shù)據(jù)庫

CMS

常用工具

kubernetes k8s常用問題排查方法

目錄

Pod 的那些狀態(tài)

鏡像拉取失敗

啟動(dòng)后容器崩潰

容器被驅(qū)逐

總結(jié)

相關(guān)文章

最新評(píng)論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具