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
가 들어갈 수 있습니다.
위의 그림에서 보셨다시피 하나의 Pod
안에는 여러개의 Container
가 들어있을 수 있습니다.
하지만, 이는 Pod
내의 Container
들이 서로 다른 종류일 경우에 한해서 가능합니다.
또한, Pod
내의 Container
들은 같은 네트워크 공간을 공유하기 때문에 직접적으로 커뮤니케이션이 가능합니다.
추가적으로 저장 공간을 공유하는 것도 훨씬 간단합니다.
Multi Container Pod
에는 3가지 디자인 패턴이 있습니다.
- Sidecar Pattern
- Ambassador Pattern
- Adapter 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
의 재사용성이 증가하게 됩니다.
Ambassador
란 대사를 의미합니다.
외교 대사, 홍보 대사 등 무언가를 대표한다는 의미를 가집니다.
이 디자인 패턴에서는 Main Container
의 네트워크 연결을 전담하는 Proxy Container
를 둡니다.
이를 통해 Main Container
는 기능 자체에 집중할 수 있고, Network Container
는 네트워크 기능에 집중할 수 있게 됩니다.
어댑터 패턴은 Main Container
의 출력을 표준화시키는 패턴입니다.
Main Container
의 출력을 담당하는 Monitoring Adapter
를 두어서 Main Container
가 다른 Container
와의 연결을 신경쓰지 않을 수 있습니다.
예를 들어 위의 Pod
안의 Main Application Container
의 모니터링 정보를 수집하려고 하는 경우, CPU
, Memory
, Disk
사용량 등 특정 매트릭을 수집하려고 하거나 특정 형태로 받고자 하는 경우 Main Container
의 출력은 변환하지 않은 상태로 Adapter Container
만 수정하여 원하는 형태로 정보를 전달할 수 있습니다.
그럼 이제 Pod
를 직접 생성해 보겠습니다.
Pod
는 Multi Container
로 구현이 가능합니다.
Pod
내부에서 하나의 Container
는 하나의 책임(기능)만을 가져야 하며, Main Container
를 제외한 다른 Container
들이 어떤 목적으로 동작하는지에 따라 패턴 이름이 구분됩니다.
Sidcar Pattern :
Main Container
의 기능 확장 또는 향상
Ambassador :Main Container
의 네트워크 기능 담당
Adapter :Main Container
의 출력 변환