[k8s] 멀티 컨테이너 파드 - 네임스페이스(Namespace) 공유 구조와 사이드카(Sidecar) 패턴

쿠버네티스(Kubernetes)의 가장 기본적인 배포 단위인 파드(Pod)는 일반적으로 하나의 컨테이너를 포함하지만, 용도에 따라 여러 개의 컨테이너를 하나의 파드 안에 묶어서 운영할 수 있다.

이를 '멀티 컨테이너 파드'라고 하며, 컨테이너 간 긴밀한 협업이 필요한 경우 매우 효율적이다.

 

1. 멀티 컨테이너 파드의 개념과 구조

파드는 쿠버네티스에서 생성하고 관리할 수 있는 가장 작은 배포 단위다. 원칙적으로는 '1 파드 1 컨테이너' 모델이 권장되지만, 주 프로세스를 돕는 보조 프로세스(로그 수집, 프록시 등)가 필요할 때 멀티 컨테이너 구조를 사용한다.

이 구조의 핵심은 네임스페이스(Namespace) 공유다.

 

아래 그림은 하나의 파드 안에 Nginx 컨테이너와 Ubuntu 컨테이너가 실행되는 경우의 파드 간 통신을 보여주는 예다.

 

 

파드 내의 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유하므로, 서로 다른 컨테이너임에도 불구하고 localhost를 통해 통신할 수 있다.

 

2. 멀티 컨테이너 파드 생성 및 배포

위 예시처럼 Nginx 웹 서버와 이를 테스트할 Ubuntu 클라이언트를 하나의 파드에 정의하고 생성해보자.

🟣YAML 매니페스트 작성

nano 편집기를 사용하여 파드의 명세(Manifest)를 작성한다.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod01 
spec:
  containers:
  - name: container01-nginx
    image: nginx:latest
    ports:
    - containerPort: 80
      protocol: TCP
  - name: container02-ubuntu      
    image: alicek106/rr-test:curl
    command: ["tail"]
    args: ["-f", "/dev/null"]

 

• spec: containers : 하위에 두 개의 컨테이너를 정의함.
• Ubuntu 컨테이너에는 tail -f /dev/null 명령을 주어 컨테이너가 종료되지 않고 백그라운드에서 계속 대기하도록 설정함.

 

🟣파드 배포 및 상태 확인

작성된 파일을 쿠버네티스 클러스터에 적용한다.

# 오브젝트 생성
kubectl apply -f nginx-pod.yml

# 생성 확인
kubectl get po -o wide

NAME                     READY   STATUS    RESTARTS        AGE    IP            NODE           NOMINATED NODE   READINESS GATES
test-pod01               2/2     Running   0               24s    10.244.2.13   k8s-worker-2   <none>           <none>

 

• kubectl은 마스터 노드의 kube-apiserver에 YAML 파일을 전달한다. 이후 스케줄러가 적절한 워커 노드를 선택하고, 해당 노드의 kubelet이 컨테이너 런타임을 통해 파드를 실행한다.
• READY 항목이 2/2로 표시되는 것은 하나의 파드 안에 두 개의 컨테이너가 모두 정상적으로 실행 중임을 의미한다.

 

3. 컨테이너 간 네트워크 공유

멀티 컨테이너 파드의 가장 큰 특징인 '로컬 네트워크 공유'를 확인해보자.

🟣특정 컨테이너 접속 및 통신 테스트

두 번째 컨테이너(container02-ubuntu)에 접속하여 첫 번째 컨테이너의 Nginx 서비스에 접근한다.

# 특정 컨테이너 지정 접속 (-c 옵션 사용)
kubectl exec -it test-pod01 -c container02-ubuntu -- /bin/sh

# 로컬호스트로 HTTP 요청
curl localhost

 

• 동작 원리: 일반적으로 서로 다른 컨테이너는 IP가 다르지만, 파드 내부에서는 동일한 네트워크 스택을 공유한다. 따라서 Ubuntu 컨테이너에서 curl localhost를 호출하면 같은 파드 내 80번 포트를 점유 중인 Nginx 컨테이너로 데이터가 전달된다.
• 핵심 개념: 도커 환경에서는 --links 옵션을 사용해 수동으로 연결해야 하지만, 쿠버네티스 파드 모델에서는 별도 설정 없이도 고성능의 내부 통신이 가능하다.

