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

超好用的k8s中pod診斷工具：Kubectl-debug

作者：冬子先生
運(yùn)維 系統(tǒng)運(yùn)維
今天為大家推薦一款K8s pod診斷工具，kubectl-debug是一個簡單、易用、強(qiáng)大的 kubectl 插件, 能夠幫助你便捷地進(jìn)行 Kubernetes 上的 Pod 排障診斷。

[[441330]]

背景

容器技術(shù)的一個最佳實踐是構(gòu)建盡可能精簡的容器鏡像。但這一實踐卻會給排查問題帶來麻煩：精簡后的容器中普遍缺失常用的排障工具，部分容器里甚至沒有 shell (比如 FROM scratch )。 在這種狀況下，我們只能通過日志或者到宿主機(jī)上通過 docker-cli 或 nsenter 來排查問題，效率很低，在K8s環(huán)境部署應(yīng)用后，經(jīng)常遇到需要進(jìn)入pod進(jìn)行排錯。除了查看pod logs和describe方式之外，傳統(tǒng)的解決方式是在業(yè)務(wù)pod基礎(chǔ)鏡像中提前安裝好procps、net-tools、tcpdump、vim等工具。但這樣既不符合最小化鏡像原則，又徒增Pod安全漏洞風(fēng)險。

今天為大家推薦一款K8s pod診斷工具，kubectl-debug是一個簡單、易用、強(qiáng)大的 kubectl 插件, 能夠幫助你便捷地進(jìn)行 Kubernetes 上的 Pod 排障診斷。它通過啟動一個排錯工具容器，并將其加入到目標(biāo)業(yè)務(wù)容器的pid, network, user 以及 ipc namespace 中，這時我們就可以在新容器中直接用 netstat, tcpdump 這些熟悉的工具來解決問題了, 而業(yè)務(wù)容器可以保持最小化, 不需要預(yù)裝任何額外的排障工具。 kubectl-debug 主要包含以下兩部分:

  • kubectl-debug：命令行工具
  • debug-agent：部署在K8s的node上，用于啟動關(guān)聯(lián)排錯工具容器

工作原理

我們知道，容器本質(zhì)上是帶有 cgroup 資源限制和 namespace 隔離的一組進(jìn)程。因此，我們只要啟動一個進(jìn)程，并且讓這個進(jìn)程加入到目標(biāo)容器的各種 namespace 中，這個進(jìn)程就能 “進(jìn)入容器內(nèi)部”(注意引號)，與容器中的進(jìn)程”看到”相同的根文件系統(tǒng)、虛擬網(wǎng)卡、進(jìn)程空間了——這也正是 docker exec 和 kubectl exec 等命令的運(yùn)行方式。

現(xiàn)在的狀況是，我們不僅要 “進(jìn)入容器內(nèi)部”，還希望帶一套工具集進(jìn)去幫忙排查問題。那么，想要高效管理一套工具集，又要可以跨平臺，最好的辦法就是把工具本身都打包在一個容器鏡像當(dāng)中。 接下來，我們只需要通過這個”工具鏡像”啟動容器，再指定這個容器加入目標(biāo)容器的的各種 namespace，自然就實現(xiàn)了 “攜帶一套工具集進(jìn)入容器內(nèi)部”。事實上，使用 docker-cli 就可以實現(xiàn)這個操作：

  1. export TARGET_ID=666666666 
  2. # 加入目標(biāo)容器的 network, pid 以及 ipc namespace 
  3. docker run -it --network=container:$TARGET_ID --pid=container:$TARGET_ID --ipc=container:$TARGET_ID busybox 

這就是 kubectl-debug 的出發(fā)點(diǎn)： 用工具容器來診斷業(yè)務(wù)容器 。背后的設(shè)計思路和 sidecar 等模式是一致的：每個容器只做一件事情。

具體到實現(xiàn)上，一條 kubectl debug命令背后邏輯流程是這樣的：

步驟分別是:

  1. 插件查詢 ApiServer：demo-pod 是否存在，所在節(jié)點(diǎn)是什么
  2. ApiServer 返回 demo-pod 所在所在節(jié)點(diǎn)
  3. 插件請求在目標(biāo)節(jié)點(diǎn)上創(chuàng)建 Debug Agent Pod
  4. Kubelet 創(chuàng)建 Debug Agent Pod
  5. 插件發(fā)現(xiàn) Debug Agent 已經(jīng) Ready，發(fā)起 debug 請求(長連接)
  6. Debug Agent 收到 debug 請求，創(chuàng)建 Debug 容器并加入目標(biāo)容器的各個 Namespace 中，創(chuàng)建完成后，與 Debug 容器的 tty 建立連接

