Pod와 Container의 차이

개요

데브옵스 업무를 하면 인프라 레벨의 트러블슈팅을 위해 프로덕트 팀 개발자들의 다양한 문의를 받게된다. 그 때 원인파악과 해결과정에 대해서 소통하기위해서 쿠버네티스 기본 개념들에 대해서 알려준 적이 많이 있었다. 그러면서 "아 이런 개념들은 생각보다 인프라팀이 아니면 아예 혹은 잘 모르는구나" 라고 느끼는 부분들 있었다. 내 생각에 대표적인 것이 Pod와 Container의 차이이다.

따라서 이번 기회에 Pod와 Container의 차이에 대해서 글을 남겨본다. 처음 쿠버네티스를 공부하는 사람이나.. 데브옵스팀과 원활히 협업하고 싶은 개발자 분들을 위한 글이다!

---

Container

컨테이너에 대해서는 요즘 대부분의 운영환경에서 사용되고 있기 때문에 이 글을 읽는 분들이라면 대충이라도 다 아실 것이라고 생각한다.

간단히 말해서 하나의 애플리케이션이 독립적인 환경에서 실행되는 단위라고 생각하면 된다. Docker 같은 컨테이너 런타임을 통해 이미지를 실행시키면 하나의 컨테이너가 되고, 각 컨테이너는 자신만의 파일시스템, 네트워크, 프로세스 공간을 가진다.

이런 특성 덕분에 개발부터 운영까지 일관된 환경을 보장할 수 있다. (물론 host의 kernel에 관리되고 그 때문에 CPU architecture 의존성이 생기지만 multi-platform build로 해결할 수 있다)

Container의 격리된 환경의 의미

---

Kubernetes

위와 같은 장점으로 애플리케이션을 컨테이너형태로 배포하고 관리하도록 하는 회사가 많아지고 그 회사들의 비즈니스가 발달하면서 무수히 많은 컨테이너들을 관리(배포, 확장 등)해야 했다. 그래서 구글에는 이런 니즈를 파악하고 컨테이너 자동 관리 소프트웨어를 개발했는데 그게 쿠버네티스이다.

쿠버네티스는 많은 사람들이 이름 정도는 들어봤을 것 같은데, 이 기술을 익히기에는 정말 어렵다. 내가 이걸 하면서도 어떻게 배웠지? 하는 생각이 들 정도로.. os, network 등 CS 지식은 기본이고 실무적으로도 여러 삽질을 많이 해야한다..

하지만 공식문서에는 개념설명과 학습을 위한 다양한 자료들이 제공되어있긴하다. 하지만 무턱대고 처음 보면 정말 외계어 같다..

Kubernetes Docs

그 중에서도 Workloads 항목을 보면 Pods라는 항목이있다.

---

Pods

위 문단에서 쿠버네티스는 무수히 많은 컨테이너들을 관리하기위한 툴이라고 했다. 그런데 공식문서의 첫 소개는 아래와 같다.

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

Kubernetes Pods

컨테이너를 관리하는 툴인데, 배포가능한 최소의 단위는 Pods라고 되어있는 것이다. 그리고 바로 아래에는 storage와 network 자원을 공유하는 컨테이너 그룹이라고 나와있다!

A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.

---

Network Resource Sharing

실습하면서 그 의미를 확인해보기위해서 minikube 라는걸 실행해보자. 쿠버네티스 공식 문서에서도 minikube로 튜토리얼 진행을 하고 있다

Hello Minikube

Pod를 아래와 같이 명세해서 배포해보자. (kubectl apply) Pod는 container group이라고 했는데, Pod에는 container가 1개만 있을 수도 있고 여러개 있을 수도 있다.

# single-container-pod.yaml
# Pod 1개에 Container가 1개
apiVersion: v1
kind: Pod
metadata:
  name: single-container-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.20
    ports:
    - containerPort: 80

---
# multi-container-pod.yaml  
# Pod 1개에 Container가 2개
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.20
    ports:
    - containerPort: 80
    image: busybox
    command: ['sleep', '3600']

