K8s문서 - 파드(Pod) 개요

쿠버네티스 - Pod 개요

Pod Overview

이 페이지는 쿠버네티스 객체 모델 중 가장 작은 배포 가능한 객체인 Pod에 대한 개요를 제공한다.

1 Pod 이해하기

'Pod'은 쿠버네티스의 기본 구성 요소이다. 쿠버네티스 객체 모델 중 만들고 배포할 수 있는 가장 작고 간단한 단위이다. Pod은 클러스터에서의 Running 프로세스를 나타낸다.

Pod은 애플리케이션 컨테이너(또는 경우에 따라 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP, 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화한다. Pod은 배포의 단위(쿠버네티스에서의 애플리케이션 단일 인스턴스)를 의미한다.

Docker는 쿠버네티스 Pod에서 사용되는 가장 대표적인 컨테이너 런타임이지만, Pod은 다른 컨테이너 런타임 역시 지원한다.

쿠버네티스 클러스터 내부의 Pod은 주로 두 가지 방법으로 사용된다.

• 단일 컨테이너를 구동하는 Pod. "단일 컨테이너 당 1개의 Pod" 모델은 쿠버네티스 사용 사례 중 가장 흔하다. 이 경우, 한 개의 Pod이 단일 컨테이너를 감싸고 있다고 생각할 수 있으며, 쿠버네티스는 컨테이너가 아닌 Pod을 직접 관리한다고 볼 수 있다.

• 함께 동작해야 하는 다중 컨테이너를 구동하는 Pod. 아마 Pod은 강하게 결합되어 있고 리소스 공유가 필요한 다중으로 함께 배치된 컨테이너로 구성되어 있을 것이다. 이렇게 함께 배치되어 설치된 컨테이너는 단일 결합 서비스 단위일 것이다. 한 컨테이너는 공유 볼륨에서 퍼블릭으로 파일들을 옮기고, 동시에 분리되어 있는 "사이드카" 컨테이너는 그 파일들을 업데이트 하거나 복구한다. Pod은 이 컨테이너와 저장소 리소스들을 한 개의 관리 가능한 요소로 묶는다.

쿠버네티스 블로그에는 Pod 사용 사례의 몇 가지 추가적인 정보가 있다. 더 많은 정보를 위해서 아래 내용을 참고하기 바란다.

• 분산 시스템 툴킷: 복합 컨테이너를 위한 패턴
• 컨테이너 디자인 패턴

각각의 Pod은 주어진 애플리케이션에서 단일 인스턴스로 동작을 하는 것을 말한다. 만약 애플리케이션을 수평적으로 스케일하기를 원하면(예를 들면, 다중 인스턴스 동작하는 것), 각 인스턴스 당 1개씩 다중 Pod을 사용해야 한다. 쿠버네티스에서는, 일반적으로 이것을 복제 라고 한다. 복제된 Pod은 주로 컨트롤러라고 하는 추상화 개념의 그룹에 의해 만들어지고 관리된다. 자세한 사항은 Pod과 컨트롤러를 참고하기 바란다.

2 Pod은 어떻게 다중 컨테이너를 관리하는가

Pod은 결합도가 있는 단위의 서비스를 형성하는 다중 협력 프로세스(컨테이너)를 지원하도록 디자인 되었다. Pod 내부의 컨테이너는 자동으로 동일한 물리적 또는 가상의 머신의 클러스터에 함께 배치되고 스케쥴된다. 컨테이너는 리소스와 의존성 공유, 다른 컨테이너와의 통신 그리고 언제 어떻게 조절하는지를 공유할 수 있다.

단일 Pod 내부에서 함께 배치되고 관리되는 컨테이너 그룹은 상대적으로 심화된 사용 예시임에 유의하자. 컨테이너가 강하게 결합된 특별한 인스턴스의 경우에만 이 패턴을 사용하는게 좋다. 예를 들어, 공유 볼륨 내부 파일의 웹 서버 역할을 하는 컨테이너와 원격 소스로부터 그 파일들을 업데이트하는 분리된 "사이드카" 컨테이너가 있는 경우 아래 다이어그램의 모습일 것이다.

<img src=" " style="width:300px"/> Pod 다이어그램

Pod은 같은 Pod 안에 속한 컨테이너에 2가지 공유 리소스('네트워킹'과 '저장소')를 제공한다.

2.1 네트워킹

각각의 Pod은 유일한 IP주소를 할당 받는다. 한 Pod 내부의 모든 컨테이너는 네트워크 네임스페이스와 IP주소 및 네트워크 포트를 공유한다. Pod 안에 있는 컨테이너는 다른 컨테이너와 localhost를 통해서 통신할 수 있다. 특정 Pod 안에 있는 컨테이너가 'Pod 바깥'의 요소들과 통신하기 위해서는, 네트워크 리소스를 어떻게 쓰고 있는지 공유해야 한다(예: 포트).

2.2 저장소

Pod은 공유 저장소 집합인 '볼륨'을 명시할 수 있다. Pod 내부의 모든 컨테이너는 공유 볼륨에 접근할 수 있고, 그 컨테이너끼리 데이터를 공유하는 것을 허용한다. 또한 볼륨은 컨테이너가 재시작되어야 하는 상황에도 Pod 안의 데이터가 영구적으로 유지될 수 있게 한다. 쿠버네티스가 어떻게 Pod 안의 공유 저장소를 사용하는지 보려면 볼륨을 참고하기 바란다.

3 Pod 다루기

직접 쿠버네티스에서 개별 Pod을 만들 일은 - 싱글톤 Pod이더라도 - 거의 없을 것이다. 그 이유는 Pod이 상대적으로 수명이 짧고 일시적이기 때문이다. Pod이 만들어지면(직접 만들거나, 컨트롤러에 의해서 간접적으로 만들어지거나), 그것은 클러스터의 노드에서 동작할 것이다. Pod은 프로세스가 종료되거나, Pod 객체가 삭제되거나, Pod이 리소스의 부족으로 인해 제거되거나, 노드에 장애가 생기지 않는 한 노드에 남아 있게 된다.

⚠️

Pod 내부에서 재시작되는 컨테이너를 Pod과 함께 재시작되는 컨테이너로 혼동해서는 안된다. Pod은 자기 스스로 동작하지 않는다. 하지만 컨테이너 환경은 그것이 삭제될 때까지 계속 동작한다.

Pod은 셀프힐링을 하지 않는다. 만약 Pod이 스케줄링된 노드에 장애가 생기거나, 스케쥴링 동작이 스스로 실패할 경우 Pod은 삭제된다. 그와 비슷하게, Pod은 리소스나 노드의 유지 부족으로 인해 제거되는 상황에서 살아남지 못할 것이다. 쿠버네티스는 상대적으로 일시적인 Pod 인스턴스를 관리하는 작업을 처리하는 컨트롤러라고 하는 고수준의 추상적 개념을 사용한다. 즉, Pod을 직접적으로 사용가능 하지만, 컨트롤러를 사용하여 Pod을 관리하는 것이 쿠버네티스에서 훨씬 더 보편적이다. 쿠버네티스가 어떻게 Pod 스케일링, 힐링하는지 보려면 Pod과 컨트롤러를 참고하기 바란다.

3.1 Pod과 컨트롤러

컨트롤러는 다중 Pod을 생성하고 관리해 주는데, 클러스터 범위 내에서의 레플리케이션 핸들링, 롤아웃, 셀프힐링 기능 제공을 한다. 예를 들어, 만약 노드가 고장났을 때, 컨트롤러는 다른 노드에 Pod을 스케줄링함으로써 자동으로 교체할 것이다.

1가지 이상의 Pod을 보유한 컨트롤러의 몇 가지 예시

• 디플로이먼트
• 스테이트풀 셋
• 데몬 셋

일반적으로, 컨트롤러는 책임을 지고 제공한 Pod템플릿을 사용한다.

4 Pod 템플릿

Pod 템플릿은 레플리케이션 컨트롤러, 잡, 데몬 셋과 같은 다른 객체를 포함하는 Pod 명세서이다. 컨트롤러는 Pod 템플릿을 사용하여 실제 Pod을 만든다. 아래 예시는 메시지를 출력하는 컨테이너를 포함하는 Pod에 대한 간단한 매니페스트이다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Pod 템플릿은, 모든 레플리카의 현재 원하는 상태를 지정한다기 보다는 쿠키 틀에 가깝다. 일단 쿠키가 커팅되고 나면, 그 쿠키는 쿠키 틀에 영향을 받지 않는다. "양자 얽힘" 따위는 없는 것이다. 그 이후 템플릿을 변경하거나 새로운 템플릿으로 바꿔도 이미 만들어진 Pod에는 직접적인 영향이 없다. 마찬가지로, 레플리케이션 컨트롤러에 의해 만들어진 Pod은 아마 그 이후 직접 업데이트될 수 있다. 이것은 모든 컨테이너가 속해있는 Pod에서 현재 원하는 상태를 명시하는 것과 의도적으로 대비가 된다. 이러한 접근은 시스템의 의미를 철저히 단순화하고 유연성을 증가시킨다.

5 같이 보기

• 쿠버네티스 Pod
• k8s문서 - Pod#Pod 종료

6 참고

• https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/
• https://kubernetes.io/ko/docs/concepts/workloads/pods/pod-overview/