개요
큰 단일 애플리케이션을 마이크로서비스라는 하위 요소로 분리하는 개념은 독립적이고, 작고, 다시 사용할 수 있는 코드 집합을 개발하고 배포하는 것을 가능하게 한다. 즉, 전체 애플리케이션을 수정하는 대신 필요에 따라 각 서비스를 수정하고, 축소/확대하는 것이 가능하다.
다중 컨테이너 포드
온전한 서비스를 동작시키기 위해 여러 기능이 함께 동작해야 하는 경우, 다중 컨테이너 포드를 이용할 수 있다. 포드 내의 컨테이너는 수명주기가 같고, 같은 네트워크에 존재하기 때문에 서로를 localhost로 참조할 수 있으며, 같은 볼륨에 접근할 수 있기 때문이다.
포드 정의 파일의 spec 섹션에서 containers 섹션이 배열인 이유가 바로, 멀티컨테이너 포드를 사용할 수 있게끔 하기 위해서다.
apiVersion: v1
kind: Pod
metadata:
name: simple-webapp
labels:
name: simple-webapp
spec:
containers:
- name: simple-webapp
image: simple-webapp
ports:
- containerPort: 8080
- name: log-agent
image: log-agent
다중 컨테이너 포드 디자인 패턴
1. Sidecar
하나의 컨테이너는 하나의 책임만 가져야 한다.
컨테이너의 기능을 추가하고자 할 때에 컨테이너 내에 기능을 추가하는 것이 아니라, 별개의 컨테이너를 추가한다.
예로 들어 웹 서버와 로그 수집기가 함께 동작하는 경우, 두 개의 요소는 서로 다른 역할을 하고 있으므로 별개의 컨테이너로 동작할 수 있도록 해야 한다.
2. Adaptor
Adaptor 컨테이너는 포드 외부로 노출되는 정보를 표준화하는 역할이다.
위의 로그 관련해서 다시 예로 들면, 여러 개의 애플리케이션이 생성하는 로그 패턴은 서로 다를 수 있다. 이때 adaptor 컨테이너를 중앙 로그 서버에 전송하기 전에 배치하여, 로그의 형식을 공통 형식으로 변환한다.
3. Ambassader
포드 내에 프록시 역할을 하는 컨테이너를 추가한다.
포드 내에서 외부에 접근할 때 포드 내의 프록시에 접근하도록 설정하고 실제로 연결은 프록시에서 처리하도록 한다.
참고 문서
https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html