自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Kubernetes 應用問題的通用排查思路

作者： IT明哥
云計算
本片文章介紹下 Kubernetes 應用問題的通用排查思路，分享一個線上此類問題的排查案例，總結下背后的相關知識，以饗讀者，大家共勉！

[[428799]]

本文轉載自微信公眾號「明哥的IT隨筆」，作者IT明哥。轉載本文請聯(lián)系明哥的IT隨筆公眾號。

大家好，我是明哥！

本片文章介紹下 Kubernetes 應用問題的通用排查思路，分享一個線上此類問題的排查案例，總結下背后的相關知識，以饗讀者，大家共勉！

1 技術趨勢大背景

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

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

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

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

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

2 問題現(xiàn)象

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

pod-CrashLoopBackOff

3 背后知識：什么是 CrashLoopBackOff?

某個 pod 處于 CrashloopBackOff， 意味著該 pod 中的容器被啟動了，然后崩潰了，接下來又被自動啟動了，但又崩潰了，如此周而復始，陷入了（starting, crashing, starting，crashing）的循壞.

注意：pod 中的容器之所以會被自動重啟，其實是通過 PodSpec 中的 restartPolicy 指定的，該配置項默認是 Always，即失敗后會自動重啟：

  • 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 背后知識：為什么會發(fā)生 CrashLoopBackOff 錯誤？

pod 的 CrashLoopBackOff 錯誤還是挺常見的，該錯誤可能會因為多種原因被觸發(fā)，幾個主要的上層原因有：

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

5 背后知識：如何排查 pod 容器底層的應用程序的故障?

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

  • 步驟一：通過命令 kubectl describe pod xxx 獲取 pod 詳細信息
  • 步驟二：通過命令 kubectl logs xxx 查看 pod 容器底層的應用程序的日志
  • 步驟三：進一步獲取并查看 pod 容器底層的應用程序的其它日志文件，深挖問題原因

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

其實步驟二和步驟三在底層查看的是應用程序的不同的日志文件，其底層細節(jié)跟 kubernetes 的日志機制，以及該 pod 底層的應用程序將日志寫向何處有關：

  • kubectl logs 展示的是 pod 底層的 container 的標準輸出 stdout 和標準錯誤 stderr 的日志；
  • 應用程序寫到其它文件的日志，kubectl logs 展示不了，需要獲取日志文件路徑，并自行查看；
  • k8s 建議應用程序將日志寫到 container 的標準輸出 stdout 和標準錯誤 stderr；
  • 容器內的應用程序可以將日志直接寫到 container 的標準輸出 stdout 和標準錯誤 stderr；
  • 如果容器內的應用程序不能或不方便將日志直接寫到 container 的標準輸出 stdout 和標準錯誤 stderr，可以使用 sidecar 即邊車模式，在應用程序的 container 所在的 pod 內部署另一個 sidecar container，該 sidecar container 負責讀取應用程序的日志文件并輸出到其標準輸出 stdout 和標準錯誤 stderr 里；
  • k8s 在底層會通過運行在各個節(jié)點的 kubelet 來收集節(jié)點中所有 container 的 stdout 和 stderr 日志，并寫到一個 kubelet 管理的本地文件中；
  • 用戶執(zhí)行 kubectl logs xx 命令時，該命令在底層會調用該 container 對應節(jié)點上的 kubelet 來檢索其管理的本地日志文件，以獲取日志;
  • 用戶使用 kubectl log xxx 來檢索應用程序日志，省去了用戶登錄 k8s 集群中對應節(jié)點查看對應日志的繁瑣操作，提供了很大遍歷；

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

6 問題排查復盤

按照上述通用問題排查思路，我們復盤回顧下該 CrashLoopBackOff 問題的排查經(jīng)過。

6.1：問題排查復盤：通過命令 kubeclt describe pod xxx 獲取 pod 詳細信息

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

kubectl-describe-pod

該命令的詳細輸出如下：

  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 問題排查復盤：通過命令 kubectl logs xxx 查看 pod 容器底層的應用程序的日志

