Podman이 systemd로 시작될 때 conmon이 다른 cgroup에 있는 이유는 무엇입니까?

Question 1

이에 대한 전체 아이디어는 중앙 집중식 데몬이 단일 실패 지점인 podman매우 강력한 감독자(예: )가 있는 중앙 집중식 아키텍처에서 벗어나는 것입니다 . dockerd이에 대한 태그도 있습니다. - "#nobigfatdaemons".

컨테이너의 중앙 집중식 관리를 피하는 방법은 무엇입니까? 단일 기본 데몬(다시 말하지만 dockerd)을 제거하고 컨테이너를 독립적으로 시작합니다(결국 컨테이너는 프로세스일 뿐이므로 컨테이너를 생성하는 데 데몬이 필요하지 않습니다).

그러나 여전히 방법이 필요합니다.

컨테이너에서 로그를 수집합니다. 누군가가 stdout컨테이너를 보관해야 합니다 stderr.
컨테이너의 종료 코드 수집 - 누군가 wait(2)컨테이너의 PID 1을 수집해야 합니다.

이를 위해 각 Podman 컨테이너는 conmon("컨테이너 모니터"에서) 호출되는 작은 데몬에 의해 계속해서 감독됩니다. Docker 데몬과의 차이점은 이 데몬이 가능한 한 작다는 것입니다(확인소스 코드 크기)이며 컨테이너별로 생성됩니다. 컨테이너 하나가 충돌 하더라도 conmon시스템의 나머지 부분은 영향을 받지 않습니다.

다음으로 컨테이너는 어떻게 생성되나요?

사용자가 Docker처럼 백그라운드에서 컨테이너를 실행하기를 원할 수 있다는 점을 고려하면 프로세스가 podman run분기됩니다.두 배그런 다음 다음을 실행하십시오 conmon.

$ strace -fe trace=fork,vfork,clone,execve -qq podman run alpine
execve("/usr/bin/podman", ["podman", "run", "alpine"], 0x7ffeceb01518 /* 30 vars */) = 0
...
[pid  8480] clone(child_stack=0x7fac6bffeef0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tid=[8484], tls=0x7fac6bfff700, child_tidptr=0x7fac6bfff9d0) = 8484
...
[pid  8484] clone(child_stack=NULL, flags=CLONE_VM|CLONE_VFORK|SIGCHLD <unfinished ...>
[pid  8491] execve("/usr/bin/conmon", ... <unfinished ...>
[pid  8484] <... clone resumed>)        = 8491

podman run사이에 있는 중간 프로세스 conmon(즉, 직접 상위 프로세스 conmon- 위의 예에서는 PID 8484)가 종료되고 conmon상위가 다시 지정되어 init자체 관리 데몬이 됩니다. 그런 다음 conmon런타임도 포크되고(예 runc: ) 마지막으로 런타임은 컨테이너의 진입점(예: /bin/sh)을 실행합니다.

컨테이너가 실행되는 동안에는 podman run더 이상 필요하지 않아 종료될 수 있지만 귀하의 경우에는 컨테이너에서 분리를 요청하지 않았기 때문에 온라인 상태로 유지됩니다.

다음으로 podmancgroup을 사용하여 컨테이너를 제한합니다. 이것은 그것을 의미한다새 컨테이너에 대한 새 cgroup을 생성하고 프로세스를 여기로 이동합니다.. cgroup의 규칙에 따르면 프로세스는 한 번에 하나의 cgroup에만 속할 수 있으며, cgroup에 프로세스를 추가하면 동일한 계층(이전에 위치했던)의 다른 cgroup에서 해당 프로세스가 제거됩니다. 따라서 컨테이너가 시작되면 cgroup의 최종 레이아웃은 다음과 같습니다. podman run생성된 cgroup에 남아 있고 프로세스는 자체 cgroup에 배치되며 컨테이너화된 프로세스는 자체 cgroup에 배치됩니다.baz.servicesystemdconmon

$ ps axf
<...>
 1660 ?        Ssl    0:01 /usr/bin/podman run --rm --tty --name baz alpine sh -c while true; do date; sleep 1; done
 1741 ?        Ssl    0:00 /usr/bin/conmon -s -c 2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6 <...>
 1753 pts/0    Ss+    0:02  \_ sh -c while true; do date; sleep 1; done
13043 pts/0    S+     0:00      \_ sleep 1
<...>

$ cd /sys/fs/cgroup/memory/machine.slice
$ ls -d1 libpod*
libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope
libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope

$ cat libpod-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1753
13075

$ cat libpod-conmon-2f56e37a0c5ca6f4282cc4c0f4c8e5c899e697303f15c5dc38b2f31d56967ed6.scope/cgroup.procs 
1741

참고: 위의 PID 13075는 실제로 sleep 1PID 13043이 죽은 후에 생성된 프로세스입니다.

도움이 되었기를 바랍니다.

Answer