[CKAD] Multi-Container Pod and InitContainer

개요

Pod는 다수의 container를 동시에 가질 수 있습니다. 

그렇기 Pod에서 다수의 container를 어떻정의하고 왜 사용하는지 알아보겠습니다. 그리고 initcontainer에 대해서도 추가 적으로 알아보겠습니다. 

Multi-Container 정의 방법

spec -> containers-> container 추가

하는 방식으로 container를 추가 하면 1개의 Pod안에 다수의 Container를 실행할 수 있습니다. 

참고 : Pod의 최대 container개수는 기술 적으로 제약은 없습니다. 2~3개의 container 사용을 권장하고 있습니다.

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80
  - name: sidecar-container
    image: busybox
    command: ["sh", "-c", "while true; do echo hello; sleep 10;done"]

Multi-Container 사용 이유

다수의 container가 협력하여 하나의 작업을 수행하거나, 보조 기능을 제공할 필요가 있을 때입니다.

이때 보조 기능으로 container를 사용하기 위해서는 Pod안에서 공유가능한 영역을 사용하여 보조기능 역할을 수행해야 합니다. 

Pod안에서 container간 공유한 영역

1. 네트워크 네임스페이스 (Network Namespace)

• 공유 요소: 동일한 Pod 내의 모든 container 는 동일한 Network Namespace를 공유합니다. 이는 모든 container가 localhost를 통해 서로 통신할 수 있음을 의미합니다.
• 예시: 만약 두 개의 container가 각각 다른 port를 사용한다면, localhost:<port>를 통해 서로의 service에 접근할 수 있습니다.

2. 볼륨 (Volumes)

• 공유 요소: Pod 내의 여러 container는 동일한 volume을 mount 할 수 있습니다. 이를 통해 filesystem을 통해 data를 쉽게 공유할 수 있습니다.
• 예시: 예를 들어, 한 container가 log file을 작성하고, 다른 container가 그 file을 읽어 처리할 수 있습니다. 이 경우, 공유 volume이 mount 되어 있어야 합니다.

3. IPC 네임스페이스 (Inter-Process Communication Namespace)

• 공유 요소: 동일한 Pod 내의 container들은 기본적으로 같은 IPC namespace를 공유합니다.
  이는 container 간에 Semaphores , Message Queues , shared memory, Unix Domain Sockets , Signals, Pipes, Memory-Mapped Files, Futex 등을 사용할 수 있음을 의미합니다.
• 예시: 여러 컨테이너가 IPC를 통해 직접 통신하거나, 메모리 맵핑을 통해 데이터를 공유할 수 있습니다.

4. 프로세스 네임스페이스 (Process Namespace, 선택적)

• 공유 요소: 기본적으로 Pod 내의 컨테이너는 서로의 프로세스를 볼 수 없습니다. 하지만 특정 요구 사항이 있을 경우, shareProcessNamespace 옵션을 설정하여 프로세스를 공유할 수 있습니다.
• 예시: 하나의 컨테이너에서 실행된 프로세스를 다른 컨테이너가 모니터링하거나, 컨테이너 간에 디버깅을 할 수 있습니다.

InitContainer 란?

정의 

Pod가 생성될 때 main container가 실행되기 전에 반드시 실행되어야 하는 container입니다

Init Container는 Pod의 초기화 작업을 수행하고, 그 작업이 성공적으로 완료된 후에만 main container가 시작될 수 있습니다.

주요 특징

 

순차 실행

• Init Container는 하나 이상의 container로 구성될 수 있으며, 이들은 순차적으로 실행됩니다. 다음 Init Container는 이전 Init Container가 성공적으로 완료되어야만 실행됩니다.

실행 보장

• Init Container는 반드시 실행되어야 하며, 성공적으로 완료되지 않으면 Pod는 준비 상태가 되지 않습니다. 만약 Init Container가 실패하면, Kubernetes는 Init Container를 재시작하고, 성공할 때까지 반복합니다.

일회성 작업

• Init Container는 단 한 번 실행되고, 이후에는 실행되지 않습니다. 주로 설정, 준비 작업, 사전 조건 확인 등에 사용됩니다.

다른 image 사용 가능

• Init Container는 main application container와 다른 image와 도구를 사용할 수 있습니다. 예를 들어, main application에서 필요하지 않은 도구를 Init Container에서 사용하여 초기화 작업을 수행할 수 있습니다.

Network와 volume 공유

Init Container는 main container와 동일한 network와 volume을 공유하므로, file을 생성하거나 network 설정을 할 수 있습니다.

 

정의 방법

spec -> initContainers 에 container를 정의하면 됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'echo Initializing... && sleep 5']
  containers:
  - name: myservice
    image: nginx
    ports:
    - containerPort: 80

 

multi-container 운영 전략

1. Sidecar Pattern

