Pause 컨테이너에 대한 나의 오해

Pause 컨테이너

이미 너무 잘 알려진대로 Pause 컨테이너는 파드가 생성될 때 가장 먼저 실행되어 기본 환경을 구성한다.

그 외 네트워크 할당 격리등 다양한 동작을 하는데 오늘 다룰 내용은 위에서 잘 알려진 내용들이 아닌 프로세스 회수 절차에 대한 내용이다.

---

공식 사이트

광고 클릭은 큰 힘이 됩니다!

(공식 사이트에서 발췌한 내용을 기반으로 작성하였으나,명확하지 않은 부분은 경험을 토대로 작성하였습니다.
이는 정확한 정보가 아닐 수 있음을 알려드립니다.)

 

공식 문서는 아니지만 Pause에 대한 아주 좋은 글입니다.

The Almighty Pause Container

 

Share Process Namespace between Containers in a Pod

공식 문서 발췌

Understanding process namespace sharing

Pods share many resources so it makes sense they would also share a process namespace. Some containers may expect to be isolated from others, though, so it's important to understand the differences:

1. The container process no longer has PID 1. Some containers refuse to start without PID 1 (for example, containers using systemd) or run commands like kill -HUP 1 to signal the container process. In pods with a shared process namespace, kill -HUP 1 will signal the pod sandbox (/pause in the above example).
2. Processes are visible to other containers in the pod. This includes all information visible in /proc, such as passwords that were passed as arguments or environment variables. These are protected only by regular Unix permissions.
3. Container filesystems are visible to other containers in the pod through the /proc/$pid/root link. This makes debugging easier, but it also means that filesystem secrets are protected only by filesystem permissions.

 

728x90

---

Pause 컨테이너의 프로세스 회수 능력

Pause 컨테이너가 부모 프로세스로 동작하면서 파드 내부의 프로세스에 대한 회수 절차를 진행한다고 생각했다. (아예 틀린말은 아니다)

그런데 문득 그럼 내부에서 프로세스를 처리하는 형식으로 어플리케이션을 만든다면 그럴땐 어떻게 동작하지? 라는 의문이 들었다.

 

아래는 Pause 컨테이너의 기본적인 상태이다.

격리 상태 (shareProcessNamespace: false): Pause와 앱 컨테이너는 PID 네임스페이스가 분리되어 있다.
서로의 프로세스를 볼 수 없으므로 Pause는 앱 내부의 좀비 프로세스에 관여할 수 없다.

 

그렇다, 기본적으로 Pause 컨테이너는 앱 내부의 프로세스 회수에 대한 의무가 없다.

이때까지 별 생각 없이 베이스 이미지를 가져다 쓴 입장에서 고려하지 못 한 부분이다.

 

그럼 왜 기본적인 상태가 격리 shareProcessNamespace: false 일까? 서두에서 말 한것 처럼 어플리케이션 내에서 프로세스를 처리하는 로직이 있다면 시그널이 꼬일수 있기 때문이라고 한다.

 

혹여 운영중인 클러스터의 특정 파드내에서 좀비 프로세스가 다량으로 발생한다면, 위와 같은 내용일 가능성이 있다.

 

앱 컨테이너가 스스로 자식 프로세스를 정리하지 못할 때 두가 해결책이 있다.

 

첫번째는 shareProcessNamespace 를 True로 변경한다. (가장 쉽긴하다.)

두번째는 Tini 를 사용한다. tini는 좀비 프로세스를 청소하는 역할만 전문으로 하는 초경량 init 프로세스이다.

Tini의 두가지 액션

좀비 프로세스 회수 (Reaping): Tini가 PID 1번을 맡고 앱을 자식으로 실행한다. 고아가 된 좀비 프로세스가 발생하면 Tini가 즉시 감지하여 메모리에서 해제한다.

시그널 전달 (Signal Forwarding): 종료 신호(SIGTERM)를 앱에 정확히 전달하여 파드가 30초 동안 대기하다 강제 종료되는 현상을 방지한다.

 

혹여 쿠버네티스 네이티브 환경에서 구동할 어플리케이션을 만들때 이를 위 내용을 고려해서 만들면 도움이 되지 않을까 하는 생각에서 글을 기재한다.

---

중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.