1. 멀티 컨테이너 Pod
기본적으로 하나의 Pod 안에서는 모든 컨테이너가 같은 네트워크 안에서 동작하므로,
같은 IP 주소와 포트를 공유하게 된다. 따라서 같은 포트를 사용하는 컨테이너들을 묶어서 하나의 파드로 배포해서는 안된다. 또한 하나의 파드 안에 완전히 별개의 성격을 가진 다른 프로세스들을 묶어 배포하는 것도 권장되지 않는다. 이는 전체 서비스를 기능 단위로 분산하고 Pod를 최소의 배포 단위로 구성하는 쿠버네티스의 설계 사상에 맞지 않는 방식이다.
따라서, 멀티 컨테이너 Pod는 메인 프로세스를 네트워크 또는 스토리지의 밀접한 공유가
필요한 다른 컨테이너와 함께 운영하고자 할 때에 고려하는 것이 바람직하다.
1.1. 멀티 컨테이너 yaml
| apiVersion: v1 kind: Pod metadata: name: two-containers spec: restartPolicy: Never volumes: - name: shared-data emptyDir: {} containers: - name: nginx-container image: nginx volumeMounts: - name: shared-data mountPath: /usr/share/nginx/html - name: debian-container image: debian volumeMounts: - name: shared-data mountPath: /pod-data command: ["/bin/sh"] args: ["-c", "echo Hello from the debian container > /pod-data/index.html"] |
1.2. 멀티 컨테이너 파드의 대표적인 디자인 패턴
1.2.1. Sidecar 컨테이너
Sidecar 컨테이너는 기존 컨테이너의 변경 없이 기능을 확장시키고 향상
시킨다. 사이드카 패턴은 단일 목적 컨테이너들이 서로 긴밀하게 협력할 수 있게 해주는 기본 컨테이너 패턴 중 하나다.
1.2.2. Adapter 컨테이너
Adapter 패턴은 포드 외부로 노출되는 정보를 표준화 하는 역할을 한다. 주로 포드의 모니터링 지표를 어댑터 컨테이너를 통해서 표준화된 형식으로 노출 시키고 외부의 모니터링 시스템에서 데이터를 주기적으로 가져가서 모니터링 한다.
1.2.3. Ambassador 컨테이너
Ambassador 패턴은 포드내에 프록시 역할을 하는 컨테이너를 추가하는
패턴이다. 포드내에서 외부 서버에 접근 할때 내부의 프록시에 접근 하도록
설정하고 실제로 외부로의 연결은 프록시에서 알아서 처리 하는 방식이다.
