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

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

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

[[441330]]

背景

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

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

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

工作原理

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

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

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

這就是 kubectl-debug 的出發點： 用工具容器來診斷業務容器 。背后的設計思路和 sidecar 等模式是一致的：每個容器只做一件事情。

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

步驟分別是:

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

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

安裝

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

Mac 可以直接使用 brew 安裝

  1. brew install aylei/tap/kubectl-debug 

通過下載二進制文件安裝

  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 頁面選擇進行下載windows版本，加入環境變量使用

其中github上有提供debug agent以DaemonSet的方式安裝在集群中，但是daemonset模式，agent pod預先部署在所有node上，會始終占用資源，對于排錯調試頻率不高的環境造成資源浪費

日常用法說明

簡單使用

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

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

kubectl 從 1.12 版本之后開始支持從 PATH 中自動發現插件。1.12 版本之前的 kubectl 不支持這種插件機制，但也可以通過命令名 kubectl-debug 直接調用。

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

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

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

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

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

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

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

進階使用

1、排錯init-container

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

2、假如 Pod 處于 CrashLookBackoff 狀態無法連接, 可以復制一個完全相同的 Pod 來進行診斷

  1. kubectl debug POD_NAME --fork 

自定義鏡像配置

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

配置文件

~/.kube/debug-config，通過配置文件修改默認參數，免去使用命令時設置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的網絡流量

比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的網絡流量：

  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的網絡流量：

  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的網絡流量：

  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對應的宿主機上拷貝出來進行分析

  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 都沒法穩定進行排查問題，基本上只能寄希望于 Pod 的日志中打印出了有用的信息。 為了讓針對 CrashLoopBackoff 的排查更方便， kubectl-debug 參考 oc debug 命令，添加了一個 --fork 參數。當指定 --fork 時，插件會復制當前的 Pod Spec，做一些小修改， 再創建一個新 Pod：

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

接下來，我們就可以在新 Pod 中嘗試復現舊 Pod 中導致 Crash 的問題，示例pod_name為srv-es-driver-7445f6cf48-ff7bq的go服務。為了保證操作的一致性，可以先 chroot 到目標容器的根文件系統中：

  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.  # 觀察執行啟動腳本時的信息并根據信息進一步排障 

自定義image作為sidercar安裝命令行調試

對于沒有安裝yum,apt-get 的鏡像可以掛載 centos或者ubuntu的sidercar鏡像, 再進行操作, 如安裝 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/

本文轉載自微信公眾號「運維開發故事」

 

責任編輯：姜華 來源： 運維開發故事
k8s診斷工具kubectl-debug
相關推薦

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運維

2024-03-18 15:44:48

K8S故障運維

2021-09-24 14:20:25

開發技能工具

2022-04-22 13:32:01

K8s容器引擎架構

2023-11-06 07:16:22

WasmK8s模塊

2022-02-23 08:01:04

KubernetesK8sPod

2021-02-03 14:04:52

k8spermissionm管理工具

2023-09-06 08:12:04

k8s云原生

2019-08-12 08:36:33

K8S網絡Pod

2025-04-07 08:00:00

KubernetesK8Spod

2020-07-17 08:40:47

K8SServicePOD

2023-02-08 07:55:33

K8sHPA服務器

2023-09-15 07:34:15

AIOps云原生項目

2024-07-15 18:20:18

點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 99久久日韩精品免费热麻豆美女 | 成人精品一区 | 久久免费视频在线 | 亚洲国产精品一区在线观看 | 久久精品一区二区三区四区 | 精品国产伦一区二区三区观看方式 | 一区二区三区在线 | 韩国电影久久 | 激情三区 | 激情影院久久 | 在线视频a | 91看片免费 | 亚洲 91| 亚洲美女视频 | a国产视频 | 日韩免费一区二区 | 国产高清精品一区二区三区 | 91九色porny首页最多播放 | 美女视频一区二区 | 国产亚洲精品久久午夜玫瑰园 | 国产一区二 | 亚洲欧美一区二区在线观看 | 91成人免费看片 | 精品无码久久久久国产 | 国产乱码精品1区2区3区 | 亚洲精品一区久久久久久 | 国产高清精品一区二区三区 | 免费观看成人av | 日韩精品在线视频 | jav成人av免费播放 | 国产欧美精品 | www.天天操| 久久久人成影片免费观看 | 欧美日韩在线观看视频 | 中文字幕欧美一区二区 | 综合国产 | 免费中文字幕日韩欧美 | 91高清视频在线观看 | 久久免费观看一级毛片 | 不卡在线视频 | 日韩欧美中文 |