成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

Kubernetes 應(yīng)用問(wèn)題的通用排查思路

作者： IT明哥
云計(jì)算
本片文章介紹下 Kubernetes 應(yīng)用問(wèn)題的通用排查思路，分享一個(gè)線上此類(lèi)問(wèn)題的排查案例，總結(jié)下背后的相關(guān)知識(shí)，以饗讀者，大家共勉！

[[428799]]

本文轉(zhuǎn)載自微信公眾號(hào)「明哥的IT隨筆」，作者IT明哥。轉(zhuǎn)載本文請(qǐng)聯(lián)系明哥的IT隨筆公眾號(hào)。

大家好，我是明哥！

本片文章介紹下 Kubernetes 應(yīng)用問(wèn)題的通用排查思路，分享一個(gè)線上此類(lèi)問(wèn)題的排查案例，總結(jié)下背后的相關(guān)知識(shí)，以饗讀者，大家共勉！

1 技術(shù)趨勢(shì)大背景

我們知道，大數(shù)據(jù)進(jìn)一步發(fā)展的一個(gè)趨勢(shì)，就是大數(shù)據(jù)和云計(jì)算進(jìn)一步融合（包括在底層更加青睞存儲(chǔ)計(jì)算分離的架構(gòu)，在底層更加青睞對(duì)象存儲(chǔ)），在部署架構(gòu)上支持混合云和多云場(chǎng)景，擁抱云計(jì)算走向云原生化。

對(duì)應(yīng)到底層具體技術(shù)堆棧上，體現(xiàn)在各個(gè)主流大數(shù)據(jù)平臺(tái)和底層的大數(shù)據(jù)組件，紛紛開(kāi)始支持以 Kubernetes 和 Docker 為代表的容器系列技術(shù)棧。

所以大數(shù)據(jù)從業(yè)者，需要不斷擴(kuò)展自己的技能包，掌握 Kubernetes 和 Docker 的基礎(chǔ)知識(shí)和常見(jiàn)命令，才能在排查大數(shù)據(jù)相關(guān)問(wèn)題時(shí)不至于捉襟見(jiàn)肘，因技能儲(chǔ)備短缺，無(wú)從下手。

從技術(shù)視角看大數(shù)據(jù)行業(yè)的發(fā)展趨勢(shì)

在此分享一個(gè)大數(shù)據(jù)平臺(tái)中 docker 容器相關(guān)故障的排查案列，并介紹下此類(lèi)問(wèn)題的背后知識(shí)和排查思路，以饗讀者，大家共勉！

2 問(wèn)題現(xiàn)象

星環(huán)大數(shù)據(jù)平臺(tái) TDH 中， zookeeper 服務(wù)無(wú)法正常啟動(dòng)。我們知道 TDH 中，各個(gè)服務(wù)其實(shí)是在 k8s 的管控下運(yùn)行于 docker 容器中，通過(guò) kubectl get pods -owide |grep -i zoo 可以發(fā)現(xiàn)，對(duì)應(yīng)的 pod 的狀態(tài)是CrashLoopBackOff，如下圖所示:

pod-CrashLoopBackOff

3 背后知識(shí)：什么是 CrashLoopBackOff?

某個(gè) pod 處于 CrashloopBackOff， 意味著該 pod 中的容器被啟動(dòng)了，然后崩潰了，接下來(lái)又被自動(dòng)啟動(dòng)了，但又崩潰了，如此周而復(fù)始，陷入了（starting, crashing, starting，crashing）的循壞.

注意：pod 中的容器之所以會(huì)被自動(dòng)重啟，其實(shí)是通過(guò) PodSpec 中的 restartPolicy 指定的，該配置項(xiàng)默認(rèn)是 Always，即失敗后會(huì)自動(dòng)重啟：

  • A PodSpec has a restartPolicy field with possible values Always, OnFailure, and Never which applies to all containers in a pod， the default value is Always;
  • The restartPolicy only refers to restarts of the containers by the kubelet on the same node (so the restart count will reset if the pod is rescheduled in a different node).
  • Failed containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s …) capped at five minutes, and is reset after ten minutes of successful execution.

