kubernetes pod内抓包,telnet检查网络链接的几种方式

背景

在平常kubernetes的运维中,常常遇到pod的网络问题,如pod间网络不通,或者端口不通,更复杂的,须要在容器里面抓包分析才能定位。而kubertnets的场景,pod使用的镜像通常都是尽可能精简,不少都是基于alpine基础镜像制做的,于是pod内没有ping,telnet,nc,curl命令,更别说tcpdump这种复杂的工具了。除了在容器或者镜像内直接安装这些工具这种最原始的法子,咱们探讨下其余法子。linux

实现

kubectl debug插件方式

项目地址 kubect debughttps://github.com/aylei/kubectl-debugios

kubectl-debug 是一个简单的 kubectl 插件,可以帮助你便捷地进行 Kubernetes 上的 Pod 排障诊断。背后作的事情很简单: 在运行中的 Pod 上额外起一个新容器,并将新容器加入到目标容器的 pid, network, user 以及 ipc namespace 中,这时咱们就能够在新容器中直接用 netstat, tcpdump 这些熟悉的工具来解决问题了, 而旧容器能够保持最小化,不须要预装任何额外的排障工具。操做流程能够参见官方项目地址文档。git

一条 kubectl debug命令背后是这样的github

image-20200605194618522

步骤分别是:docker

  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 完成。bash

直接进入容器net ns方式

有2种进入pod 所在net ns的方式,前提都是须要登陆到pod所在宿主机,且须要找出pod对应的容器ID或者名字。网络

ip netns方式

  • 获取pod对应容器的ID或者name运维

    pid="$(docker inspect -f '{{.State.Pid}}' <container_name | uuid>)" #替换为环境实际的容器名字或者uuid
  • 建立容器对应netnsssh

    ip netns会到/var/run/netns目录下寻找network namespace,把容器进程中netns链接到这个目录中后,ip netns才会感知到curl

    $ sudo mkdir -p /var/run/netns
    
    #docker默认不会建立这个连接,须要手动建立,这时候执行ip netns,就应当看到连接过来的network namespace
    $ sudo ln -sf /proc/$pid/ns/net "/var/run/netns/<container_name|uuid>"
  • 执行ip netns <<container_name|uuid > bash,进入容器ns

    ip netns exec <container_name|uuid>  bash
  • 执行telnet,tcpdump等命令,此时执行ip a或者ifconfig,只能看到容器自己的IP

image-20200605211648653

image-20200605212230963

以下图,执行ifconfig,只看到容器自己的IP,此时执行telnet,tcpdump等于直接在容器内操做

image-20200605212401419

nsenter方式

nsenter为util-linux里面的一个工具,除了进入容器net ns,还支持其余不少操做,能够查看官方文档。

pid="$(docker inspect -f '{{.State.Pid}}' <container_name | uuid>)"
nsenter -t $pid -n /bin/bash
tcpdump -i eth0 -nn  #此时利用宿主机的tcpdump执行抓包操做,等于在容器内抓包

image-20200605214331582

总结

  1. kubectl debug方式功能更强大,缺点是须要附加镜像,要在目标pod建立debug agent的容器,比较笨重,可是优势是能使用的工具更多,不须要ssh到pod所在节点,除了netstat,tcpdump工具,还能使用htop,iostat等其余高级工具,不只能对网络进行debug,还能对IO等其余场景进行诊断,适用更复杂的debug场景。
  2. 直接进入容器net ns方式相对比较轻量,复用pod所在宿主机工具,但鱼和熊掌不可兼得,缺点是只能进行网络方面的debug,且须要ssh登陆到pod所在节点操做。
相关文章
相关标签/搜索