그 다음 network 공유 여부를 확인해보자

로컬에서 Container를 실행할면 각각의 network를 가진다. 그 의미는 Container A를 3000 포트에서, Container B가 4000포트에서 실행된다고 해도, A에서 localhost:4000 으로 패킷을 보내도 호스트를 찾을 수 없다. Container A는 독립적인 네트워크를 가지고, 거기서는 3000 포트에서만 프로세스가 실행되고있기 때문이다.

하지만 같은 파드로 명세되어 실행되는 컨테이너들은 네트워크를 공유한다. 이는 localhost인 루프백인터페이스도 공유한다는 의미이므로 localhost를 통해 서로 통신할 수 있다!

# Pod 내 컨테이너들이 localhost로 통신하는지 확인
kubectl exec -it multi-container-pod -c busybox -- wget -qO- localhost:80

# 필요 패키지 설치
kubectl exec multi-container-pod -c nginx -- apt-get update
kubectl exec multi-container-pod -c nginx -- apt-get install -y iproute2

# 각 컨테이너의 네트워크 인터페이스 확인
kubectl exec multi-container-pod -c nginx -- ip addr show

kubectl exec multi-container-pod -c busybox -- ip addr

ip addr show 명령어를 쓰면 컨테이너의 네트워크 인터페이스를 확인할 수 있다. 당연히 둘이 동일하다. 대표적으로 eth0 항목을 보면 private ip 도 둘다 동일한 것을 볼 수 있다.

---

Storage Sharing

이번에는 두 컨테이너가 같은 볼륨을 공유할 수 있는 것을 볼 수 있는 실습을 해보자. (Volume)

writer와 reader 이름의 2개의 컨테이너로 파드를 구성해서 배포한다. writer 컨테이너느 시작하자마자 특정 경로에 텍스트 파일을 만들도록 되어있다 (command 참고)

# shared-volume-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-pod
spec:
  containers:
  - name: writer
    image: busybox
    command: ['sh', '-c', 'echo "Hello from writer" > /shared/message.txt && sleep 3600']
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  - name: reader
    image: busybox
    command: ['sleep', '3600']
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  volumes:
  - name: shared-data
    emptyDir: {}

아래 명령어를 쳐보면 둘다 message.txt 파일을 볼 수 있는 것을 확인할 수 있다

kubectl exec shared-volume-pod -c writer -- ls -la /shared/
kubectl exec shared-volume-pod -c writer -- cat /shared/message.txt

그 다음 reader 컨테이너에서 아래 명령을 수행해보자

# reader 컨테이너에서 같은 파일 읽기
kubectl exec shared-volume-pod -c reader -- ls -la /shared/
kubectl exec shared-volume-pod -c reader -- cat /shared/message.txt

같은 파드는 storage를 공유하기 때문에 writer container가 만든 message 파일을 읽을 수 있다.

---

Pod 설계 이유

자 그러면 컨테이너의 설계 목적이 격리된 환경에서의 프로세스 실행인데 또 파드는 왜 굳이 자원을 공유하도록 해놨을까?

그 이유는 단일 컨테이너만으로는 네트워크 설정이나 로그 수집같은 복잡한 애플리케이션 패턴을 구현하기 어렵기 때문이다.

대표적인 멀티컨테이너 Pod 사용 케이스가 그 유명한 istio이다. istio를 설정하게 되면 애플리케이션을 쿠버네티스 환경에 배포할 때, 해당 애플리케이션 컨테이너 뿐 아니라 envoy 컨테이너가 주입되어 multi container 파드로 실행된다. 그리고 envoy 컨테이너가 시작될 때 모든 네트워크 트래픽을 그 컨테이너로 먼저 라우팅하도록 ip table을 수정한다. (Pod로 묶인 컨테이너들은 network resource를 공유하기때문에 같은 network 정책이 애플리케이션 컨테이너에도 적용되게 된다.)

최신에는 ambient mode가 도입되서 host마다 배포되는 agent 형태로 네트워크를 관리하는 버전도 있다.