4 背后知識(shí)：為什么會(huì)發(fā)生 CrashLoopBackOff 錯(cuò)誤？

pod 的 CrashLoopBackOff 錯(cuò)誤還是挺常見(jiàn)的，該錯(cuò)誤可能會(huì)因?yàn)槎喾N原因被觸發(fā)，幾個(gè)主要的上層原因有：

  • Kubernetes 集群部署有問(wèn)題;
  • 該 pod 或 pod 底層的 container 的某些參數(shù)被配置錯(cuò)了；
  • 該 pod 內(nèi)部的 container 中運(yùn)行的應(yīng)用程序，在多次重啟運(yùn)行時(shí)都一直處于失敗狀態(tài)；

5 背后知識(shí)：如何排查 pod 容器底層的應(yīng)用程序的故障?

當(dāng) pod 容器底層的應(yīng)用程序運(yùn)行出現(xiàn)故障時(shí)，通用的排查思路，一般是：

  • 步驟一：通過(guò)命令 kubectl describe pod xxx 獲取 pod 詳細(xì)信息
  • 步驟二：通過(guò)命令 kubectl logs xxx 查看 pod 容器底層的應(yīng)用程序的日志
  • 步驟三：進(jìn)一步獲取并查看 pod 容器底層的應(yīng)用程序的其它日志文件，深挖問(wèn)題原因

有的小伙伴可能會(huì)有疑問(wèn)，上述步驟二和步驟三都是查看 pod 容器底層的應(yīng)用程序的日志，有什么區(qū)別呢？

其實(shí)步驟二和步驟三在底層查看的是應(yīng)用程序的不同的日志文件，其底層細(xì)節(jié)跟 kubernetes 的日志機(jī)制，以及該 pod 底層的應(yīng)用程序?qū)⑷罩緦?xiě)向何處有關(guān)：

  • kubectl logs 展示的是 pod 底層的 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr 的日志；
  • 應(yīng)用程序?qū)懙狡渌募娜罩荆琸ubectl logs 展示不了，需要獲取日志文件路徑，并自行查看；
  • k8s 建議應(yīng)用程序?qū)⑷罩緦?xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr；
  • 容器內(nèi)的應(yīng)用程序可以將日志直接寫(xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr；
  • 如果容器內(nèi)的應(yīng)用程序不能或不方便將日志直接寫(xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr，可以使用 sidecar 即邊車(chē)模式，在應(yīng)用程序的 container 所在的 pod 內(nèi)部署另一個(gè) sidecar container，該 sidecar container 負(fù)責(zé)讀取應(yīng)用程序的日志文件并輸出到其標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr 里；
  • k8s 在底層會(huì)通過(guò)運(yùn)行在各個(gè)節(jié)點(diǎn)的 kubelet 來(lái)收集節(jié)點(diǎn)中所有 container 的 stdout 和 stderr 日志，并寫(xiě)到一個(gè) kubelet 管理的本地文件中；
  • 用戶(hù)執(zhí)行 kubectl logs xx 命令時(shí)，該命令在底層會(huì)調(diào)用該 container 對(duì)應(yīng)節(jié)點(diǎn)上的 kubelet 來(lái)檢索其管理的本地日志文件，以獲取日志;
  • 用戶(hù)使用 kubectl log xxx 來(lái)檢索應(yīng)用程序日志，省去了用戶(hù)登錄 k8s 集群中對(duì)應(yīng)節(jié)點(diǎn)查看對(duì)應(yīng)日志的繁瑣操作，提供了很大遍歷；

ps. 我們這里討論的是運(yùn)行在 k8s 容器中的應(yīng)用程序的日志，除了應(yīng)用程序的日志，其實(shí)整個(gè)k8s 集群中還有很多系統(tǒng)組件的日志，如：docker，kubelet，kube-proxy，kube-apiserver，kube-scheduler，etcd等。

6 問(wèn)題排查復(fù)盤(pán)

按照上述通用問(wèn)題排查思路，我們復(fù)盤(pán)回顧下該 CrashLoopBackOff 問(wèn)題的排查經(jīng)過(guò)。

6.1：?jiǎn)栴}排查復(fù)盤(pán)：通過(guò)命令 kubeclt describe pod xxx 獲取 pod 詳細(xì)信息

