[Kubernetes] Pod

쿠버네티스에는 컨테이너 애플리케이션을 구동하기 위해 반드시 알아야할 몇 가지 오브젝트가 존재한다.

Pod / Replica Set / Service / Deployment

그 중 하나인 Pod에 대해서 알아보자.

Pod

컨테이너 애플리케이션의 기본 단위이며, 1개 이상의 컨테이너로 구성된 컨테이너의 집합이다. 파드는 쿠버네티스에서 가장 기초적이고 중요한 개념이기 때문에, 반드시 이해해야 하는 개념이다.

쿠버네티스에서는 컨테이너 애플리케이션을 배포하기 위한 기본 단위로 파드라는 개념을 사용한다. 1개의 파드에는 1개의 컨테이너가 존재할 수도 있고, 여러 개의 컨테이너가 존재할 수도 있다.

# nginx-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
spec:
  containers:
  -name: my-nginx-container
  image: nginx:latest
  ports:
  - containerPort: 80
   protocol: TCP

- apiVersion : YAML 파일에서 정의한 오브젝트의 API 버전. 오브젝트의 종류 및 개발 성숙도에 따라 apiVersion의 설정값이 달라질 수 있다.

- kind : 이 리소스의 종류를 뜻하며, kind 항목에서 사용할 수 있는 리소스 오브젝트 종류는 kubectl api-resources 명령어의 KIND 항목에서 확인이 가능하다.

- metadata : 라벨, 주석, 이름 등과 같은 리소스의 부가 정보들을 입력한다. 위 예시에서는 name 항목에서 파드의 고유한 이름을 my-nginx-pod로 설정

- spec : 리소스를 생성하기 위한 자세한 정보를 입력한다. 위 예시에서는 파드에서 실행될 컨테이너 정보를 정의하는 containers 항목을 작성한 뒤, 하위 항목인 image에서 사용할 도커 이미지를 지정하였다. name 항목에서는 컨테이너의 이름을, ports 항목에서는 Nginx 컨테이너가 사용할 포트인 80을 입력

YAML 파일에 사용할 포트를 정의하긴 했으나, 아직 외부에서 접근할 수 있도록 노출된 상태는 아니다. 따라서 파드의 Nginx 서버로 요청을 보내려면 파드 컨테이너의 내부 IP로 접근해야 한다.

 - kubectl exec [POD] -- [COMMAND] : 파드 컨테이너에 명령어를 전달할 수 있는 옵션

 

vs 도커 컨테이너

지금까지 내용을 봤을 때 파드는 docker run 으로 생성한 단일 nginx 컨테이너와 크게 다르지 않아 보인다.

파드는 컨테이너 IP 주소를 가지고 있어 쿠버네티스 클러스터 내부에서 접근할 수 있으며, kubectl logs 명령어로 파드의 로그 조회도 가능하다. 그렇다면 쿠버네티스는 왜 도커 컨테이너가 아닌 파드라는 새로운 개념을 사용하는 이유는 무엇일까? 많은 이유가 있지만, 가장 큰 이유 중 하나는 여러 Linux Namespace를 공유하는 여러 컨테이너들을 추상화된 집합으로 사용하기 위함에 있다.

실제로 대부분 쿠버네티스의 컨테이너 애플리케이션은 1개의 컨테이너로 파드를 구성해 사용한다.

그러나 파드는 반드시 1개의 컨테이너로 구성해야 하는 것이 아님을 명심하자.

이번에는 위 nginx 파드에 새로운 우분투 컨테이너를 추가해보자.

apiVersion: v1
kind: Pod
metadata:
    name: my-nginx-pod
spec:
    containers:
    - name: my-nginx-container # '-': 여러 개의 항목을 정의할 수 있음을 의미
      image: nginx:latest
      ports:
      - containerPort: 80
        protocol: TCP

    - name: ubuntu-sidecar-container
      image: alicek106/rr-test:curl
      command: ["tail"]
      args: ["-f", "/dev/null"] # 컨테이너가 종료되지 않도록 유지

Pod의 Yaml 파일에서 사용되는 command와 args는 컨테이너 내부에서 가장 먼저 실행될 프로세스를 지정한다.

YAML 파일에서의 command는 도커 컨테이너의 Entrypoint와 동일하고, 파드에서의 args는 도커 컨테이너의 CMD와 동일하다고 보면된다.

해당 파일을 kubectl apply -f 파일명.yaml 명령어를 실행한 뒤, 우분투 컨테이너 내부에 접속 후 curl localhost를 실행시켜주면 Nginx 서버를 실행하고 있지 않음에도 우분투 컨테이너의 localhost에서 Nginx 서버로 접근이 가능해졌다. 이유는 파드 내 컨테이너들이 네트워크 네임스페이스 등과 같은 리눅스 네임스페이스를 공유해 사용하기 때문이다.

 

완전한 애플리케이션으로서의 파드

기억하자, 하나의 파드는 하나의 완전한 애플리케이션이다.

Nginx 컨테이너는 그 자체만으로도 완전한 애플리케이션이기 때문에, 하나의 파드에 2개의 Nginx 컨테이너가 정의되는 것은 바람직하지 않다. 그러나 Nginx 컨테이너가 실행되기 위해 부가적인 기능을 필요로 한다면?

1. Nginx 설정 파일의 변경 사항을 갱신해주는 설정 리로더 프로세스

2. 로그를 수집해주는 프로세스는 Nginx 컨테이너와 함께 실행되어야 할 수 있다.

이런 경우 파드의 주 컨테이너를 Nginx로 하되, 기능 확장을 위한 추가 컨테이너를 함께 파드에 포함시킬 수 있다. 이렇게 정의된 부가적 컨테이너를 사이드카 컨테이너로 불리며, 사이드카 컨테이너는 파드 내의 다른 컨테이너와 네트워크 환경 등을 공유하게 된다. 때문에 파드에 포함된 컨테이너들은 모두 같은 워커 노드에서 함께 실행된다.

이런 구조에 따라 파드에 정의된 여러 개의 컨테이너는 하나의 완전한 애플리케이션으로서 동작하게 되며, 이것이 도커 컨테이너와 쿠버네티스 파드의 차이점이다.