Multi Container Pod

파드와 컨테이너 통신

파드는 하나 이상의 컨테이너가 공유할 수 있는 네트워크 및 파일 시스템을 제공하는 가상 환경으로, 한 노드 상에서 동작하는 단위이다.
컨테이너는 별도의 환경 변수와 자신만의 프로세스를 가지며 서로 다른 기술 스택으로 구성된 별개 이미지를 사용할 수 있는 독립된 단위이다.
윈도우 컨테이너와 리눅스 컨테이너는 같은 노드에서 동작할 수 없다.
같은 파드 내에 있는 컨테이너들은 같은 IP 주소를 가진다. 따라서 localhost 통신이 가능하다.
파드에서 제공하는 볼륨을 마운트하여 공유하면 컨테이너끼리 정보를 교환할 수 있다.

아래는 디플로이먼트에 멀티컨테이너 파드를 정의한 예제이다. 두 컨테이너를 배열로 정의하였다.
- 두 컨테이너 사이에 하나의 볼륨을 공유하여 마운트할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sleep
  labels:
    kiamol: ch07
spec:
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      containers:
        - name: sleep
          image: kiamol/ch03-sleep   
          volumeMounts:
            - name: data
              mountPath: /data-rw    
        - name: file-reader
          image: kiamol/ch03-sleep
          volumeMounts:
            - name: data
              mountPath: /data-ro
              readOnly: true
      volumes:
        - name: data
          emptyDir: {}

멀티 컨테이너 파드의 로그 출력을 위해서는 특정 컨테이너를 지정해야 한다.

kubectl logs -l <파드 레이블 조건> -c <컨테이너 이름>

초기화 컨테이너

멀티 컨테이너 파드의 경우 모든 컨테이너 상태가 Ready가 되어야 파드도 준비된 상태가 된다.
초기화 컨테이너란 애플리케이션 컨테이너보다 먼저 실행되어 애플리케이션 실행 준비를 돕는 추가적인 컨테이너이다.
추가 컨테이너(사이드카)가 애플리케이션 컨테이너(오토바이)를 지원하는 사이드카 컨테이너와는 다르다.
초기화 컨테이너는 파드 안에 여러 개 정의할 수 있으며 파드 내에 정의된 순서에 따라 실행된다.
모든 초기화 컨테이너가 목표를 달성해야 애플리케이션 컨테이너나 사이드카 컨테이너를 실행한다.
초기화 컨테이너의 주요 역할 중 하나는 애플리케이션 컨테이너에서 필요한 환경을 준비하는 것이다.
initContainers에 초기화 컨테이너를 정의할 수 있다.
- 아래 정의된 초기화 컨테이너에서는 컨피그맵 볼륨 마운트에서 설정을 읽은 후 환경 변수 설정값을 병합해 emptyDir 볼륨 마운트에 파일로 기록한다.
- 컨테이너는 환경 변수를 공유하지 못하므로 초기화 컨테이너에 지정된 설정 값을 emptyDir 볼륨 마운트에 기록하고, emptyDir 볼륨을 config 디렉토리로 마운트하여 애플리케이션 컨테이너에서 설정 값을 얻어오도록 한다.
- 만약 컨테이너 이미지에 이미 특정 디렉토리가 포함되어 있고 이를 새로운 볼륨 마운트 공간으로 사용한다면 덮어쓰여지기 때문에 조심해야 한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: timecheck
  labels:
    kiamol: ch07
spec:
  selector:
    matchLabels:
      app: timecheck
  template:
    metadata:
      labels:
        app: timecheck
        version: v2
    spec:
      initContainers:
        - name: init-config
          image: kiamol/ch03-sleep
          command: ['sh', '-c', "cat /config-in/appsettings.json | jq --arg APP_ENV \"$APP_ENVIRONMENT\" '.Application.Environment=$APP_ENV' > /config-out/appsettings.json"]
          env:
          - name: APP_ENVIRONMENT
            value: TEST         
          volumeMounts:
            - name: config-map
              mountPath: /config-in
            - name: config-dir
              mountPath: /config-out
      containers:
        - name: timecheck
          image: kiamol/ch07-timecheck
          volumeMounts:
            - name: config-dir
              mountPath: /config
              readOnly: true
      volumes:
        - name: config-map
          configMap:
            name: timecheck-config
        - name: config-dir
          emptyDir: {}

어댑터 컨테이너

애플리케이션과 컨테이너 플랫폼 사이를 중재하는 어댑터 역할을 맡는 사이드카 컨테이너를 의미한다.
도커나 쿠버네티스는 표준 출력 스트림으로 출력된 로그를 컨테이너 로그로 수집한다. 파일에 직접 로그를 남기거나 컨테이너 로그가 수집될 수 없는 채널을 이용해 로그를 남긴다면 파드 로그를 통해 로그를 확인할 수 없다.
어댑터 컨테이너를 이용하면 아래와 같이 로그가 출력되는 볼륨을 마운트한 후 해당 로그 파일을 tail -f 명령을 이용해 내용이 추가될 때 마다 출력하도록 해 쿠버네티스 상으로 로그 수집이 가능하도록 할 수 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: timecheck
  labels:
    kiamol: ch07