該命令輸出的部分截圖如下，通過(guò)輸出中 Events 部分，我們可以獲取如下信息：該 pod 被成功地分配到了某個(gè)節(jié)點(diǎn)上，然后鏡像拉取成功，然后 contaier 創(chuàng)建和啟動(dòng)成功，但隨后 contaier 中程序運(yùn)行失敗，最后 pod 進(jìn)入到了 BackOff 狀態(tài)：

kubectl-describe-pod

該命令的詳細(xì)輸出如下：

  1. kubectl describe pod zookeeper-server-license-7fbfc544fc-h8nn9 
  2. Name:               zookeeper-server-license-7fbfc544fc-h8nn9 
  3. Namespace:          default 
  4. Priority:           0 
  5. PriorityClassName:  <none> 
  6. Node:               uf30-tdh3-regression/10.20.159.115 
  7. Start Time:         Mon, 11 Oct 2021 16:56:30 +0800 
  8. Labels:             name=zookeeper-server-license 
  9.                     pod-template-hash=3969710097 
  10.                     podConflictName=zookeeper-server-license 
  11. Annotations:        <none> 
  12. Status:             Running 
  13. IP:                 10.20.159.115 
  14. Controlled By:      ReplicaSet/zookeeper-server-license-7fbfc544fc 
  15. Containers: 
  16.   zookeeper-server-license: 
  17.     Container ID:  docker://0887c97ab185f1b004759e8c85b48631f511cb43088424190c3f27c715bb8414 
  18.     Image:         transwarp/zookeeper:transwarp-6.0.2-final 
  19.     Image ID:      docker-pullable://transwarp/zookeeper@sha256:19bf952dedc70a1d82ba9dd9217a2b7e34fc018561c2741d8f6065c0d87f8a10 
  20.     Port:          <none> 
  21.     Args: 
  22.       boot.sh 
  23.       LICENSE_NODE 
  24.     State:          Terminated 
  25.       Reason:       Error 
  26.       Exit Code:    1 
  27.       Started:      Mon, 11 Oct 2021 17:12:09 +0800 
  28.       Finished:     Mon, 11 Oct 2021 17:12:10 +0800 
  29.     Last State:     Terminated 
  30.       Reason:       Error 
  31.       Exit Code:    1 
  32.       Started:      Mon, 11 Oct 2021 17:07:07 +0800 
  33.       Finished:     Mon, 11 Oct 2021 17:07:08 +0800 
  34.     Ready:          False 
  35.     Restart Count:  8 
  36.     Environment: 
  37.       ZOOKEEPER_CONF_DIR:  /etc/license/conf 
  38.     Mounts: 
  39.       /etc/license/conf from conf (rw) 
  40.       /etc/localtime from timezone (rw) 
  41.       /etc/tos/conf from tos (rw) 
  42.       /etc/transwarp/conf from transwarphosts (rw) 
  43.       /usr/lib/transwarp/plugins from plugin (rw) 
  44.       /var/license from data (rw) 
  45.       /var/log/license/ from log (rw) 
  46.       /var/run/secrets/kubernetes.io/serviceaccount from default-token-g42jt (ro) 
  47.       /vdir from mountbind (rw) 
  48. Conditions: 
  49.   Type           Status 
  50.   Initialized    True  
  51.   Ready          False  
  52.   PodScheduled   True  
  53. Volumes: 
  54.   data: 
  55.     Type:          HostPath (bare host directory volume) 
  56.     Path:          /var/license 
  57.     HostPathType:   
  58.   conf: 
  59.     Type:          HostPath (bare host directory volume) 
  60.     Path:          /etc/license/conf 
  61.     HostPathType:   
  62.   log: 
  63.     Type:          HostPath (bare host directory volume) 
  64.     Path:          /var/log/license/ 
  65.     HostPathType:   
  66.   mountbind: 
  67.     Type:          HostPath (bare host directory volume) 
  68.     Path:          /transwarp/mounts/license 
  69.     HostPathType:   
  70.   plugin: 
  71.     Type:          HostPath (bare host directory volume) 
  72.     Path:          /usr/lib/transwarp/plugins 
  73.     HostPathType:   
  74.   timezone: 
  75.     Type:          HostPath (bare host directory volume) 
  76.     Path:          /etc/localtime 
  77.     HostPathType:   
  78.   transwarphosts: 
  79.     Type:          HostPath (bare host directory volume) 
  80.     Path:          /etc/transwarp/conf 
  81.     HostPathType:   
  82.   tos: 
  83.     Type:          HostPath (bare host directory volume) 
  84.     Path:          /etc/tos/conf 
  85.     HostPathType:   
  86.   default-token-g42jt: 
  87.     Type:        Secret (a volume populated by a Secret) 
  88.     SecretName:  default-token-g42jt 
  89.     Optional:    false 
  90. QoS Class:       BestEffort 
  91. Node-Selectors:  zookeeper-server-license=true 
  92. Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s 
  93.                  node.kubernetes.io/unreachable:NoExecute for 300s 
  94. Events: 
  95.   Type     Reason                 Age                 From                           Message 
  96.   ----     ------                 ----                ----                           ------- 
  97.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "default-token-g42jt" 
  98.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "conf" 
  99.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "tos" 
  100.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "mountbind" 
  101.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "transwarphosts" 
  102.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "log" 
  103.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "plugin" 
  104.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "data" 
  105.   Normal   SuccessfulMountVolume  15m                 kubelet, uf30-tdh3-regression  MountVolume.SetUp succeeded for volume "timezone" 
  106.   Normal   Scheduled              15m                 default-scheduler              Successfully assigned zookeeper-server-license-7fbfc544fc-h8nn9 to uf30-tdh3-regression 
  107.   Normal   Pulled                 15m (x3 over 15m)   kubelet, uf30-tdh3-regression  Successfully pulled image "transwarp/zookeeper:transwarp-6.0.2-final" 
  108.   Normal   Created                15m (x3 over 15m)   kubelet, uf30-tdh3-regression  Created container 
  109.   Normal   Started                15m (x3 over 15m)   kubelet, uf30-tdh3-regression  Started container 
  110.   Normal   Pulling                15m (x4 over 15m)   kubelet, uf30-tdh3-regression  pulling image "transwarp/zookeeper:transwarp-6.0.2-final" 
  111.   Warning  BackOff                44s (x70 over 15m)  kubelet, uf30-tdh3-regression  Back-off restarting failed container 

