쿠버네티스 패턴 중 하나인 사이드카 패턴에 대해 학습합니다.
Intro
사이드카(Sidecar) 컨테이너는 기존 컨테이너의 변경 없이 기능을 확장시키고 향상시킨다.
사이드카 패턴은 단일 목적 컨테이너들이 서로 긴밀하게 협력할 수 있게 해주는 기본 컨테이너 패턴 중 하나다.
여기서 사이드카 패턴을 다루고 이후에 이 응용버전인 Adapter 패턴과 Ambassador 패턴에 대해 다루겠다.
문제
컨테이너는 개발자와 시스템 관리자가 통합된 방식으로 애플리케이션을 작성, 배포 및 실행하는데 오늘날 가장 많이 사용하는 패키징 기술이다.
컨테이너는 별도의 런타임, 릴리스 주기, API, 컨테이너를 소유한 팀 등으로 기능 단위를 자연스럽게 구분해 경계를 만든다.
컨테이너는 단일 리눅스 프로세스처럼 동작하고 쉽게 교체할 수 있으며 재사용이 가능하다.
요즘 웹 서버를 만들때도 웹 서버용 컨테이너를 만들 필요 없이 기존 서버를 재활용 할 수 있다. 이런 접근 방식을 통해 개발자는 시간 절약이 가능하고 더 적은 수의 컨테이너를 유지 관리 할 수 있다.
그러나 단일 목적의 재사용 가능한 컨테이너를 활용하려면 컨테이너의 기능을 확장하는 방법과 컨테이너 간에 협업할 수 있는 수단이 필요하다.
사이드카 패턴은 컨테이너가 기존에 존재하는 다른 컨테이너의 기능을 향상시키는 방법으로 협업을 가능하게 한다.
해결책
파드를 통해 사이드카를 설명해 보겠다.
파드에 대해선 알고있겠지만 엄밀히 말하면 파드는 런타임에서 컨테이너다.
하지만 파드는 다른 모든 컨테이너보다 가장 먼지 일시 정지된 프로세스(pause) 컨테이너를 시작하며 애플리케이션 컨테이너가 파드의 수명주기 동안 상호작용하는 데 사용하는 모든 리눅스 네임 스페이스를 유지하는 것 외에는 아무 작업을 하지 않는다.
이것보다 더 재밌는건 파드 추상화를 알아보면 된다.
파드는 가장 끼본적인 요소로 배포 단위로서 파드는 파드 자신에게 속한 컨테이너들에게 런타임 제약을 걸 수 있다.
예를 들면 모든 컨테이너는 동일한 노드에 배치되고 동일한 파드 수명주기를 공유하게 할 수 있다.
또한 파드는 컨테이너들이 볼륨을 공유하고 로컬 네트워크 또는 호스트 IPC를 통해 서로 통신할 수 있게 해준다.
이러한 이유로 컨테이너 그룹을 파드로 만든다.
사이드카 패턴은 컨테이너의 기능을 확장시키고 향상시키기 위해 컨테이너를 파드에 넣는 것과 유사하다.
이 패턴을 설명하기 위해 예제로 HTTP 서버와 깃 동기화 프로그램을 사용하겠다.
HTTP 서버 컨테이너는 HTTP를 통해서 파일을 제공하는데만 초점을 두고 파일이 어디서 어떻게 오는지는 관심없다.
마찬가지로 깃 동기화 컨테이너의 유일 목표는 깃 서버에서 로컬 파일 시스템으로 데이터를 동기화 하는데만 관심이 있다.
동기화된 파일이 어떻게 되는지는 신경쓰지 않는다.
다음 예제는 HTTP 서버와 깃 동기화 컨테이너가 볼륨을 이용해 파일을 교환하는 파드 정의다.
apiVersion: v1
kind: Pod
metadata:
name: web-app
spec:
containers:
- name: app
image: docker.io/centos/httpd // HTTP로 파일을 제공하는 기본 애플맄케이션 컨테이너
ports:
- containerPort: 80
volumeMounts:
- mountPath: /var/www/html // 사이드카와 기본 애플리케이션 컨테이너 간에 데이터를 교환하기 위해 공유된 장소
name: git
- name: poll
image: axeclbr/git // 깃 서버로부터 데이터를 가져오고 병렬로 실행하는 사이드카 컨테이너
volumeMounts:
- mountPath: /var/lib/data // 사이드카와 기본 애플리케이션 컨테이너 간에 데이터를 교환하기 위해 공유된 장소
name: git
env:
- name: GIT_REPO
value: https://github.com/mdn/beginner-html-site-scripted
command:
- "sh"
- "-c"
- "git clone ${GIT_REPO} . && watch -n 600 git pull"
workingDir: /var/lib/data
volumes:
- emptyDir: {}
name: git 이 에제는 깃 동기화 프로그램이 콘텐츠를 제공하는 HTTP 서버의 동작을 향상 시킨다. 사이드카 패턴을 이용해서.
사이드카 패턴에서는 기본 컨테이너가 있고 공동 작업을 향상 시키는 보조 컨테이너가 있다.
일반적으로 기본 컨테이너는 컨테이너 목록에 나열된 첫 번째 컨테이너가 기본 컨테이너다.
사이드카 패턴을 통해 컨테이너는 런타임에 협업이 가능해지며 그와 동시에 두 컨테이너의 관심을 분리시킴으로써 서로 다른 프로그래밍 언어를 사용하거나 별도의 컨테이너를 통해 개발할 수 있다.
이를 통해 기존 컨테이너의 치환성과 재사용성을 높여주고 보조 컨테이너는 또 다른 설정을 적용해 여러 컨테이너와 협업하기 위해 재사용될 수 있다.
정리
컨테이너 이미지는 클래스와 유사하고 컨테이너는 객체 지향 프로그래밍에서 객체와 유사하다.
이 비유를 적용해보자면 컨테이너의 기능을 향상 시키기 위해 컨테이너를 확장하는 것은 OOP의 상속과 유사하고 파드에서 공동 작업하는 여러 컨테이너는 OOP의 Composition과 유사하다.
이 두가지 방법 모두 코드를 재사용 하는게 가능하다. 하지만 상속에는 컨테이너간의 밀접한 결합이 필요하고 컴포지션 관계는 컨테이너를 결합하지 않고 파드를 정의할 때 적용되므로 교체할 수 있으므로 유연성이 뛰어나다.
사이드카 패턴에서 컨테이너는 크기가 작으며 최소한의 자원을 사용하도록 해야하고 별도의 프로세스가 더 나은지 아니면 기본 컨테이너에 병합하는게 나은지 각자 판단해야한다.