接下來，客戶端就可以開始通過 5，6 這兩個連接開始 debug 操作。操作結(jié)束后，Debug Agent 清理 Debug 容器，插件清理 Debug Agent，一次 Debug 完成

安裝

github地址：https://github.com/aylei/kubectl-debug

Mac 可以直接使用 brew 安裝

  1. brew install aylei/tap/kubectl-debug 

通過下載二進(jìn)制文件安裝

  1. export PLUGIN_VERSION=0.1.1 
  2. # linux x86_64 
  3. curl -Lo kubectl-debug.tar.gz https://github.com/aylei/kubectl-debug/releases/download/v${PLUGIN_VERSION}/kubectl-debug_${PLUGIN_VERSION}_linux_amd64.tar.gz 
  4. # macos 
  5. curl -Lo kubectl-debug.tar.gz https://github.com/aylei/kubectl-debug/releases/download/v${PLUGIN_VERSION}/kubectl-debug_${PLUGIN_VERSION}_darwin_amd64.tar.gz 
  6.  
  7. tar -zxvf kubectl-debug.tar.gz kubectl-debug 
  8. sudo mv kubectl-debug /usr/local/bin/ 

Windows 用戶可以在Release 頁面選擇進(jìn)行下載windows版本，加入環(huán)境變量使用

其中g(shù)ithub上有提供debug agent以DaemonSet的方式安裝在集群中，但是daemonset模式，agent pod預(yù)先部署在所有node上，會始終占用資源，對于排錯調(diào)試頻率不高的環(huán)境造成資源浪費(fèi)

日常用法說明

簡單使用

1、kubectl 1.12.0 或更高的版本, 可以直接使用

  1. #查看常用命令參數(shù) 
  2. kubectl debug -h 

kubectl 從 1.12 版本之后開始支持從 PATH 中自動發(fā)現(xiàn)插件。1.12 版本之前的 kubectl 不支持這種插件機(jī)制，但也可以通過命令名 kubectl-debug 直接調(diào)用。

2、假如安裝了 debug-agent 的 daemonset, 可以略去 --agentless 來加快啟動速度，之后的命令里會略去 --agentless

  1. kubectl debug POD_NAME --daemonset-ns=default --daemonset-name=debug-agent 

其中g(shù)ithub上有提供debug agent以DaemonSet的方式安裝在集群中，但是daemonset模式，agent pod預(yù)先部署在所有node上，會始終占用資源，對于排錯調(diào)試頻率不高的環(huán)境造成資源浪費(fèi)，部署方式：kubectl apply -f https://raw.githubusercontent.com/aylei/kubectl-debug/master/scripts/agent_daemonset.yml

3、agentless模式，kubectl-debug執(zhí)行命令后，才創(chuàng)建agent pod和排錯工具容器，并在退出后刪除工具容器和agent pod。由于每次執(zhí)行都要重新拉起agent，啟動會比daemon-set模式稍慢。使用-a, --agentless開啟agentless模式：

  1. kubectl debug POD_NAME --agentless --port-forward 

4、假如 Node 沒有公網(wǎng) IP 或無法直接訪問(防火墻等原因), 請使用 port-forward 模式

  1. kubectl debug POD_NAME --agentless --port-forward 

進(jìn)階使用

1、排錯init-container

  1. kubectl debug POD_NAME --container=init-pod 

2、假如 Pod 處于 CrashLookBackoff 狀態(tài)無法連接, 可以復(fù)制一個完全相同的 Pod 來進(jìn)行診斷

  1. kubectl debug POD_NAME --fork 

自定義鏡像配置

  1. --image：可自定義排錯工具容器鏡像，改為私有鏡像倉庫，默認(rèn)為nicolaka/netshoot:latest 
  2. --agent-image：在agentless模式下，自定義debug-agent鏡像，默認(rèn)為aylei/debug-agent:latest。在daemon-set模式下，直接將debug-agent daemonset pod template修改為私有倉庫鏡像即可 

配置文件