6.2 問(wèn)題排查復(fù)盤(pán)：通過(guò)命令 kubectl logs xxx 查看 pod 容器底層的應(yīng)用程序的日志

接下來(lái)我們嘗試通過(guò)命令 kubectl logs xxx 查看 pod 容器底層的應(yīng)用程序的日志，以期找到問(wèn)題的原因，該命令的輸出部分截圖如下所示：圖片

如上圖所見(jiàn)，不幸的是，該命令的輸出，沒(méi)有展示出問(wèn)題的根本原因。

在底層日志機(jī)制上，應(yīng)該是星環(huán) tdh 中該 zk 應(yīng)用沒(méi)有將日志打印到標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr, 所以 kubectl logs xxx 查看不到對(duì)應(yīng)的日志。

我們需要進(jìn)一步排查。

6.3 問(wèn)題排查復(fù)盤(pán)：進(jìn)一步獲取并查看 pod 容器底層的應(yīng)用程序的其它日志文件，深挖問(wèn)題原因

進(jìn)一步排查問(wèn)題，我們首先需要獲取 pod 容器底層的應(yīng)用程序的其它日志文件的路徑。

由于 tdh 是閉源的，我們查看不到應(yīng)用程序的源碼，在沒(méi)有聯(lián)絡(luò)官方客戶(hù)的情況下，我們可以通過(guò)命令 kubectl describe pod xxx 查看該 pod 掛載了哪些 volume，然后猜測(cè)并驗(yàn)證獲得具體的日志文件的路勁給，（排查問(wèn)題就是要，大膽猜想，小心求證?。?/p>

