파드 란? , 다중 컨테이너가 동작하는 파드

파드란?

• nginx 컨테이너 단독 구성 파일 예제
• 다중 컨테이너가 동작하는 파드
• 사이드카 패턴
• 앰버서더 패턴
• 파드 초기화 컨테이너

 

 

---

파드 란?

쿠버네티스에서 프로그램을 동작시키는 기본 단위

관련성 있는 하나 이상의 컨테이너를 합쳐놓은 오브젝트

 

---

 

nginx 컨테이너 단독 구성 파일 예제

# 02_nginx_k8s.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx-app
spec:
  containers:
  - name: nginx-container
    image: nginx
    ports:
    - containerPort: 80

 

• apiVersion: v1은 이 매니페스트 파일에서 정의된 오브젝트가 준수해야 하는 사양의 버전을 설정. 자세한 설명은 이전 포스트 참고
• kind: pod는 이 구성 파일이 파드라는 종류의 오브젝트라는 것을 의미
• metadata: 파드의 메타데이터를 정의
  • name: 파드 이름을 설정하는 것. ("nginx-pod" 라는 파드 이름으로 선언했음)
  • app: 파드에 레이블을 설정. 키-값 형식으로 app이라는 키에 대해서 nginx-app라는 값을 설정
    • 레이블을 사용하는 이유는 디플로이먼트나 서비스 같은 다양한 리소스를 식별하기 위해
    • 사용자에게는 중요하지만, 코어 시스템에 직접적인 의미는 없음

 

• spec: 파드에 생성할 컨테이너를 정의
  • name: 컨테이너의 이름 ("nginx-container" 라는 컨테이너 이름을 선언했음)
  • image: 컨테이너 생성 시 어떤 이미지를 사용할지 설정 (nginx 컨테이너 이미지를 태그 없이 설정했음 [default: latest] )
  • containerPort: 컨테이너를 공개할 포트를 설정 (80번 포트를 그대로 80번으로 공개했음)

---

 

다중 컨테이너가 동작하는 파드

쿠버네티스 클러스터 내부의 파드는 주로 2가지 방법으로 사용

 

단일 컨테이너만 동작하는 파드

다중 컨테이너가 동작하는 파드

 

위에서는 단일 컨테이너로 동작하는 파드를 살펴보았다.

 

파드 하나에 포함되는 컨테이너는 아래와 같은 특징이 있다.

• 로컬 호스트로 서로 통신 가능
• 스토리지(볼륨) 공유 가능
• 컨테이너들은 함께 동작과 정지가 됌

 

어떤 컨테이너가 다른 컨테이너와 네트워크나 스토리지를 공유하여 밀접한 처리해야하는 작업이 있다면 다중 컨테이너가 동작하는 파드가 필요한 상황이다.

 

다중 컨테이너가 동작하는 파드의 대표적인 2가지 패턴이 있다.

 

 

사이드카(sidecar) 패턴 

사이드카 패턴은 원래 사용하려고 했던 기본컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 패턴

메인 처리하는 컨테이너에서 보조 기능을 분리할 수 있어 메인 처리를 단순화하여 구현할 수 있음.

또, 보조 기능을 다른 컨테이너로 분리하면 사이드카 부분의 재사용이 용이

cf) 메인 처리를 실행하는 컨테이너가 출력한 로그를 다른 컨테이너가 읽어 들여 로그 수집 서버나 메트릭 수집 서버에 전송

 

 

앰버서더(ambassador) 패턴

 

앰버서더 패턴은 포드내에 프록시 역할을 하는 컨테이너를 추가하는 패턴

포드내에서 외부 서버에 접근할때 내부의 프록시에 접근하도록 설정하고 실제로 외부로의 연결은 프록시에서 알아서 처리하는 방식

 

cf) 메인 처리를 실행하는 컨테이너가 외부 시스템에 접속할 경우, 또 다른 컨테이너가 프록시로 되어 목적지를 할당하거나 요청이 제대로 처리되지 않았을 때 재시도 수행

 

---

 

파드 초기화 컨테이너

메인 컨테이너를 동작시키기 위해 초기화 처리를 하는 것이 주된 목적인 특수 컨테이너

파드의 메인 컨테이너를 생성하기 전에 초기화 컨테이너를 실행하도록 설정할 수 있음

초기화 컨테이너는 여러 개 설정 가능

초기화 컨테이너에 의한 처리는 메인 컨테이너 안에 포함시킬 수 있지만 분리하여 처리하면 다음과 같은 장점을 얻을 수 있음.

• 애플리케이션 자체에 필요 없는 도구를 사용하여 초기화 처리 가능.
• 메인 컨테이너의 보안성을 낮추는 도구를 초기화 컨테이너에 분리시키면 안전하게 초기화 처리 가능
• 초기화 처리와 애플리케이션을 서로 독립시켜 빌드, 배포 가능
• 초기화 컨테이너는 앱 컨테이너와 다른 파일 시스템 뷰를 가지도록 Linux 네임스페이스를 사용.
  • 초기화 컨테이너에는 앱 컨테이너가 가질 수 없는 시크릿에 접근 권한 가능.
  • 초기화 처리에만 필요하고 애플리케이션 처리에는 필요 없는 비밀 정보를 메인 컨테이너에서 제외 가능
• 초기화 컨테이너가 모두 종료될 때까지 메인 컨테이너가 시작되지 않으므로, 메인 컨테이너를 생성시키는 어떤 조건을 설정하고 그 조건이 성립될 때까지 메인 컨테이너 생성 차단 가능