4. Deployment를 이용한 리플리카 확장

파드를 직접 생성하는 대신 Deployment를 사용하면 파드의 복제본(Replica) 개수를 유지하고 관리할 수 있다.

🟣복제본 3개를 갖는 Deployment 작성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-test
  template:
    metadata:
      labels:
        app: web-test
    spec:
      containers:
      - name: container01-nginx
        image: nginx:latest
      - name: container02-ubuntu
        image: alicek106/rr-test:curl
        command: ["tail"]
        args: ["-f", "/dev/null"]

 

🟣리플리카 확장 구조 (Container 레벨 포함)

 

4. 쿠버네티스 아키텍처와 리소스 관리

쿠버네티스를 원활하게 운영하기 위해서는 상위 관리 객체와 시스템 구성 요소에 대한 이해가 필요하다.

 

 

☑️Deployment

파드의 배포와 관리를 담당하는 매니저다. 파드가 중단되면 자동으로 재생성하여 설정된 개수(replicas)를 유지하며, Rolling Update와 Roll Back을 통해 무중단 배포를 지원한다.

 

☑️Namespace

클러스터 내의 리소스를 논리적으로 분리하는 단위다. 팀별, 프로젝트별로 작업 환경을 격리할 때 사용하며, 규모 면에서 Deployment보다 큰 범주에 속한다.

네임스페이스의 역할

• 리소스 격리: 팀별, 프로젝트별, 또는 개발/테스트/운영 환경별로 리소스를 분리하여 서로 간섭하지 않게 한다.
• 권한 관리: 특정 네임스페이스에 대해서만 접근 권한을 부여하여 보안을 강화할 수 있다.
• 자원 제한 (Quota): 특정 네임스페이스가 사용할 수 있는 CPU나 메모리의 총합을 제한하여, 한 프로젝트가 클러스터 전체 자원을 독점하는 것을 방지한다.

☑️시스템 구성 요소

• kube-apiserver: 모든 조작의 입구 역할을 하는 API 서버.
• etcd: 클러스터의 모든 상태 정보를 저장하는 키-값 저장소.
• kubelet: 각 노드에서 파드의 실행을 관리하는 에이전트.
• kube-proxy: 노드별 네트워크 규칙을 관리하여 통신을 가능하게 함.

 

5. 사이드카 패턴이란? 

 

사이드카(Sidecar) 패턴은 오토바이 옆에 붙어 있는 사이드카처럼, 메인 컨테이너의 기능을 확장하거나 보조하기 위해 별도의 컨테이너를 같은 파드(Pod) 안에 추가하는 설계 방식을 의미한다.

메인 애플리케이션의 코드를 수정하지 않고도 로그 수집, 모니터링, 보안 통신(Proxy) 등의 기능을 독립적으로 추가할 수 있다는 것이 가장 큰 장점이다.

 

🟢사이드카 패턴의 구조

사이드카 컨테이너는 메인 컨테이너와 동일한 파드에 담겨 있으므로, 네트워크(Localhost)와 저장 공간(Volume)을 공유한다.

실제 운영 환경에서는 다음과 같은 방식으로 구성된다.

spec:
  containers:
  - name: app-container
    image: my-web-app:1.0 # 메인 서비스
  - name: log-sidecar
    image: fluentd:latest  # 사이드카 (로그 수집)

 

정리 및 결론

멀티 컨테이너 파드 모델은 주 컨테이너의 기능을 보조하는 사이드카 패턴 등을 구현할 때 유용하다.

사이드카 패턴을 잘 활용하면 애플리케이션의 비즈니스 로직과 인프라 로직(로그, 보안, 통신)을 깔끔하게 분리할 수 있다.

Deployment를 통해 이를 관리함으로써 서비스의 고가용성과 확장성을 동시에 확보할 수 있다.