該命令輸出的部分截圖如下，我們看到其中掛載了路徑 /var/log/license:

接下來(lái)我們查看這些日志文件/var/log/license，嘗試深挖問(wèn)題原因，注意，該文件是本地文件系統(tǒng)的文件，需要登錄到對(duì)應(yīng)的節(jié)點(diǎn)上去查看，該日志文件部分關(guān)鍵截圖如下：

通過(guò)日志，問(wèn)題原因找到了：zk 底層存儲(chǔ)在本地文件系統(tǒng)中的文件 /var/license/version-2/snapshot.70000007a 損壞了，所以無(wú)法啟動(dòng):

  1. 2021-10-11 17:07:08,330 ERROR org.apache.zookeeper.server.persistence.Util: [myid:16] - [main:Util@239] - Last transaction was partial. 
  2. 2021-10-11 17:07:08,331 ERROR org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@453] - Unable to load database on disk 
  3. java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:392) 

該日志文件詳細(xì)內(nèi)容如下：

  1. tail -50 /var/log/license/zookeeper.log 
  2. 2021-10-11 17:07:08,203 INFO  org.apache.zookeeper.server.DatadirCleanupManager: [myid:16] - [main:DatadirCleanupManager@101] - Purge task is not scheduled. 
  3. 2021-10-11 17:07:08,212 INFO  org.apache.zookeeper.server.quorum.QuorumPeerMain: [myid:16] - [main:QuorumPeerMain@127] - Starting quorum peer 
  4. 2021-10-11 17:07:08,221 INFO  org.apache.zookeeper.server.NIOServerCnxnFactory: [myid:16] - [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:2291 
  5. 2021-10-11 17:07:08,235 INFO  org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@913] - tickTime set to 9000 
  6. 2021-10-11 17:07:08,235 INFO  org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@933] - minSessionTimeout set to -1 
  7. 2021-10-11 17:07:08,235 INFO  org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@944] - maxSessionTimeout set to -1 
  8. 2021-10-11 17:07:08,236 INFO  org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@959] - initLimit set to 10 
  9. 2021-10-11 17:07:08,285 INFO  org.apache.zookeeper.server.persistence.FileSnap: [myid:16] - [main:FileSnap@83] - Reading snapshot /var/license/version-2/snapshot.70000007a 
  10. 2021-10-11 17:07:08,330 ERROR org.apache.zookeeper.server.persistence.Util: [myid:16] - [main:Util@239] - Last transaction was partial. 
  11. 2021-10-11 17:07:08,331 ERROR org.apache.zookeeper.server.quorum.QuorumPeer: [myid:16] - [main:QuorumPeer@453] - Unable to load database on disk 
  12. java.io.EOFException 
  13.         at java.io.DataInputStream.readInt(DataInputStream.java:392) 
  14.         at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) 
  15.         at org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64) 
  16.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558) 
  17.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577) 
  18.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543) 
  19.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625) 
  20.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529) 
  21.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.<init>(FileTxnLog.java:504) 
  22.         at org.apache.zookeeper.server.persistence.FileTxnLog.read(FileTxnLog.java:341) 
  23.         at org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:132) 
  24.         at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223) 
  25.         at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:417) 
  26.         at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409) 
  27.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151) 
  28.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111) 
  29.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78) 
  30. 2021-10-11 17:07:08,332 ERROR org.apache.zookeeper.server.quorum.QuorumPeerMain: [myid:16] - [main:QuorumPeerMain@89] - Unexpected exception, exiting abnormally 
  31. java.lang.RuntimeException: Unable to run quorum server  
  32.         at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:454) 
  33.         at org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:409) 
  34.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:151) 
  35.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:111) 
  36.         at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78) 
  37. Caused by: java.io.EOFException 
  38.         at java.io.DataInputStream.readInt(DataInputStream.java:392) 
  39.         at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) 
  40.         at org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64) 
  41.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558) 
  42.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577) 
  43.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543) 
  44.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625) 
  45.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529) 
  46.         at org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.<init>(FileTxnLog.java:504) 
  47.         at org.apache.zookeeper.server.persistence.FileTxnLog.read(FileTxnLog.java:341) 
  48.         at org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:132) 
  49.         at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223) 
  50.         at org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:417) 
  51.         ... 4 more 