~/.kube/debug-config，通過配置文件修改默認(rèn)參數(shù)，免去使用命令時設(shè)置flag。

  1. # debug agent listening port(outside container) 
  2. default to 10027 
  3. agentPort: 10027 
  4. whether using agentless mode 
  5. default to false 
  6. agentless: true 
  7. namespace of debug-agent pod, used in agentless mode 
  8. default to 'default' 
  9. agentPodNamespace: default 
  10. prefix of debug-agent pod, used in agentless mode 
  11. default to  'debug-agent-pod' 
  12. agentPodNamePrefix: debug-agent-pod 
  13. image of debug-agent pod, used in agentless mode 
  14. default to 'aylei/debug-agent:latest' 
  15. agentImage: aylei/debug-agent:latest 
  16. daemonset name of the debug-agent, used in port-forward 
  17. default to 'debug-agent' 
  18. debugAgentDaemonset: debug-agent 
  19. daemonset namespace of the debug-agent, used in port-forwad 
  20. default to 'default' 
  21. debugAgentNamespace: kube-system 
  22. whether using port-forward when connecting debug-agent 
  23. default false 
  24. portForward: true 
  25. image of the debug container 
  26. default as showed 
  27. image: nicolaka/netshoot:latest 
  28. start command of the debug container 
  29. default ['bash'] 
  30. command: 
  31. - '/bin/bash' 
  32. - '-l' 

典型案例

使用 iftop查看pod的網(wǎng)絡(luò)流量

比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的網(wǎng)絡(luò)流量：

  1.  ~  kubectl debug kube-flannel-ds-amd64-2xwqp -n kube-system 
  2. Agent Pod info: [Name:debug-agent-pod-b14bd868-61a9-11ec-bc72-acbc328370f3, Namespace:default, Image:registry.cn-hangzhou.aliyuncs.com/querycapimages/kubectl-debug-agent:latest, HostPort:10027, ContainerPort:10027] 
  3. Waiting for pod debug-agent-pod-b14bd868-61a9-11ec-bc72-acbc328370f3 to run... 
  4. Forwarding from 127.0.0.1:10027 -> 10027 
  5. Forwarding from [::1]:10027 -> 10027 
  6. Handling connection for 10027 
  7.                              set container procfs correct false .. 
  8. pulling image registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest, skip TLS false... 
  9. latest: Pulling from querycapimages/netshoot 
  10. Digest: sha256:f0eba49c9bf66600788d58779e57c2d7334708e12cb292ff8ccc9414c1b6730c 
  11. Status: Image is up to date for registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest 
  12. starting debug container... 
  13. container created, open tty... 
  14. bash-5.0# iftop -i eth0 
  15. interface: eth0 
  16. IP address is: 172.17.3.3 
  17. MAC address is: 52:54:be:83:3a:e4 

使用 drill 診斷 DNS 解析

比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的網(wǎng)絡(luò)流量：

  1. bash-5.0# drill any www.baidu.com 
  2. ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3214 
  3. ;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 3 
  4. ;; QUESTION SECTION: 
  5. ;; www.baidu.com. IN ANY 
  6.  
  7. ;; ANSWER SECTION: 
  8. www.baidu.com. 803 IN CNAME www.a.shifen.com. 
  9.  
  10. ;; AUTHORITY SECTION: 
  11. baidu.com. 38993 IN NS ns4.baidu.com. 
  12. baidu.com. 38993 IN NS ns3.baidu.com. 
  13. baidu.com. 38993 IN NS ns7.baidu.com. 
  14. baidu.com. 38993 IN NS dns.baidu.com. 
  15. baidu.com. 38993 IN NS ns2.baidu.com. 
  16.  
  17. ;; ADDITIONAL SECTION: 
  18. ns2.baidu.com. 19348 IN A 220.181.33.31 
  19. ns3.baidu.com. 23022 IN A 112.80.248.64 
  20. ns7.baidu.com. 20697 IN A 180.76.76.92 
  21.  
  22. ;; Query time: 1 msec 
  23. ;; SERVER: 100.64.9.5 
  24. ;; WHEN: Mon Dec 20 15:37:35 2021 
  25. ;; MSG SIZE  rcvd: 196 

drill 命令詳解：https://commandnotfound.cn/linux/1/533/drill-%E5%91%BD%E4%BB%A4

使用 tcpdump 抓包

