🔭[디자인 패턴 특집] Kubernetes 컨테이너 디자인 패턴 소개

안녕하세요 구독자님, DevOps 소식과 기술 지식을 정리해서 공유해드리는 DevOps 여행을 위한 소식지입니다.

☁️Kubernetes 컨테이너 디자인 패턴이란?

디자인 패턴은 소프트웨어를 디자인하는 과정에서 자주 발생하는 문제들에 대한 일반적인 해결책을 의미합니다. 소프트웨어 개발 중에 자주 마주치는 문제를 어떻게 해결할 수 있을지 유형별로 정리된 디자인 패턴은, 특히 객체 지향 프로그래밍을 위해 고안된 것이 일반적인데요.

전통적인 소프트웨어 개발뿐만 아니라, 컨테이너 형태로 애플리케이션을 배포할 때 사용할 수 있는 디자인 패턴도 있다는 사실, 알고 계셨나요?

그래서 오늘은, Kubernetes에서 컨테이너를 배포할 때 활용 가능한 대표적인 컨테이너 디자인 패턴 4가지를 알아보겠습니다.

🔎컨테이너 디자인 패턴 알아보기

사이드카(Sidecar) 패턴

사이드카 패턴은 기존에 존재하던 컨테이너 애플리케이션의 코드를 수정하지 않으면서도, 해당 애플리케이션의 로그를 기록하거나 모니터링과 같은 기능을 별도로 추가하고 싶을 때 사용하는데요.

Kubernetes의 Pod 내부에 기존 컨테이너 외로 필요한 기능을 수행하는 컨테이너를 추가하는 방식으로 사이드카 패턴을 구현할 수 있습니다.

예를 들어, 웹서버 애플리케이션 컨테이너가 동작 중인 Pod 내에 로그 수집기 fluentd를 별도 컨테이너로 추가한 다음, 기존에 동작하던 웹서버의 로그를 fluentd 컨테이너에서 수집하는 식이죠.

앰배서더(Ambassador) 패턴

앰배서더 패턴은 Kubernetes에 배포된 컨테이너의 네트워크 연결을 전담하는 별도의 컨테이너를 두는 패턴인데요. 이 패턴을 적용하면, 복잡한 네트워크 통신과 관련된 기능은 별도의 컨테이너로 빼내고, 기존 컨테이너는 애플리케이션이 본래 수행해야 하는 핵심 기능에만 집중할 수 있다는 장점이 있습니다.

그래서 앰배서더 패턴으로 추가한 컨테이너를 프록시(Proxy) 컨테이너라고도 하는데요. 외부 환경과 내부 서버 사이에서 통신이 오고갈 수 있는 가교 역할을 하는 프록시 서버와 비슷하게 동작해서 그렇습니다.

Kubernetes 환경에서 앰배서더 패턴 구현이 가능한 이유는, 동일한 Pod 내에서 동작하는 컨테이너는 서로 Localhost로 통신할 수 있기 때문입니다.

HTTP 웹서버로 자주 사용되는 Nginx는 앰배서더 패턴으로 추가하하기 좋은 애플리케이션 중 하나입니다.

어댑터(Adapter) 패턴

외부와의 연결을 별도의 컨테이너에서 전담하여 간소화시키는 앰배서더 패턴과는 달리, 어댑터 패턴은 기존 컨테이너가 외부로 보내는 결과물을 통일화하는 데에 활용됩니다.

특히 어댑터 패턴은 모니터링을 위해 외부 서비스와 연동할 때 외부 서비스에서 요구하는 양식이나 인터페이스를 맞추기 위해 사용되는데요. 기존의 컨테이너는 그대로 두면서, 컨테이너에서 나오는 결과물을 외부 규격에 맞추는 별도의 컨테이너를 동일한 Pod 내에 두는 방식으로 어댑터 패턴을 구현할 수 있습니다.

만약 컨테이너로 동작 중인 로그 데이터 저장소 Elasticsearch의 상태와 관련된 로그를 외부 모니터링 툴 Prometheus 서비스에 저장해야 한다면, 동일한 Pod에 별도의 Prometheus Exporter 컨테이너를 추가하여 Prometheus 규격에 맞는 Elasticsearch의 상태 로그를 내보낼 수 있는 것이죠.

초기화 컨테이너(Init Container) 패턴

초기화 컨테이너 패턴은 기존 컨테이너가 실행되기 전에 필요한 작업을 별도의 컨테이너에서 수행하는 디자인 패턴입니다.

Kubernetes에선 Pod의 스펙을 정의하는 Manifest에서 'initContainers'라는 필드로 초기화 컨테이너 패턴을 정식으로 지원하고 있는데요.

예를 들어 기존 컨테이너의 Elasticsearch 애플리케이션이 동작하려면 '/usr/share' 내 폴더의 소유권을 다른 사용자로 바꿔야 하는 경우, 별도의 초기화 컨테이너에서 해당 작업을 수행한 다음 Elasticsearch 컨테이너를 실행할 수 있는 겁니다.