在调查容器中的一些 TCP 网络问题时,我尝试使用它ss
来窥视容器网络 TCP 堆栈。
我们在 AWS 中运行 Amazon Linux:
# uname -a
Linux 4.14.173-137.229.amzn2.x86_64 #1 SMP Wed Apr 1 18:06:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
ss
有以下 CLI 开关:
-N NSNAME, --net=NSNAME
Switch to the specified network namespace name.
lsns
给出以下输出:
# lsns | grep net
4026531993 net 225 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 21
4026532284 net 2 26244 root /pause
这是pause
为每个 pod 创建的容器Kubernetes
——它是创建网络命名空间的容器。
尝试通过运行以下命令来窥视 pod 网络命名空间ss
:
# ss -tp -N 4026532284
Cannot open network namespace "4026532284": No such file or directory
有趣的是 ip netns list
没有返回任何网络命名空间:
# ip netns list
#
有没有什么方法可以从根网络命名空间(即 netns 1)查看 K8s pod 网络命名空间?
# ss --version
ss utility, iproute2-ss180129
# lsns --version
lsns from util-linux 2.30.2
# rpm -qi iproute
Name : iproute
Version : 4.15.0
Release : 1.amzn2.0.4
Architecture: x86_64
Install Date: Sat 07 Mar 2020 03:42:24 AM UTC
Group : Applications/System
Size : 1321292
License : GPLv2+ and Public Domain
Signature : RSA/SHA256, Fri 21 Feb 2020 09:00:29 PM UTC, Key ID 11cf1f95c87f5b1a
Source RPM : iproute-4.15.0-1.amzn2.0.4.src.rpm
Build Date : Fri 21 Feb 2020 07:56:50 PM UTC
Build Host : build.amazon.com
Relocations : (not relocatable)
Packager : Amazon Linux
Vendor : Amazon Linux
URL : http://kernel.org/pub/linux/utils/net/iproute2/
Summary : Advanced IP routing and network device configuration tools
更新时间:2020 年 12 月 1 日星期二 11:35:39 UTC
经过一番挣扎之后,我最终决定strace
这么做。
事实证明ss
它是一个很棒的工具,但是当与容器一起使用时,它就有点不尽如人意了,但我觉得其中涉及的“罪魁祸首”不止一个。
ss
不去查找创建网络命名空间的进程的实际 PID,而是直接去检查/var/run/netns
:
openat(AT_FDCWD, "/var/run/netns/4026532284", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
write(2, "Cannot open network namespace \"4"..., 70Cannot open network namespace "4026532284": No such file or directory
) = 70
现在,我怀疑这是由于iproute
包的创建方式network namespaces
,即考虑到包ss
附带的内容,对网络命名空间的iproute
假设ip
是:“嘿,所有网络 ns 都应该在目录中找到/var/run/netns
,因为,为什么不呢,而且这将使iproute
开发人员的生活更轻松,或者其他什么。
ss
事实证明,这是iproute
对现代容器工具和互操作性缺乏“共识”的错误假设iproute
,但它在某种程度上解释了
ip netns list
因此,创建网络命名空间的方式ip
(以便可以通过 检查ss
)显然与 kubernetes 等创建它们的方式不匹配,从而使得iproute
软件包实用程序在总体上几乎毫无用处。
答案1
更通用的方法是使用nsenter(1)
。
nsenter -t ${PID_FOO} -muni ss -tpi
当需要运行临时的东西时,可以使用以下方法,而这些东西不一定支持unshare(2)
/setns(2)
内置。
docker run -it --rm --security-opt=seccomp:unconfined \
--security-opt=apparmor:unconfined \
--privileged --pid=host --userns=host \
debian:jessie@sha256:51cd80bb935b76fbbf49640750736abc63ab7084d5331e198326b20063e7f13c \
nsenter -t ${PID_FOO} -m -u -n -i -F ss -tpi
答案2
如果你想使用ss
它来查看特定的容器命名空间,你可以这样做:
找出容器进程的PID
ps aux
或者ps -ef
应该给你答案创建以下符号链接
ln -s /proc/PID/ns/net /var/run/netns/mycontainer
- 利润
ss -tpi -N mycontainer
答案3
如果你有最新版本的lsns,您可以使用选项-n -o NSFS将命名空间 inode 转换为网络子系统使用的 ID。
例如,假设您的网络 NS 为 4026536974。您可以运行:
sh-4.4# lsns --version
lsns from util-linux 2.32.1
sh-4.4# lsns -n -o NSFS 4026536974 | sort -u
/run/netns/d0912eba-0fae-425c-94ba-cf270aa23c93
sh-4.4# basename /run/netns/d0912eba-0fae-425c-94ba-cf270aa23c93
d0912eba-0fae-425c-94ba-cf270aa23c93
sh-4.4# ss -nltp -N d0912eba-0fae-425c-94ba-cf270aa23c93 | head -2
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:5000 0.0.0.0:* users:(("nginx",pid=874035,fd=5),("nginx",pid=874028,fd=5))
sh-4.4#
或者全部合为一体:
sh-4.4# lsns -n -o NSFS 4026536974 | sort -u | xargs -rn1 basename | xargs -rn1 ss -nltp -N | head -2
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:5000 0.0.0.0:* users:(("nginx",pid=874035,fd=5),("nginx",pid=874028,fd=5))
sh-4.4#