比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的網(wǎng)絡(luò)流量：

  1. bash-5.0# tcpdump -i eth0 -c 1 -Xvv 
  2. tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 
  3. 15:39:27.577342 IP (tos 0x0, ttl 63, id 41476, offset 0, flags [DF], proto TCP (6), length 89) 
  4.     198.19.116.60.16710 > 172.17.3.3.6443: Flags [P.], cksum 0xf831 (correct), seq 677521811:677521848, ack 1388710574, win 1037, options [nop,nop,TS val 2849535414 ecr 1924260089], length 37 
  5.  0x0000:  4500 0059 a204 4000 3f06 b036 c613 743c  E..Y..@.?..6..t< 
  6.  0x0010:  ac11 0303 4146 192b 2862 2993 52c6 0aae  ....AF.+(b).R... 
  7.  0x0020:  8018 040d f831 0000 0101 080a a9d8 75b6  .....1........u. 
  8.  0x0030:  72b1 e0f9 1703 0300 2047 49f1 8fbb 2835  r........GI...(5 
  9.  0x0040:  059a 5e82 0746 afaf bd2d 5af3 c797 16b5  ..^..F...-Z..... 
  10.  0x0050:  8709 4666 7e61 6f5a 0b                   ..Ff~aoZ. 
  11. 1 packet captured 
  12. 18 packets received by filter 
  13. 0 packets dropped by kernel 
  14. bash-5.0# tcpdump -n -vvv -w /tmp/kube-flannel-ds-amd64-2xwqp.pcap 
  15. tcpdump: listening on veth19416cac, link-type EN10MB (Ethernet), capture size 262144 bytes 
  16. 50 packets captured 
  17. 50 packets received by filter 
  18. 0 packets dropped by kernel 

這里需要注意，如果是想拿到-w抓包保存的文件用wireshark工具分析，則需要去POD_NAME對應(yīng)的宿主機(jī)上拷貝出來進(jìn)行分析

  1. [root@k8s-demo-master-01-2 ~]# docker ps |grep netshoot 
  2. 58b918b67b3f        registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest       "bash"                   15 minutes ago      Up 15 minutes                           unruffled_fermat 
  3. [root@k8s-demo-master-01-2 ~]# docker cp 58b918b67b3f:/tmp/kube-flannel-ds-amd64-2xwqp.pcap . 
  4. [root@k8s-demo-master-01-2 ~]# ll |grep kube-flannel-ds-amd64-2xwqp.pcap 
  5. -rw-r--r--  1 root root 5404 12月 20 23:41 kube-flannel-ds-amd64-2xwqp.pcap 

診斷 CrashLoopBackoff

排查 CrashLoopBackoff 是一個很麻煩的問題，Pod 可能會不斷重啟， kubectl exec 和 kubectl debug 都沒法穩(wěn)定進(jìn)行排查問題，基本上只能寄希望于 Pod 的日志中打印出了有用的信息。 為了讓針對 CrashLoopBackoff 的排查更方便， kubectl-debug 參考 oc debug 命令，添加了一個 --fork 參數(shù)。當(dāng)指定 --fork 時，插件會復(fù)制當(dāng)前的 Pod Spec，做一些小修改， 再創(chuàng)建一個新 Pod：

  • 新 Pod 的所有 Labels 會被刪掉，避免 Service 將流量導(dǎo)到 fork 出的 Pod 上
  • 新 Pod 的 ReadinessProbe 和 LivnessProbe 也會被移除，避免 kubelet 殺死 Pod
  • 新 Pod 中目標(biāo)容器(待排障的容器)的啟動命令會被改寫，避免新 Pod 繼續(xù) Crash

接下來，我們就可以在新 Pod 中嘗試復(fù)現(xiàn)舊 Pod 中導(dǎo)致 Crash 的問題，示例pod_name為srv-es-driver-7445f6cf48-ff7bq的go服務(wù)。為了保證操作的一致性，可以先 chroot 到目標(biāo)容器的根文件系統(tǒng)中：

  1.  ~  kubectl-debug srv-es-driver-7445f6cf48-ff7bq -n devops --agentless --port-forward 
  2. Agent Pod info: [Name:debug-agent-pod-177482f4-61ad-11ec-b297-acbc328370f3, Namespace:default, Image:registry.cn-hangzhou.aliyuncs.com/querycapimages/kubectl-debug-agent:latest, HostPort:10027, ContainerPort:10027] 
  3. Waiting for pod debug-agent-pod-177482f4-61ad-11ec-b297-acbc328370f3 to run... 
  4. Forwarding from 127.0.0.1:10027 -> 10027 
  5. Forwarding from [::1]:10027 -> 10027 
  6. Handling connection for 10027 
  7.                              set container procfs correct false .. 
  8. pulling image registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest, skip TLS false... 
  9. latest: Pulling from querycapimages/netshoot 
  10. Digest: sha256:f0eba49c9bf66600788d58779e57c2d7334708e12cb292ff8ccc9414c1b6730c 
  11. Status: Image is up to date for registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest 
  12. starting debug container... 
  13. container created, open tty... 
  14. bash-5.0# ls 
  15. bin                        mnt                        sys 
  16. dev                        opt                        termshark_2.1.1_linux_x64 
  17. etc                        proc                       tmp 
  18. home                       root                       usr 
  19. lib                        run                        var 
  20. lib64                      sbin 
  21. media                      srv 
  22. bash-5.0# chroot /proc/1/root 
  23. root@srv-es-driver-7445f6cf48-ff7bq:/# ls 
  24. bin   dev  go  lib media  opt   root  sbin  sys  usr 
  25. boot  etc  home  lib64 mnt    proc  run   srv  tmp  var 
  26. root@srv-es-driver-7445f6cf48-ff7bq:/# cd /go/bin/ 
  27. root@srv-es-driver-7445f6cf48-ff7bq:/go/bin# ls 
  28. openapi.json  srv-es-driver 
  29. root@srv-es-driver-7445f6cf48-ff7bq:/go/bin# ./srv-es-driver 
  30.  # 觀察執(zhí)行啟動腳本時的信息并根據(jù)信息進(jìn)一步排障 

自定義image作為sidercar安裝命令行調(diào)試

對于沒有安裝yum,apt-get 的鏡像可以掛載 centos或者ubuntu的sidercar鏡像, 再進(jìn)行操作, 如安裝 redis 命令, 再使用redis-cli 命令

  1.  ~  kubectl-debug srv-es-driver-7445f6cf48-ff7bq -n devops --agentless --port-forward --image centos 
  2. Agent Pod info: [Name:debug-agent-pod-f5077b08-61ad-11ec-8728-acbc328370f3, Namespace:default, Image:registry.cn-hangzhou.aliyuncs.com/querycapimages/kubectl-debug-agent:latest, HostPort:10027, ContainerPort:10027] 
  3. Waiting for pod debug-agent-pod-f5077b08-61ad-11ec-8728-acbc328370f3 to run... 
  4. Forwarding from 127.0.0.1:10027 -> 10027 
  5. Forwarding from [::1]:10027 -> 10027 
  6. Handling connection for 10027 
  7.                              set container procfs correct false .. 
  8. pulling image centos, skip TLS false... 
  9. latest: Pulling from library/centos 
  10. a1d0c7532777: Pull complete 
  11. Digest: sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177 
  12. Status: Downloaded newer image for centos:latest 
  13. starting debug container... 
  14. container created, open tty... 
  15. [root@srv-es-driver-7445f6cf48-ff7bq /]# yum install -y redis 
  16.   

參考鏈接：

https://aleiwu.com/post/kubectl-debug-intro/

本文轉(zhuǎn)載自微信公眾號「運(yùn)維開發(fā)故事」

 

責(zé)任編輯：姜華 來源： 運(yùn)維開發(fā)故事
k8s診斷工具kubectl-debug
相關(guān)推薦

2024-02-22 08:09:44

K8S日志工具

2022-06-01 09:38:36

KubernetesPod容器

2023-07-04 07:30:03

容器Pod組件

2024-01-08 06:44:08

PodK8Skubectl

2021-07-28 10:10:57

K8SMount PVCPod

2021-06-07 08:32:06

K8S集群Poddebug

2022-11-02 10:21:41

K8s pod運(yùn)維

2022-04-22 13:32:01

K8s容器引擎架構(gòu)

2023-11-06 07:16:22

WasmK8s模塊

2024-03-18 15:44:48

K8S故障運(yùn)維

2022-02-23 08:01:04

KubernetesK8sPod

2021-09-24 14:20:25

開發(fā)技能工具

2021-02-03 14:04:52

k8spermissionm管理工具

2023-02-08 07:55:33

K8sHPA服務(wù)器

2020-07-17 08:40:47

K8SServicePOD

2023-09-06 08:12:04

k8s云原生

2025-04-07 08:00:00

KubernetesK8Spod

2023-12-01 15:58:00

Kubernetes集群DevOps

2024-07-15 18:20:18

2024-01-26 14:35:03

鑒權(quán)K8sNode
點(diǎn)贊
收藏

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