CLOSE_WAIT는 Kubernetes 노드에 표시되지 않습니다.

CLOSE_WAIT는 Kubernetes 노드에 표시되지 않습니다.

오류를 디버깅하는 동안 (컨테이너의) 한 프로세스가 tcp: out of memory상태에 대해 많은 연결을 가지고 있음을 발견했습니다.CLOSE_WAIT08/proc/XXX/net/tcp

그러나 netstat이나 ss 모두 이러한 유출된 연결을 표시하지 않습니다.

133: 0E03540A: 9D9C 804CC2AD: 01BB 08 00000000: 00059D7A 00: 00000000 00000000 0 0 316215 1 ffff8f677201df00 20 4 0 10 -1
134: 0A:83 16 80A7E940:01BB 08 00000000:00000000 00:00000000 00000000 0 0 255647 1 ffff8f67c9592600 20 4 1 10 -1
135: 0E03540A: 8874 808C7D4A: 01BB 08 00000000: 00037EED 00: 00000000 00000000 0 0 331603 1 ffff8f68e37a7200 20 4 1 0 -1 13 6
: 0E03540A:E226 804CC2AD:01BB 08 00000000:0005E30B 00:00000000 00000000 0 0 215782 1 ffff8f67bd1edf00 20 4 0 10 -1
137: 0E03540A: DAEC 804CC2AD: 01BB 08 00000000: 0005B41A 00: 00000000 00000000 0 0 216048 1 ffff8f6 7daf9af8 0 20 4 0 10 -1 138: 0E03540A
: 9AEA 8005FB8E: 01BB 08 00000000: 000D6360 00 :00000000 00000000 0 0 243082 1 ffff8f67db637200 20 4 30 10 -1
140: 0E03540A:BAE4 800FB16C:01BB 08 00000000:000D8432 00:00000000 00000000 0 0 245062 1 ffff8f67640f8980 20 4 1 10 -1
141: 0E03540A: 9754 804CC2AD: 01BB 08 00000000: 00003186 00:00000000 00000000 0 0 298890 1 ffff8f676e1a5f00 20 4 1 10 -1
142: 0E03540A:C6FC 800FB16C:01BB 08 0 0000000: 000658C9 0 0:00000000 00000000 0 0 299343 1 ffff8f68dcef5580 20 4 0 10 -1
143: 0E03540A: CB24 804CC2AD: 01BB 08 00000000:0005BBB4 00:00000000 00000000 0 0 316285 1 ffff8f6772019300 20 4 1 10 -1
144:0E03540A:82 04 80A7E940 :01BB 08 00 000000:0005DD3A 00:00000000 00000000 0 0 217390 1 ffff8f67dbc20000 20 4 0 10 - 1
145: 0E03540A: 8BC8 80016642: 01BB 08 00000000: 00059847 00: 00000000 00000000 0 0 275095 1 ffff8f67b6d7a600 20 4 1 10 -1
146: 0E 03540A: C612 800 5FB8E:01BB 08 00000000:0003EC48 00:00000000 00000000 0 0 252281 1 ffff8f67cf014280 20 4 1 10 - 1

netstat가 이러한 연결을 표시하지 않는 이유는 무엇이며 각 프로세스의 세부 사항을 파헤치지 않고 어떻게 이를 얻을 수 있습니까?

답변1

호스트에서 이를 보면 컨테이너의 네트워크 네임스페이스가 아닌 초기 네트워크 네임스페이스에 있는 것입니다. 이러한 연결이나 상태는 초기 네트워크 네임스페이스의 네트워크 스택에서 처리되지 않기 때문에 볼 수 없습니다. 프로세스 디렉터리의 항목을 추적할 때 /proc해당 항목이 프로세스의 관점에서 표시되는 경우가 있습니다... 때로는 관련 네임스페이스 정보가 표시되기도 하지만 도구에서는 이 정보를 사용하도록 의도되지 않았습니다.

따라서 먼저 조사 중인 프로세스의 네트워크 네임스페이스로 전환해야 합니다.

그것은 매우 간단합니다 (사용뿌리사용자):

nsenter -t XXX --net -- ss -tn

또는 프로세스를 찾으십시오(컨테이너가 아닌 초기 pid 네임스페이스에 표시된 대로).

nsenter -t XXX --net -- ss -tnp state CLOSE-WAIT

일반적으로 사람들은 프로세스보다는 Pod(또는 다른 기술의 컨테이너)를 기준으로 검색합니다. 다양한 컨테이너 기술을 사용하면 컨테이너 프로세스 이름(예: LXC lxc-info -Hp -n containername또는 Docker docker inspect --format '{{.State.Pid}}' containername)에서 PID를 검색할 수 있지만 백엔드가 Docker가 아닌 경우 Kubernetes가 이 정보를 제공할 수 있는지 여부와 방법을 모르겠습니다.

또한 일부 도구의 경우 이보다 조금 더 어렵습니다. 예를 들어 새 네트워크 네임스페이스를 반영 /sys하기 위해 인터페이스 보기를 다시 설치해야 하기 /sys/class/net때문입니다. 이제 변경해야 할 두 개의 네임스페이스가 있습니다: 대상 프로세스의 네임스페이스와 임시 설치 네임스페이스 (초기 코드를 깨지 않도록 하거나 필수 명령이 없을 수 있는 대상을 사용하지 않기 위해). 어쨌든 ss명령은 순전히 소켓에서만 실행되며 이것이 필요하지 않습니다.

예를 들어, 사용되지 않는 brctl show명령이 제대로 작동하려면 다음 명령이 필요합니다.

nsenter -t XXX --net -- unshare --mount -- sh -c 'mount -t sysfs sysfs /sys; brctl show'

관련 정보