背景
容器技术的一个最佳实践是构建尽可能精简的容器镜像。但这一实践却会给排查问题带来麻烦:精简后的容器中普遍缺失常用的排障工具,部分容器里甚至没有 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 就可以实现这个操作:
export TARGET_ID=666666666
# 加入目标容器的 network, pid 以及 ipc namespace
docker run -it --network=container:$TARGET_ID --pid=container:$TARGET_ID --ipc=container:$TARGET_ID busybox
这就是 kubectl-debug 的出发点: 用工具容器来诊断业务容器 。背后的设计思路和 sidecar 等模式是一致的:每个容器只做一件事情。
具体到实现上,一条 kubectl debug
步骤分别是:
-
插件查询 ApiServer:demo-pod 是否存在,所在节点是什么
-
ApiServer 返回 demo-pod 所在所在节点
-
插件请求在目标节点上创建 Debug Agent Pod
-
Kubelet 创建 Debug Agent Pod
-
插件发现 Debug Agent 已经 Ready,发起 debug 请求(长连接)
-
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 安装
brew install aylei/tap/kubectl-debug
- 通过下载二进制文件安装
export PLUGIN_VERSION=0.1.1
# linux x86_64
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
# macos
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
tar -zxvf kubectl-debug.tar.gz kubectl-debug
sudo mv kubectl-debug /usr/local/bin/
Windows 用户可以在Release 页面选择进行下载windows版本,加入环境变量使用
其中github上有提供debug agent以DaemonSet的方式安装在集群中,但是daemonset模式,agent pod预先部署在所有node上,会始终占用资源,对于排错调试频率不高的环境造成资源浪费
日常用法说明
简单使用(K8s v1.15.0)
1、kubectl 1.12.0 或更高的版本, 可以直接使用:
#查看常用命令参数
kubectl debug -h
kubectl 从 1.12 版本之后开始支持从 PATH 中自动发现插件。1.12 版本之前的 kubectl 不支持这种插件机制,但也可以通过命令名 kubectl-debug 直接调用。
2、假如安装了 debug-agent 的 daemonset, 可以略去 --agentless 来加快启动速度,之后的命令里会略去 --agentless
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模式:
kubectl debug POD_NAME --agentless --port-forward
4、假如 Node 没有公网 IP 或无法直接访问(防火墙等原因), 请使用 port-forward 模式
kubectl debug POD_NAME --agentless --port-forward
进阶使用
1、排错init-container
kubectl debug POD_NAME --container=init-pod
2、假如 Pod 处于 CrashLookBackoff 状态无法连接, 可以复制一个完全相同的 Pod 来进行诊断
kubectl debug POD_NAME --fork
离线配置
--image:可自定义排错工具容器镜像,改为私有镜像仓库,默认为nicolaka/netshoot:latest
--agent-image:在agentless模式下,自定义debug-agent镜像,默认为aylei/debug-agent:latest。在daemon-set模式下,直接将debug-agent daemonset pod template修改为私有仓库镜像即可
配置文件
~/.kube/debug-config,通过配置文件修改默认参数,免去使用命令时设置flag。
# debug agent listening port(outside container)
default to 10027
agentPort: 10027
whether using agentless mode
default to false
agentless: true
namespace of debug-agent pod, used in agentless mode
default to 'default'
agentPodNamespace: default
prefix of debug-agent pod, used in agentless mode
default to 'debug-agent-pod'
agentPodNamePrefix: debug-agent-pod
image of debug-agent pod, used in agentless mode
default to 'aylei/debug-agent:latest'
agentImage: aylei/debug-agent:latest
daemonset name of the debug-agent, used in port-forward
default to 'debug-agent'
debugAgentDaemonset: debug-agent
daemonset namespace of the debug-agent, used in port-forwad
default to 'default'
debugAgentNamespace: kube-system
whether using port-forward when connecting debug-agent
default false
portForward: true
image of the debug container
default as showed
image: nicolaka/netshoot:latest
start command of the debug container
default ['bash']
command:
- '/bin/bash'
- '-l'
典型案例
使用 iftop查看pod的网络流量
比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的网络流量:
~ kubectl debug kube-flannel-ds-amd64-2xwqp -n kube-system
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]
Waiting for pod debug-agent-pod-b14bd868-61a9-11ec-bc72-acbc328370f3 to run...
Forwarding from 127.0.0.1:10027 -> 10027
Forwarding from [::1]:10027 -> 10027
Handling connection for 10027
set container procfs correct false ..
pulling image registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest, skip TLS false...
latest: Pulling from querycapimages/netshoot
Digest: sha256:f0eba49c9bf66600788d58779e57c2d7334708e12cb292ff8ccc9414c1b6730c
Status: Image is up to date for registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest
starting debug container...
container created, open tty...
bash-5.0# iftop -i eth0
interface: eth0
IP address is: 172.17.3.3
MAC address is: 52:54:be:83:3a:e4
使用 drill 诊断 DNS 解析
比如查看POD_NAME是kube-flannel-ds-amd64-2xwqp的网络流量:
bash-5.0# drill any www.baidu.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 3214
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 3
;; QUESTION SECTION:
;; www.baidu.com. IN ANY
;; ANSWER SECTION:
www.baidu.com. 803 IN CNAME www.a.shifen.com.
;; AUTHORITY SECTION:
baidu.com. 38993 IN NS ns4.baidu.com.
baidu.com. 38993 IN NS ns3.baidu.com.
baidu.com. 38993 IN NS ns7.baidu.com.
baidu.com. 38993 IN NS dns.baidu.com.
baidu.com. 38993 IN NS ns2.baidu.com.
;; ADDITIONAL SECTION:
ns2.baidu.com. 19348 IN A 220.181.33.31
ns3.baidu.com. 23022 IN A 112.80.248.64
ns7.baidu.com. 20697 IN A 180.76.76.92
;; Query time: 1 msec
;; SERVER: 100.64.9.5
;; WHEN: Mon Dec 20 15:37:35 2021
;; 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的网络流量:
bash-5.0# tcpdump -i eth0 -c 1 -Xvv
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:39:27.577342 IP (tos 0x0, ttl 63, id 41476, offset 0, flags [DF], proto TCP (6), length 89)
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
0x0000: 4500 0059 a204 4000 3f06 b036 c613 743c E..Y..@.?..6..t<
0x0010: ac11 0303 4146 192b 2862 2993 52c6 0aae ....AF.+(b).R...
0x0020: 8018 040d f831 0000 0101 080a a9d8 75b6 .....1........u.
0x0030: 72b1 e0f9 1703 0300 2047 49f1 8fbb 2835 r........GI...(5
0x0040: 059a 5e82 0746 afaf bd2d 5af3 c797 16b5 ..^..F...-Z.....
0x0050: 8709 4666 7e61 6f5a 0b ..Ff~aoZ.
1 packet captured
18 packets received by filter
0 packets dropped by kernel
bash-5.0# tcpdump -n -vvv -w /tmp/kube-flannel-ds-amd64-2xwqp.pcap
tcpdump: listening on veth19416cac, link-type EN10MB (Ethernet), capture size 262144 bytes
50 packets captured
50 packets received by filter
0 packets dropped by kernel
这里需要注意,如果是想拿到-w抓包保存的文件用wireshark工具分析,则需要去POD_NAME对应的宿主机上拷贝出来进行分析
[root@k8s-demo-master-01-2 ~]# docker ps |grep netshoot
58b918b67b3f registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest "bash" 15 minutes ago Up 15 minutes unruffled_fermat
[root@k8s-demo-master-01-2 ~]# docker cp 58b918b67b3f:/tmp/kube-flannel-ds-amd64-2xwqp.pcap .
[root@k8s-demo-master-01-2 ~]# ll |grep kube-flannel-ds-amd64-2xwqp.pcap
-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 到目标容器的根文件系统中:
~ kubectl-debug srv-es-driver-7445f6cf48-ff7bq -n devops --agentless --port-forward
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]
Waiting for pod debug-agent-pod-177482f4-61ad-11ec-b297-acbc328370f3 to run...
Forwarding from 127.0.0.1:10027 -> 10027
Forwarding from [::1]:10027 -> 10027
Handling connection for 10027
set container procfs correct false ..
pulling image registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest, skip TLS false...
latest: Pulling from querycapimages/netshoot
Digest: sha256:f0eba49c9bf66600788d58779e57c2d7334708e12cb292ff8ccc9414c1b6730c
Status: Image is up to date for registry.cn-hangzhou.aliyuncs.com/querycapimages/netshoot:latest
starting debug container...
container created, open tty...
bash-5.0# ls
bin mnt sys
dev opt termshark_2.1.1_linux_x64
etc proc tmp
home root usr
lib run var
lib64 sbin
media srv
bash-5.0# chroot /proc/1/root
root@srv-es-driver-7445f6cf48-ff7bq:/# ls
bin dev go lib media opt root sbin sys usr
boot etc home lib64 mnt proc run srv tmp var
root@srv-es-driver-7445f6cf48-ff7bq:/# cd /go/bin/
root@srv-es-driver-7445f6cf48-ff7bq:/go/bin# ls
openapi.json srv-es-driver
root@srv-es-driver-7445f6cf48-ff7bq:/go/bin# ./srv-es-driver
# 观察执行启动脚本时的信息并根据信息进一步排障
自定义image作为sidercar安装命令行调试
对于没有安装yum,apt-get 的镜像可以挂载 centos或者ubuntu的sidercar镜像, 再进行操作, 如安装 redis 命令, 再使用redis-cli 命令
~ kubectl-debug srv-es-driver-7445f6cf48-ff7bq -n devops --agentless --port-forward --image centos
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]
Waiting for pod debug-agent-pod-f5077b08-61ad-11ec-8728-acbc328370f3 to run...
Forwarding from 127.0.0.1:10027 -> 10027
Forwarding from [::1]:10027 -> 10027
Handling connection for 10027
set container procfs correct false ..
pulling image centos, skip TLS false...
latest: Pulling from library/centos
a1d0c7532777: Pull complete
Digest: sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177
Status: Downloaded newer image for centos:latest
starting debug container...
container created, open tty...
[root@srv-es-driver-7445f6cf48-ff7bq /]# yum install -y redis
参考链接:
https://aleiwu.com/post/kubectl-debug-intro/