Pod
Kubernetes에서 사용되는 많은 용어들은 바다와 관계가 깊습니다.
Kubernetes는 키잡이라는 그리스어를 따왔으며, Docker의 경우 Container를 옮기는 등의 일을 하는 항만 노동자를 의미합니다.
Pod의 경우 사전상 의미는 (물개·고래 등의) 작은 떼이며 Kubernetes에서 사용하는 가장 작은 단위로서 적합한 이름인 것 같습니다.
Kubernetes에서 애플리케이션은 Worker Node에 Container 형태로 배포되어 실행됩니다.
하지만, Kubernetes에서 Worker Node에 애플리케이션을 배포할 때, Container를 직접 배포하는 것은 아닙니다.
Kubernetes는 Container를 배포할 때 Pod라는 Kubernetes 오브젝트를 이용해 Container를 캡슐처럼 감싸서 배포하게 됩니다.
즉 애플리케이션은 Pod안에 Container가 들어있는 형태로 배포되며, 이 Pod는 애플리케이션의 한 인스턴스라고 볼 수 있습니다.
그림으로 보면 아래와 같습니다.
Kubernetes Cluster의 Worker Node안에 Container가 배포된 것을 확인할 수 있는데, 이 Container는 Pod이라는 오브젝트에 감싸져있으며, Pod에는 여러개의 Container가 들어갈 수 있습니다.
Multi Container Pods
위의 그림에서 보셨다시피 하나의 Pod안에는 여러개의 Container가 들어있을 수 있습니다.
하지만, 이는 Pod내의 Container들이 서로 다른 종류일 경우에 한해서 가능합니다.
또한, Pod내의 Container들은 같은 네트워크 공간을 공유하기 때문에 직접적으로 커뮤니케이션이 가능합니다.
추가적으로 저장 공간을 공유하는 것도 훨씬 간단합니다.
Multi Container Pod에는 3가지 디자인 패턴이 있습니다.
- Sidecar Pattern
- Ambassador Pattern
- Adapter Pattern
1. Sidecar Pattern
Sidecar Pattern 패턴을 사용하려고 할 때 하나의 대 전제가 존재합니다.
"하나의 컨테이너는 하나의 책임만 가져야 한다."
예를 들어, Web Server와 Log Collector가 하나의 Container에 들어있다고 생각해보면 하나의 컨테이너는 Web Service와 Log Collection이라는 두개의 책임을 가지게 됩니다.
이럴 경우, 둘 중 하나의 서비스를 수정해야하는 일이 발생하면 두 서비스간의 종속성들을 고려해야 하므로 난이도가 높아지고 효율이 떨어집니다.
또한, 직접적인 관련이 없더라도 문제가 발생한 지점을 추적하는데 어려움이 발생할 것입니다.
이 때문에 서로 다른 역할을 하는 서비스는 각각의 Container로 분리하는것이 좋으며, 이 때 사용하는것이 Sidecar Pattern입니다.
그림으로 보면 위와 같습니다.
하나의 Pod안에 Web Server Container와 Log Saving Sidecar Container가 있습니다.
두 Container는 하나의 Pod안에 존재하기 때문에 손쉽게 Filesystem을 공유합니다.
해당 Pod의 핵심 목표는 Web Service를 제공하는 것이므로 Web Server Container가 해당 Pod의 Main Container가 됩니다.
Log Saving Sidecar Container는 Main Container에 Log Collection이라는 기능을 추가하여 Main Container의 기능을 확장, 향상 또는 개선 시키는 역할을 해주는 Container입니다.
이러한 역할을 수행하는 Container를 Sidecar Container라고 하며, Sidecar Contaienr를 사용하는 디자인 패턴을 Sidecar Pattern이라고 합니다.
Sidecar Pattern을 사용하면 Main Container를 수정해도 Sidecar Contaier는 독립적으로 동작하기 때문에 수정하지 않아도 됩니다.
이를 통해 Contaienr의 재사용성이 증가하게 됩니다.
2. Ambassador Pattern
Ambassador란 대사를 의미합니다.
외교 대사, 홍보 대사 등 무언가를 대표한다는 의미를 가집니다.
이 디자인 패턴에서는 Main Container의 네트워크 연결을 전담하는 Proxy Container를 둡니다.
이를 통해 Main Container는 기능 자체에 집중할 수 있고, Network Container는 네트워크 기능에 집중할 수 있게 됩니다.
3. Adapter Pattern
어댑터 패턴은 Main Container의 출력을 표준화시키는 패턴입니다.
Main Container의 출력을 담당하는 Monitoring Adapter를 두어서 Main Container가 다른 Container와의 연결을 신경쓰지 않을 수 있습니다.
예를 들어 위의 Pod안의 Main Application Container의 모니터링 정보를 수집하려고 하는 경우, CPU, Memory, Disk 사용량 등 특정 매트릭을 수집하려고 하거나 특정 형태로 받고자 하는 경우 Main Container의 출력은 변환하지 않은 상태로 Adapter Container만 수정하여 원하는 형태로 정보를 전달할 수 있습니다.
Pod 생성 및 삭제
그럼 이제 Pod를 직접 생성해 보겠습니다.
정리
Pod는 Multi Container로 구현이 가능합니다.
Pod 내부에서 하나의 Container는 하나의 책임(기능)만을 가져야 하며, Main Container를 제외한 다른 Container들이 어떤 목적으로 동작하는지에 따라 패턴 이름이 구분됩니다.
Sidcar Pattern :
Main Container의 기능 확장 또는 향상
Ambassador :Main Container의 네트워크 기능 담당
Adapter :Main Container의 출력 변환
