0부터 시작하는 Kubernetes 공부 - Pause Container & Pod 내 공유 Namespace

Jaehong Lee·2023년 6월 14일
4
post-thumbnail

1. Linux Namespace

Linux Namespace

  • Namespace는 하나의 시스템에서 프로세스를 논리적으로 격리시킬 수 있는 가상화 기술이다

    • Namespace는 동일한 OS와 자원 위에서 공간을 분리하는 것이고, HyperVisor는 자원을 분리하여 그 위에 각각의 OS가 돌아가는 것이다
  • Namespace의 종류는 아래와 같다

    • UTS Namespace : Hostname을 변경하고 분할
    • IPC Namespace : 프로세스간 통신 격리
    • PID Namespace : Process ID 를 분할 관리
    • MNT Namespace : File System의 Mount 지점을 분할하여 관리
    • NET Namespace : Network Interface, Iptables 등 Network 리소스와 관련 정보 분할
    • USER Namespace : User와 Group ID 분할 격리

Pod 내 공유되는 Namespace

참고 : https://ssup2.github.io/theory_analysis/Kubernetes_Pod/

일반적으로 하나의 Pod에는 하나의 애플리케이션만을 구동시킨다. 만약 Multi Container Pod라면, 어떠한 Namespace를 공유할까?

  • Pod 내부의 Container 들은 기본적으로 Pause Container의 NET Namespace, IPC Namespace, UTS Namespace를 공유한다
  • Docker Container의 경우, 기본적으로 User Namespace를 격리하지 않는다. 따라서 컨테이너의 User가 Host와 같은 UID 권한을 사용할 수 있다

  • PID Namespace는 기본적으로 Container 별로 격리하지만, 공유하게 할 수 있다. 단, MNT Namespace는 절대 공유하지 않는다
  • IPC Namespace : IPC 리소스 ( 세마포어, 메시지 큐, 공유 메모리 )를 분할 & 격리하여 프로세스간 통신을 격리시킨다

  • Net Namespace ( Network Namespace ) : Host Network와 논리적으로 격리된 Network 공간으로, Network Interface / Routing Table / Forwarding Table / Iptables 와 같은 Network 리소스와 관련 정보를 가진다

    • Host 자체도 하나의 Network Namespace를 가진다 ( Root Namespace ). Init 프로세스에 할당된 Root Namespace를 자식 프로세스들이 공유하는 구조이다

2. Pause Container

Pause Container 란

  • Pause Container는 기본적으로 Pod 내부의 Container 들에게 Net Namespace, Ipc Namespace, Uts Namespace를 제공해주는 부모 Container 이다. Pod 내부 Container 들은 Pause Container의 Net Namespace와 Ipc Namespace, Uts Namespace를 공유한다
    • Pod 안의 Container들이 동일한 Ip 주소를 가지는 것도, 같은 네트워크를 가지는 것도 Pause Container의 Net Namespace를 공유하기 때문이다

  • Pause Container에 PID Namespace 공유를 설정할 경우, Pod의 Init Process ( PID : 1 ) 로서의 역할을 수행하고, 좀비 프로세스를 거둬들이는 기능도 수행한다
    • 해당 기능을 사용하지 않으면, 각 Container는 고유한 Init Process를 가진다
    • Kubernetes 1.7 버전 이상에서만 사용 가능한 기능이다

Pause Container 사용 이유

  • Pause Container의 Namespace를 공유하는 이유는 App Container가 불안정하기 때문이다. App Container의 App이 죽으면 App Container가 삭제되는데, Kubernetes는 App Container의 App이 언제 죽을지 모른다. 따라서 App Container의 Namespace를 공유하지 않는다

  • Pause Container는 Pod에 반드시 하나가 생성된다. Pause Container는 Pause라고 불리는 Binary를 구동하는데, Pause Binary는 pause() 시스템 콜을 호출하여 Signal을 받을 때 까지 대기 상태가 된다. 따라서 Signal을 받을 때까지 죽지 않으므로, 안정적이다

    • Binary : 실행 가능한 형식의 데이터 파일 ( ex. EXE , ELF )
    • Signal : 비동기적인 이벤트를 발생시키는 소프트웨어 인터럽트로 특정 프로세스의 동작을 멈추거나, 다른 동작을 하게 하는 신호이다
    • 인터럽트 : CPU가 프로그램을 실행하고 있을 때, 예외 상황이 발생하여 처리가 필요한 경우에 마이크로 프로세서에게 알려 처리하게 하고, 처리가 끝나면 이전에 실행중인 프로그램으로 복귀하게 하는 것
    • 소프트웨어 인터럽트 : 소프트웨어가 발생시키는 인터럽트로 시스템 콜을 통해 구현될 수 있다

따라서 불안정적인 App Container가 아닌, 안정적인 Pause Container의 Namespace를 공유한다

profile
멋진 엔지니어가 될 때까지

1개의 댓글

comment-user-thumbnail
2023년 6월 18일

좋은 정보 감사합니다

답글 달기