接下來我們嘗試通過命令 kubectl logs xxx 查看 pod 容器底層的應用程序的日志，以期找到問題的原因，該命令的輸出部分截圖如下所示：圖片

如上圖所見，不幸的是，該命令的輸出，沒有展示出問題的根本原因。

在底層日志機制上，應該是星環(huán) tdh 中該 zk 應用沒有將日志打印到標準輸出 stdout 和標準錯誤 stderr, 所以 kubectl logs xxx 查看不到對應的日志。

我們需要進一步排查。

6.3 問題排查復盤：進一步獲取并查看 pod 容器底層的應用程序的其它日志文件，深挖問題原因

進一步排查問題，我們首先需要獲取 pod 容器底層的應用程序的其它日志文件的路徑。

由于 tdh 是閉源的，我們查看不到應用程序的源碼，在沒有聯(lián)絡官方客戶的情況下，我們可以通過命令 kubectl describe pod xxx 查看該 pod 掛載了哪些 volume，然后猜測并驗證獲得具體的日志文件的路勁給，（排查問題就是要，大膽猜想，小心求證！）

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

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

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

  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) 

該日志文件詳細內容如下：

  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 問題解決

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

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

zk data on good node

zk data on bad node

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

kubectl-get-pods-after-fix

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

zkCleanup.sh

8 知識總結

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

步驟一：通過命令 kubectl describe pod xxx 獲取 pod 詳細信息;

步驟二：通過命令 kubectl logs xxx 查看 pod 容器底層的應用程序的日志;

步驟三：進一步獲取并查看 pod 容器底層的應用程序的其它日志文件，深挖問題原因;

  • kubectl logs 展示的是 pod 底層的 container 的標準輸出 stdout 和標準錯誤 stderr 的日志, 應用程序寫到其它文件的日志，kubectl logs 展示不了，需要獲取日志文件路徑，并自行查看；
  • k8s 建議應用程序將日志寫到 container 的標準輸出 stdout 和標準錯誤 stderr；
  • 容器內的應用程序可以將日志直接寫到 container 的標準輸出 stdout 和標準錯誤 stderr；如果容器內的應用程序不能或不方便將日志直接寫到 container 的標準輸出 stdout 和標準錯誤 stderr，可以使用 sidecar 即邊車模式，在應用程序的 container 所在的 pod 內部署另一個 sidecar container，該 sidecar container 負責讀取應用程序的日志文件并輸出到其標準輸出 stdout 和標準錯誤 stderr 里；
  • k8s 在底層會通過運行在各個節(jié)點的 kubelet 來收集節(jié)點中所有 container 的 stdout 和 stderr 日志，并寫到一個 kubelet 管理的本地文件中；
  • 用戶執(zhí)行 kubectl logs xx 命令時，該命令在底層會調用該 container 對應節(jié)點上的 kubelet 來檢索其管理的本地日志文件，以獲取日志;
  • 用戶使用 kubectl log xxx 來檢索應用程序日志，省去了用戶登錄 k8s 集群中對應節(jié)點查看對應日志的繁瑣操作，提供了很大便利；
  • 排查問題，需要大膽猜想小心求證！

 

責任編輯：武曉燕 來源： 明哥的IT隨筆
Kubernetes通用排查
相關推薦

2019-12-13 10:50:10

TCP排查服務器

2023-10-08 13:10:00

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

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)絡

2021-04-25 09:25:25

Linux手工排查

2021-09-26 19:39:58

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

2019-07-16 06:43:18

LinuxCPU占用率

2021-04-19 08:02:54

Windows手工入侵

2024-02-20 16:55:14

K8S云計算

2021-03-29 12:35:04

Kubernetes環(huán)境TCP

2019-12-09 10:40:15

YAMLBashKubernetes

2020-04-08 11:12:37

Linux開發(fā)工具

2022-04-03 19:51:38

linux服務性能

2020-09-25 11:10:51

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

2021-10-28 17:05:11

IT運維故障

2021-07-30 20:59:21

MySQL內存.參數(shù)

2010-09-25 15:19:04

DHCP故障問題

2011-08-09 13:34:56

MySQL數(shù)據(jù)庫負荷較高
點贊
收藏

51CTO技術棧公眾號