spec:
  selector:
    matchLabels:
      app: timecheck
  template:
    metadata:
      labels:
        app: timecheck
        version: v3
    spec:
      initContainers:
        # ...
      containers:
        - name: timecheck
          image: kiamol/ch07-timecheck
          volumeMounts:
            - name: config-dir
              mountPath: /config
              readOnly: true
            - name: logs-dir
              mountPath: /logs
        - name: logger
          image: kiamol/ch03-sleep
          command: ['sh', '-c', 'tail -f /logs-ro/timecheck.log'] 
          volumeMounts:
            - name: logs-dir
              mountPath: /logs-ro
              readOnly: true
      volumes:
        - name: config-map
          configMap:
            name: timecheck-config
        - name: config-dir
          emptyDir: {}
        - name: logs-dir
          emptyDir: {}

이외에도 커스터마이징된 정보를 수집하거나 헬스 체크, 성능 지표를 수집하는 이미지를 사이드카 컨테이너에서 사용할 수 있다.

- name: healthz
  image: kiamol/ch03-sleep  
  command: ['sh', '-c', "while true; do echo -e 'HTTP/1.1 200 OK\nContent-Type: application/json\nContent-Length: 17\n\n{\"status\": \"OK\"}' | nc -l -p 8080; done"]
  ports:
    - containerPort: 8080
      name: http

애플리케이션 컨테이너에서 외부로 향하는 트래픽을 관리하고 싶다면 어댑터 컨테이너로 프록시 컨테이너를 둘 수 있다.
어댑터 역할을 하는 사이드카 컨테이너는 오버헤드로 작용한다. 자원을 더 소모하고 파드 업데이트에 걸리는 시간도 길어질 수 있다.
아래 그림과 같이 old 파드에서는 애플리케이션 컨테이너의 한계로 각종 사이드카 컨테이너를 두지만, new 파드에서는 애플리케이션 컨테이너 자체에서 기능을 제공하여 오버헤드를 줄일 수 있다. 단, 두 방식을 외부에서 봤을 때 동작은 완전히 똑같다.

앰배서더 컨테이너

앰배서더 컨테이너에서는 애플리케이션과 외부 통신을 제어하고 단순화하여 네트워크의 제어권을 가지게 된다. 이 때 성능 향상 혹은 신뢰성, 보안 강화하는 내용 등 복잡한 로직이 포함될 수 있다.
애플리케이션이 네트워크 요청을 보내면 앰배서더 컨테이너가 받아 처리할 수 있다.
데이터베이스 앰배서더 컨테이너를 둘 경우 update 쿼리는 마스터 DB에, select 쿼리는 복제 DB에 보내도록 할 수 있다.
프록시 컨테이너를 활용하면 서비스 디스커버리, 로드밸런싱, 연결 재시도, 비보안 채널에 대한 암호화 등을 할 수 있게 된다.
아래와 같이 프록시 앰배서더 컨테이너를 정의하면 모든 트래픽이 앰배서더 컨테이너를 거치며, 네트워크 요청을 URL 매핑에 따라 라우팅한다. 각 애플리케이션 컨테이너는 호출할 서비스의 URL을 알 필요 없이 프록시의 한 주소로만 요청을 보내면 된다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: numbers-web
  labels:
    kiamol: ch07
spec:
  selector:
    matchLabels:
      app: numbers-web
  template:
    metadata:
      labels:
        app: numbers-web
    spec:
      containers:
        - name: web
          image: kiamol/ch03-numbers-web 
          env:
          - name: http_proxy
            value: http://localhost:1080
          - name: RngApi__Url
            value: http://localhost/api
        - name: proxy
          image: kiamol/ch07-simple-proxy # 요청된 주소를 실제 주소로 매핑하고 로그를 남기는 프로그램
          env:
          - name: Proxy__Port
            value: "1080"
          - name: Proxy__Request__UriMap__Source
            value: http://localhost/api
          - name: Proxy__Request__UriMap__Target
            value: http://numbers-api/sixeyed/kiamol/master/ch03/numbers/rng

파드 환경 이해하기

파드는 컴퓨팅의 기본 단위이다. 내부에 존재하는 모든 컨테이너가 READY여야 파드도 READY 상태가 된다.
초기화 컨테이너 실행에 실패하면 애플리케이션 컨테이너도 업데이트되지 않는다. 이 때 새로 생성된 파드는 READY 상태에 들어가지 못하지만, 디플로이먼트는 기존 레플리카셋을 사용하므로 사용 가능 상태이니 주의해야 한다.
다음은 파드 및 컨테이너의 재시작 조건이다.
- 초기화 컨테이너를 가진 파드가 대체될 때, 새 파드는 초기화 컨테이너를 모두 실행하므로 초기화 로직은 반복적으로 실행 가능해야 한다.
- 초기화 컨테이너 이미지가 변경되면 파드가 재시작된다. 초기화 컨테이너가 다시 실행되며 애플리케이션 컨테이너도 교체된다.
- 애플리케이션 컨테이너 이미지가 변경되면 초기화 컨테이너는 재시작하지 않고 애플리케이션 컨테이너만 대체된다.
- 애플리케이션 컨테이너가 종료되면 애플리케이션 컨테이너를 재생성한다.
프로세스 간 통신이나 애플리케이션 프로세스의 지표 수집을 위해 사이드카 컨테이너가 애플리케이션 프로세스에 접근해야 할 경우 shareProcessNamespace: true 설정을 추가하면 접근이 가능하다.

PreviousController NextStatefulSet & Job

Last updated 7 months ago