init-container와 empty-dir

 

상황

 

1. main(envoy)는 시작할 때 main(envoy) 내의 유효한 위치에 config파일이 있어야 원하는 구성 대로 만들어지고,

이후 인증서와 grpc용 proto 파일 등도 유효한 위치에 있어야 정상 통신가능하다.

 

2. 해당 인증서는 만료일이 있어서 일정 주기마다 원격 CA서버로 부터 인증서를 받아 교체해 줘야 한다.

 

3. 원래 테스트할 땐 main(envoy)는 server file-system dir에서 바로 마운트 해서 해당 파일들을 바로 꽂아줬었다.

 

4.하지만 이 아키텍쳐 대로 prod 환경이 되면 고객에게 구축해 주기도 복잡하고, 고객도 인증서 넣었다 뺐다 복잡해한다.

무엇 보다 해당 아키택쳐(config파일의 존재, 인증서가 어떻게 main에 들어가는지)가 고객에게 노출된다.

 

 

 

테스트

 

1. init-container가 기동하면 원격 CA서버에 요청하여 main(envoy)가 시작하기 전에 config와 인증서, proto 파일을 다운받는다.

 

2. empty dir를 통해 main(envoy)의 유효한 위치에 해당 파일을 위치시킨다.

 

3. envoy는 행복하게 작동한다.

 

 

 

아래와 같이 간단한 구성으로 작성했다.
CA 서버가 아직 구성이 안되었으니 간이로 file-system dir(/data/envoy1)에서 마운트 해서 내용물을 가져오는 것으로 때운다.

 

원래는 main 컨테이너 내에서도 다른 디렉토리로 받아서 cp로 유효한 위치까지 내용물을 옮기려고 했는데,

config가 먼저 유효 위치에 존재하지 않으면 main(envoy)는 디폴트 config를 떡 하고 생성해서 그걸로 올라간다;;;

config를 적용하려면 재시작해야하기 때문에 이럼 안돼서

그냥 처음부터 유효 위치로 내용물을 꽂아넣기로 했다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: envoy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: envoy
  template:
    metadata:
      labels:
        app: envoy
    spec:
      #메인컨테이너
      containers:
      - name: envoy
        image: envoyproxy/envoy:v1.19.0
        ports:
        - containerPort: 8080 # Envoy가 수신 대기할 포트
        volumeMounts:
        - name: init-emp
          mountPath: /etc/envoy
     #이닛컨테이너
      initContainers:
      - name: init-envoy
        image: busybox
        command: ["/bin/sh"]
        args: ["-c", "cp /etc/envoy1/* /etc/envoy2/"]
        volumeMounts:
        - name: envoy-config
          mountPath: /etc/envoy1
        - name: init-emp
          mountPath: /etc/envoy2
      volumes:
        - name: envoy-config
          hostPath:
            path: /data/envoy1
            type: DirectoryOrCreate
        - name: init-emp
          emptyDir: {}
          #configMap:
          #name: envoy-config
      tolerations:
      - key: node-role.kubernetes.io/control-plane
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        effect: NoSchedule

 

 

 

 

 

empty dir 사용에 대한 타당성 고찰

 

pod와 라이프사이클이 같은 볼륨인 만큼 의도대로 작동할까 걱정이 있었다. (재기동시 내용물 증발)

내용물에 인증서가 들어있기 때문에 정전 등 재해에 pod재기동이 일어나서 볼륨이 날아가면 main(envoy)가 작동이 안된다.

pod 재기동 말고는 empty dir 자체가 날아갈 다른 가능성이 없을까?

생각해보니 container중 어느 하나라도 어긋나면 pod 자체가 안올라간다. pod 내부의 구성은 일단 보장이 된다.

그러면 문제 없어 보인다.

 

 

pod 재기동을 가정하고 테스트 결과 아래와 같이 기존 envoy가 init부터 다시 잘 올라온다.

그리고 통신도 잘 되는것을 보니, 인증서랑 config도 잘 들어갔다.

 

 

기타

 

1. envoy는 시작시 유효한 위치에 config가 없으면 디폴트 config를 생성해서 시작한다.