
ss
컨테이너의 일부 TCP 네트워크 문제를 조사하는 동안 컨테이너 네트워크 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
각 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 포드 네트워크 네임스페이스를 조사할 수 있는 방법이 있습니까?
# 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
경우 네트워크 네임스페이스에 대한 가정은 다음과 같습니다. "안녕하세요 모든 네트워크 ns는 디렉토리에서 찾아야 합니다 . 왜냐하면 그렇지 않은 이유는 무엇이며 이것이 생명을 불어넣을 것이기 때문입니다. 개발자는 쉽든 뭐든.ss
iproute
ip
/var/run/netns
iproute
이는 현대 컨테이너 도구 및 상호 운용성에 대한 "합의"가 부족하거나 측면 ss
에서 잘못된 가정으로 밝혀졌지만 이는 다음의 빈 출력을 일종의 설명합니다.iproute
iproute
ip netns list
따라서 네트워크 네임스페이스를 생성하는 방식 ip
(에서 검사할 수 있도록 ss
)은 분명히 쿠버네티스 등이 이를 생성하는 방식과 일치하지 않으므로 iproute
전체적인 계획에서 패키지 유틸리티를 쓸모 없게 만듭니다.
답변1
보다 일반적인 방법은 다음을 사용하는 것입니다.nsenter(1)
.
nsenter -t ${PID_FOO} -muni ss -tpi
Go to 접근 방식은 임시 작업을 실행해야 할 때 다음과 같은 것을 사용하는 것입니다.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로 변환합니다.
예를 들어 net 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#