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 분할 격리
참고 : https://ssup2.github.io/theory_analysis/Kubernetes_Pod/
- 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를 자식 프로세스들이 공유하는 구조이다
- Pod 안의 Container들이 동일한 Ip 주소를 가지는 것도, 같은 네트워크를 가지는 것도 Pause Container의 Net Namespace를 공유하기 때문이다
- 해당 기능을 사용하지 않으면, 각 Container는 고유한 Init Process를 가진다
- Kubernetes 1.7 버전 이상에서만 사용 가능한 기능이다
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가 프로그램을 실행하고 있을 때, 예외 상황이 발생하여 처리가 필요한 경우에 마이크로 프로세서에게 알려 처리하게 하고, 처리가 끝나면 이전에 실행중인 프로그램으로 복귀하게 하는 것
- 소프트웨어 인터럽트 : 소프트웨어가 발생시키는 인터럽트로 시스템 콜을 통해 구현될 수 있다
좋은 정보 감사합니다