Pod

Pod

https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers

 

Kubernetes에서의 Pod는 Kubernetes 애플리케이션의 기본 실행 단위입니다. Pod는 공유 네임스페이스와 공유 파일 시스템 볼륨을 가진 일련의 컨테이너와 유사합니다. 이를 애플리케이션이 실행되는 고유한 환경으로 생각할 수 있으며, 하나 이상의 애플리케이션 컨테이너와 공유 스토리지/네트워크 리소스를 캡슐화합니다. Pod는 코드가 실행되는 장소입니다.

Pod와 컨테이너의 차이점

개념적으로, Pod는 컨테이너와 비교될 수 있으며, 특히 Kubernetes를 Docker Compose와 비교할 때 그렇습니다. Pods는 Kubernetes에서 Docker Compose의 컨테이너와 동일한 역할을 수행하지만, 실제로는 하나 이상의 컨테이너에 대한 추상화 계층으로, 관련 네트워킹 및 스토리지 구성을 포함합니다. Pods는 여러 컨테이너를 포함할 수 있지만, 모범 사례는 애플리케이션 코드를 실행하는 단일 주요 컨테이너와 로깅, 모니터링 및 네트워킹과 같은 추가 기능을 제공하는 0개 이상의 지원 컨테이너를 가지는 것입니다. 이 패턴을 사이드카 패턴이라고 하며, 이러한 지원 컨테이너를 사이드카 컨테이너라고 합니다.

Pod와 노드의 차이점

노드는 Kubernetes에서 Pod가 실행되는 워커입니다. 노드는 AWS EC2 인스턴스와 같은 가상 인스턴스일 수도 있고, 물리적 컴퓨터 서버일 수도 있습니다. Pods는 노드에 할당되며, 클러스터에 노드가 제공하는 용량을 소비하면서 해당 노드에서 실행됩니다. Pods는 명시적으로 노드에 묶여 있지 않으며, Kubernetes 제어 평면에 의해 할당되고 필요에 따라 한 노드에서 다른 노드로 이동할 수 있습니다.

Pod와 클러스터의 차이점

클러스터는 기본적으로 용량을 제공하는 노드 그룹, 애플리케이션을 실행하는 Pod 그룹 및 서비스 또는 인그레스 컨트롤러와 같은 기타 구성을 포함하며, 이는 모두 Kubernetes 제어 평면에 의해 관리됩니다. 개념적으로, Pods는 Kubernetes가 애플리케이션을 실행하는 방법으로 생각할 수 있습니다.

Pod 를 사용하는 이유

컨테이너 추상화

Pod는 호스팅하는 컨테이너의 추상화 계층이므로, Kubernetes는 이러한 컨테이너를 클러스터 내에서 단일 단위로 처리하여 컨테이너 관리가 간소화됩니다.

리소스 공유

단일 Pod 내의 모든 컨테이너는 동일한 네트워크 네임스페이스를 공유합니다. 이 속성 덕분에 컨테이너들은 localhost를 통해 통신할 수 있어 네트워킹이 크게 단순화됩니다. 네트워크 공유 외에도, Pod 컨테이너는 스토리지 볼륨을 공유할 수 있어 상태 저장 애플리케이션 관리에 특히 유용합니다.

로드 밸런싱

Pods는 클러스터 전체에서 복제될 수 있으며, 로드 밸런싱 서비스는 이러한 복제본 간의 트래픽을 분산시킬 수 있습니다. Kubernetes 로드 밸런싱은 애플리케이션을 외부 네트워크 트래픽에 노출하는 간단한 방법입니다.

확장성

Kubernetes는 미리 정해진 요인에 따라 Pod 복제본의 수를 자동으로 늘리거나 줄일 수 있습니다. 이 기능을 통해 시스템은 작업량에 따라 유연하게 확장하거나 축소될 수 있습니다.

모니터링

시스템은 정기적으로 Pod의 건강 상태를 점검하고 재시작합니다. 또한, Kubernetes는 충돌하거나 건강하지 않은 Pods를 다시 스케줄링합니다. 자동 건강 모니터링은 애플리케이션의 가동 시간을 유지하는 데 중요한 요소입니다.

Pod의 LifeCycle

Pending

Pod가 시스템에 의해 수락되었지만, 하나 이상의 컨테이너가 설정되고 실행되지 않은 상태입니다.

Running

Pod가 노드에 바인딩되었고, 모든 컨테이너가 생성된 상태입니다.

Succeeded

Pod 내의 모든 컨테이너가 성공적으로 종료되어 다시 시작되지 않는 상태입니다. Pod는 더 이상 노드에 바인딩되지 않으며 리소스를 소비하지 않습니다.

Failed

Pod 내의 적어도 하나의 컨테이너가 실패로 종료된 상태입니다. Pod는 더 이상 노드에 바인딩되지 않으며 리소스를 소비하지 않습니다.

Unknown

Pod의 호스트 노드와의 통신 문제로 인해 상태를 설명할 수 없는 경우입니다. 노드가 Kubernetes 제어 평면에 상태를 보고하지 못하면 해당 노드에서 실행되던 Pods는 Unknown 상태에 들어갑니다.

Pod 업데이트 및 교체

실행 중인 Pod를 직접 업데이트하는 것은 좋은 방법이 아닙니다. 이는 Pod의 불변성(본질적으로 컨테이너의 불변성과 동일함)에 대한 가정을 깨뜨리기 때문입니다. 실제로, Kubernetes는 Pod 수준에서 이러한 불변성을 강제하며, Pod에 대한 업데이트를 거부합니다. 대신, Pod의 새로운 버전을 배포하고 트래픽을 새로운 버전으로 점진적으로 리디렉션해야 합니다. 이러한 배포가 점진적으로 이루어지며, 동일한 애플리케이션에 대해 여러 개의 Pods를 실행하는 경우 한 번에 하나의 Pod를 교체하는 방식이 Rolling Update라고 합니다. 반면에 전체 새로운 세트의 Pods를 배포하고, 트래픽을 새로운 세트로 리디렉션하며, 작동 여부를 확인한 후에만 기존 Pods를 종료하는 방식은 블루/그린 배포라고 합니다.

 

| Ref. |

https://www.techtarget.com/searchitoperations/definition/Kubernetes-Pod

https://blog.guilleojeda.com/kubernetes-pods-explained

https://phoenixnap.com/kb/kubernetes-pod

https://kubernetes.io/docs/concepts/workloads/pods/#how-pods-manage-multiple-containers