• 설명: Sidecar 패턴은 주 컨테이너의 기능을 보완하거나 확장하는 보조 컨테이너를 사용하는 패턴입니다. 주로 메인 애플리케이션 컨테이너의 부가적인 기능을 분리하여 관리할 때 사용됩니다.
• 사용 사례: 로깅, 모니터링, 설정 관리, 데이터 변환, 인증 Proxy
• 구현 예시: 웹 애플리케이션 컨테이너와 함께 Sidecar 컨테이너가 로그를 수집하여 외부로 전송하거나, 설정 파일을 동적으로 관리하는 작업을 수행합니다.

2. Ambassador Pattern

• 설명: Ambassador 패턴은 외부 서비스와의 통신을 담당하는 컨테이너를 Pod 내에 배치하여, 메인 애플리케이션 컨테이너가 Ambassador를 통해 간접적으로 외부와 통신하도록 하는 패턴입니다.
• 사용 사례: 서비스 디스커버리, 요청 라우팅, 외부 API 호출 관리.
• 구현 예시: Ambassador 컨테이너가 메인 컨테이너의 요청을 Proxy로 받아 외부 API 호출을 처리하고, 응답을 전달합니다.

3. Adapter Pattern

• 설명: Adapter 패턴은 데이터를 변환하거나 프로토콜을 변환하는 보조 컨테이너를 사용하는 패턴입니다. 이를 통해 메인 컨테이너가 특정 형식이나 프로토콜을 처리하지 않고도 데이터를 사용할 수 있습니다.
• 사용 사례: 로그 형식 변환, 데이터 구조 변환, 프로토콜 변환.
• 구현 예시: 메인 컨테이너가 데이터를 생성하면, Adapter 컨테이너가 이를 다른 형식으로 변환하여 외부 서비스로 전송합니다.

4. Init Container Pattern

• 설명: Init 컨테이너는 메인 애플리케이션 컨테이너가 실행되기 전에 반드시 완료되어야 하는 초기화 작업을 수행하는 컨테이너입니다. 이 패턴을 사용하면 메인 컨테이너의 사전 조건을 보장할 수 있습니다.
• 사용 사례: 데이터베이스 스키마 마이그레이션, 설정 파일 다운로드, 초기화 작업.
• 구현 예시: Init 컨테이너가 데이터베이스의 스키마를 설정한 후, 메인 애플리케이션 컨테이너가 시작됩니다.

5. Watcher Pattern

• 설명: Watcher 패턴은 메인 컨테이너의 상태를 모니터링하고, 필요시 자동으로 대응하는 보조 컨테이너를 사용하는 패턴입니다. 메인 컨테이너의 상태를 주기적으로 점검하고, 이상이 발생하면 재시작 또는 알림을 수행할 수 있습니다.
• 사용 사례: 애플리케이션 상태 모니터링, 장애 복구, 자동 스케일링 트리거.
• 구현 예시: Watcher 컨테이너가 메인 애플리케이션 컨테이너의 로그나 상태 파일을 모니터링하며, 문제가 발생하면 이를 자동으로 복구하거나 알림을 전송합니다.

6. Proxy Pattern

• 설명: Proxy 패턴은 메인 컨테이너와 외부 리소스 간의 통신을 중재하는 역할을 하는 컨테이너를 사용하는 패턴입니다. Proxy 컨테이너는 트래픽 제어, 인증, 로깅 등의 기능을 수행할 수 있습니다.
• 사용 사례: 요청 중재, 트래픽 제어, 네트워크 보안.
• 구현 예시: Proxy 컨테이너가 메인 컨테이너의 외부 요청을 제어하고, 요청을 적절한 서비스로 routing 합니다.

7. Data Sync Pattern

• 설명: Data Sync 패턴은 여러 컨테이너 간의 데이터 동기화를 관리하는 패턴입니다. 이 패턴을 통해 메인 컨테이너가 사용하는 데이터를 다른 컨테이너에서 동기화하거나 업데이트할 수 있습니다.
• 사용 사례: 캐시 동기화, 데이터베이스 복제, 설정 파일 동기화.
• 구현 예시: 하나의 컨테이너가 외부로부터 데이터를 가져와 볼륨에 저장하고, 다른 컨테이너가 이를 읽어 사용합니다.

8. Log Aggregation Pattern

• 설명: Log Aggregation 패턴은 여러 컨테이너의 로그를 중앙에서 수집하고 처리하기 위해 사용됩니다. 이를 통해 로그 데이터를 한 곳에서 관리하고 분석할 수 있습니다.
• 사용 사례: 중앙 집중식 로그 관리, 모니터링, 감사 로그 수집.
• 구현 예시: 로그를 수집하는 컨테이너가 메인 컨테이너의 로그 파일을 읽어 중앙 로그 시스템으로 전송합니다.

정리 

Pod안에는 여러 개의 container를 실행할 수 있습니다. 특히 InitContainer를 사용하여 Pod를 먼저 초기화할 수 있습니다. 

그리고  Pod의 공유 가능한 자원을 사용하여 다양한 pattern으로 container들을 운영할 수 있습니다.