[Kubernetes] Pod란 ?

AWS EKS 실습을 진행하면서 만났던 생소한 개념들을 정리하는 글. 하단 링크 글이 많은 도움이 되었다.

[Kubernetes] 쿠버네티스 Pod

✔️ Pod란 ?

https://artist-developer.tistory.com/32?category=949818

Pod란 쿠버네티스의 가장 기본적인 배포 단위이다. 

마스터 노드에서는 워커 노드로 Pod를 전달하고 워커 노드에서는 Pod를 수행하는 구조이다.

한 개의 워커 노드에는 N개의 Pod들이 돌아가게 된다. 

 

쿠버네티스는 컨테이너(Docker 등)를 개별적으로 배포하는 것이 아닌 Pod 안에 탑재하여 배포한다.

이 때 Pod 안에는 1개 이상의 컨테이너가 탑재될 수 있다. (N container ⊂ 1 Pod)

 

왜 여러개의 컨테이너를 Pod 단위로 묶어 배포하는가 ?!

 

✔️ Pod에 N개의 컨테이너를 묶어 배포하는 이유

https://kubernetes.io/docs/concepts/workloads/pods/

1. Pod 내부 컨테이너 간의 IP 및 Port 공유를 통한 통신 용이성 향상 

N개의 컨테이너가 한개의 Pod에 탑재되어 배포된 어플리케이션을 고려해보자 

이 어플리케이션 안의 컨테이너 A, B끼리는 실시간으로 데이터를 교환하며 그에 따라 상태를 업데이트해야 한다. 

이때, 두 컨테이너 A, B는 별도의 IP 호출없이 localhost를 통해 통신이 가능하다.

만약 A에 port 7080, B에 port 8090이 할당되었다면 A가 B를 호출할 때는 localhost:8090 그 반대는 localhost:7080으로 접근할 수 있다.

정리하자면, Pod 내부 컨테이너 간의 IP 및 Port를 공유함으로써 상호 동작해야 하는 컨테이너끼리 통신 용이성을 향상시킨다. 

 

2. Pod 내부 컨테이너 간의 디스크 볼륨 공유 

Pod 내에 함께 배포된 컨테이너끼리는 디스크 볼륨을 공유할 수 있다.

위의 상황에서 A, B가 볼륨을 공유하므로 A가 B의 파일을 읽어올 수 있다.뿐만 아니라, 로그 수집기를 사이드카 패턴(side car pattern)을 통해 Pod에 탑재해 배포할 경우, Pod 내부 컨테이너들의 로그를 모두 수집할 수 있다.

 

위의 이유들로 인해 1개의 Pod에 여러개의 컨테이너를 탑재해 배포하는 것은 큰 장점을 가지게 된다.

 

이를 통해 만들어진 Pod를 배포하면 단일 인스턴스가 만들어진다.유저 유입의 증가, 트래픽 증가로 인해 더 많은 리소스를 제공하기 위해 수평적으로 어플리케이션을 확장하려면 단일 인스턴스를 만드는 Pod를 복제하는 레플리케이션을 수행해야 한다. 

 

✔️ Pod의 생성

Pods

Pod의 생성은 yaml, Json 등의 template을 주로 사용한다. 

물론 kubectl create와 옵션의 조합을 통해 만들수도 있지만, template을 통해 만들고 수정이 필요하면 template를 업데이트하는 것이 더 좋은 방법이다.

apiVersion: batch/v1
kind: Pod
metadata:
  name: hello
  labes:
   app: myapp
spec:
  template:
    # This is the pod template
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # The pod template ends here

기본적인 Pod 생성을 위한 yaml template는 위와 같다.

yaml 파일은 기본적으로 들여쓰기를 기준으로 동작하므로 작성 시 주의해야 한다.

 

하나씩 의미를 알아보자 

apiVersion : batch/v1

쿠버네티스 API의 버전 명세이다.

apps/v1, batch/v1 처럼 depth를 깊게 작성해주거나 v1 이라고 작성해도 된다.

Kind: Pod

생성할 쿠버네티스의 리소스 타입이다.

Pod, deployment, statefulset 등 수많은 쿠버네티스 리소스는 yaml 등의 template을 통해 생성할 수 있다.