7 問(wèn)題解決

通過(guò)以上通用問(wèn)題排查思路，我們查看日志找到了問(wèn)題原因：zk 底層存儲(chǔ)在本地文件系統(tǒng)中的文件 /var/license/version-2/snapshot.70000007a 損壞了，所以無(wú)法啟動(dòng)。由于集群中 zk 是有多個(gè)節(jié)點(diǎn)的，且其它節(jié)點(diǎn)的 zk 啟動(dòng)是成功的，所以我們 可以刪除該問(wèn)題節(jié)點(diǎn)上述目錄下的數(shù)據(jù)文件，然后重啟該節(jié)點(diǎn)的 zk， 重啟后該節(jié)點(diǎn)的 zk 就可以從其它節(jié)點(diǎn)復(fù)制數(shù)據(jù)到本地，就可以正常對(duì)外提供服務(wù)了！

zk 底層存儲(chǔ)在本地文件系統(tǒng)中的文件，在正常節(jié)點(diǎn)于問(wèn)題節(jié)點(diǎn)，對(duì)比截圖如下：

zk data on good node

zk data on bad node

按照上述方法，清空目錄重啟zk后，kubectl get pods 查看服務(wù)正常，截圖如下：

kubectl-get-pods-after-fix

注意：其實(shí) zk 也提供了系統(tǒng)工具 zkCleanup.sh 來(lái)清理本地?cái)?shù)據(jù)文件，筆者沒(méi)有使用該工具，而是手工備份和清空了問(wèn)題節(jié)點(diǎn)的本地文件。大家可以自行嘗試該工具。

zkCleanup.sh

8 知識(shí)總結(jié)

  • 大數(shù)據(jù)從業(yè)者，需要不斷擴(kuò)展自己的技能包，掌握 Kubernetes 和 Docker 的基礎(chǔ)知識(shí)和常見(jiàn)命令，才能在排查大數(shù)據(jù)相關(guān)問(wèn)題時(shí)不至于捉襟見(jiàn)肘，因技能儲(chǔ)備短缺，無(wú)從下手;
  • 某個(gè) pod 處于 CrashloopBackOff， 意味著該 pod 中的容器被啟動(dòng)了，然后崩潰了，接下來(lái)又被自動(dòng)啟動(dòng)了，但又崩潰了，如此周而復(fù)始，陷入了（starting, crashing, starting，crashing）的循壞;
  • 當(dāng) pod 容器底層的應(yīng)用程序運(yùn)行出現(xiàn)故障時(shí)，通用的排查思路，一般是：

步驟一：通過(guò)命令 kubectl describe pod xxx 獲取 pod 詳細(xì)信息;

步驟二：通過(guò)命令 kubectl logs xxx 查看 pod 容器底層的應(yīng)用程序的日志;