현재 정의하고 있는 것은 Pod이다. 

metadata:
  name: hello
  labes:
   app: myapp

metadata 정의부이다. 생성할 Pod의 이름과 label을 정하는 것이다.

label은 특정 쿠버네티스 리소스를 검색할 때 사용하는 Key-Value 형태의 데이터이다.

myapp 이라는 app label을 통해 myapp-pod를 검색할 수 있는 것이다.

spec:
  template:
    # This is the pod template
    spec:
      containers:
      - name: hello
        image: busybox
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # The pod template ends here

Pod의 구체적인 사양을 정의하는 Spec부이다. 

하위로 수많은 항목이 나열되는데 여기서는 containers만 사용하고 있다. 

1개의 Pod는 N개의 컨테이너를 탑재할 수 있는데 이 예시에서는 hello라는 1개의 컨테이너만을 정의했다.

 

컨테이너에는 image가 명세되어야 한다. 

이 예시에서는 busybox 이미지를 사용하고 있다.

docker registry를 구체적으로 명세하여 가져올 수도 있다. 

이 예시에서는 registry를 명세하지 않아 docker hub의 docker 공식 registry에서 이미지를 가져오게 된다.

 

command는 컨테이너가 생성된 직후 실행되는 명령어를 명세한다. 

실행되자마다 command에 있는 명령어들이 실행된다. 

 

restartPolicy 필드 옵션이다. restartPolicy 필드 옵션에는 3가지가 있다.

• Always - 항상 재시작
• OnFailure - 비정상 종료 발생 시 컨테이너를 재시작
• Never - 재시작을 하지 않음

Pods

공식 문서에서 "Example states"를 검색해 상황에 따른 재시작 유무를 확인할 수 있다. 

 

정리하자면 위의 .yaml file은 'Hello Kubernetes!' 문구를 출력하고 1시간 동안 sleep하는 어플리케이션을 배포하는 pod이다. 

kubectl apply -f "파일명.yaml"

kubectl apply 명령어를 통해 yaml file로 명세한 Pod를 배포할 수 있다. 

kubectl get pods

생성된 Pod의 배포 결과를 조회하기 위한 명령어이다. 

kubectl logs pod/hello

해당 Pod의 로그 데이터를 확인할 수 있다.

 

한시간 동안 해당 Pod은 Sleep 상태로 대기한 뒤 종료될 것이다.

✔️ Pod의 단계

Pod status의 값들은 다음과 같다.

• Pending : Pod 배포 명령이 있었으나, Pod 내부 1개 이상의 컨테이너가 실행할 준비가 되지 않음 실행까지 오류가 발생할 경우 Pending 상태에서 대기할 수 있음.
• Running : Pod가 워커 노드에 바인딩되었고, 해당 Pod의 모든 컨테이너가 생성되었음. 정상 동작 상태.
• Failed : Pod의 모든 컨테이너가 종료되었으나, 한 개 이상의 컨테이너가 실패로 종료되었음.
• Unknown : 임의의 이유로 인해 Pod의 상태를 알 수 없음. 일반적으로는 해당 워커 노드와 마스터 노드의 통신 오류로 인해 발생

추가로 Pod는 Pod 내부에서 각 컨테이너의 상태를 추적한다.

kubectl describe pod "Pod name"

명령어를 통해 Pod 내부 특정 컨테이너의 상태를 확인할 수 있다.

• Running : 컨테이너가 문제없이 실행되고 있음을 의미한다.
• Terminated : 컨테이너가 실행을 시작한 다음 완료될 때까지 모두 정상 실행되었거나, 특정한 이유로 실패하여 컨테이너가 종료된 상태이다. kubectl describe 명령어를 통해 종료 코드 등을 확인할 수 있다.
• Waiting : 컨테이너가 Running, Terminated 상태가 아니면 모두 Waiting 상태이다. 컨테이너를 시작하기 위해 필요한 작업(이미지 레지스트리에서 이미지를 Pulling 하거나 시크릿 데이터를 적용하는 등)을 실행하고 있는 중이다. 

일반적으로 Pod 내부 컨테이너는 Waiting -> Running -> Terminated의 상태 단계를 가진다.