步驟三：進(jìn)一步獲取并查看 pod 容器底層的應(yīng)用程序的其它日志文件，深挖問(wèn)題原因;

  • kubectl logs 展示的是 pod 底層的 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr 的日志, 應(yīng)用程序?qū)懙狡渌募娜罩?，kubectl logs 展示不了，需要獲取日志文件路徑，并自行查看；
  • k8s 建議應(yīng)用程序?qū)⑷罩緦?xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr；
  • 容器內(nèi)的應(yīng)用程序可以將日志直接寫(xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr；如果容器內(nèi)的應(yīng)用程序不能或不方便將日志直接寫(xiě)到 container 的標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr，可以使用 sidecar 即邊車(chē)模式，在應(yīng)用程序的 container 所在的 pod 內(nèi)部署另一個(gè) sidecar container，該 sidecar container 負(fù)責(zé)讀取應(yīng)用程序的日志文件并輸出到其標(biāo)準(zhǔn)輸出 stdout 和標(biāo)準(zhǔn)錯(cuò)誤 stderr 里；
  • k8s 在底層會(huì)通過(guò)運(yùn)行在各個(gè)節(jié)點(diǎn)的 kubelet 來(lái)收集節(jié)點(diǎn)中所有 container 的 stdout 和 stderr 日志，并寫(xiě)到一個(gè) kubelet 管理的本地文件中；
  • 用戶(hù)執(zhí)行 kubectl logs xx 命令時(shí)，該命令在底層會(huì)調(diào)用該 container 對(duì)應(yīng)節(jié)點(diǎn)上的 kubelet 來(lái)檢索其管理的本地日志文件，以獲取日志;
  • 用戶(hù)使用 kubectl log xxx 來(lái)檢索應(yīng)用程序日志，省去了用戶(hù)登錄 k8s 集群中對(duì)應(yīng)節(jié)點(diǎn)查看對(duì)應(yīng)日志的繁瑣操作，提供了很大便利；
  • 排查問(wèn)題，需要大膽猜想小心求證！

 

責(zé)任編輯：武曉燕 來(lái)源： 明哥的IT隨筆
Kubernetes通用排查
相關(guān)推薦

2023-10-08 13:10:00

Redis數(shù)據(jù)庫(kù)

2019-12-13 10:50:10

TCP排查服務(wù)器

2023-05-18 08:00:00

2024-03-15 10:05:13

Kubernetes容器云原生

2023-10-13 12:05:55

RedisBig Key

2021-04-19 17:25:08

Kubernetes組件網(wǎng)絡(luò)

2019-07-16 06:43:18

LinuxCPU占用率

2021-09-26 19:39:58

MogDB故障數(shù)據(jù)庫(kù)

2021-04-25 09:25:25

Linux手工排查

2021-04-19 08:02:54

Windows手工入侵

2024-02-20 16:55:14

K8S云計(jì)算

2021-03-29 12:35:04

Kubernetes環(huán)境TCP

2019-12-09 10:40:15

YAMLBashKubernetes

2020-04-08 11:12:37

Linux開(kāi)發(fā)工具

2022-04-03 19:51:38

linux服務(wù)性能

2020-09-25 11:10:51

運(yùn)維故障排查監(jiān)控

2021-10-28 17:05:11

IT運(yùn)維故障

2021-03-03 08:57:46

java死鎖線程

2010-09-25 15:19:04

DHCP故障問(wèn)題

2024-08-14 14:20:00

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)

主站蜘蛛池模板： 在线视频久久 | 欧美日韩电影一区二区 | 欧美日韩高清一区二区三区 | 波多野结衣精品在线 | 亚洲电影成人 | 精品乱子伦一区二区三区 | 欧美a在线 | 精品久久久久久久 | 国产第一页在线播放 | 久久精品国产亚洲夜色av网站 | 亚洲一区二区免费视频 | 国产9999精品 | 国产欧美日韩一区 | 国产精品久久久久久久久久久久久久 | 国产精品日韩欧美一区二区三区 | 国产精品www | 9久9久9久女女女九九九一九 | 91精品国产91久久久久久最新 | 91伊人 | 午夜影视网 | 天堂一区在线观看 | 国产欧美视频一区二区三区 | h片在线看 | 国产成人精品久久二区二区91 | 日韩喷潮| 日韩av资源站 | 亚洲精品天堂 | 久久久成人免费一区二区 | 日韩精品一二三 | 亚洲欧洲精品一区 | 精久久久| 亚洲在线 | 天天综合久久 | 午夜丁香视频在线观看 | 成年男女免费视频网站 | 超黄毛片 | 亚洲最色网站 | 国产激情一区二区三区 | 国产精品乱码一区二区三区 | 岛国毛片在线观看 | 综合激情av |