Section 5 : Application Lifecycle Management

1. Rollout and Versioning

: 처음 배포를 생성하면 새로운 Rollout은 새로운 revision을 생성합니다. 컨테이너 버전이 새것으로 업데이트 되면 새 Rollout이 트리거되고, 새로운 배포 revision을 생성합니다. 배포에 일어난 변화를 추적하고, 전버전으로 돌아갈 수 있게 돕습니다. 

배포 전략에는 2가지가 있습니다. 

 

1) 기존의 것을 삭제하고, 새로운 것을 배포하는 방법은 구 버전이 다운되고, 새로운 버전이 업데이트 되기 전 기간에 응용 프로그램이 다운되어 사용자가 사용이 불가합니다. 이 Recreate 전략은 기본적으로 잘 사용되지 않습니다.

 

 

2) 한꺼번에 전부 삭제하지 않고, 하나씩 삭제하며 새 버전을 올리는 방법이 있습니다. 이는 응용 프로그램이 다운되지 않고, 업그레이드도 잘 수행할 수 있습니다. 이를 Rolling Update라고 하며, Deployment Strategy를 설정하지 않으면 이가 기본으로 적용됩니다. 좀 더 자세하게는 Deployment 내 원래의 ReplicaSet1이 존재한다면, 새로운 ReplicaSet2를 생성해 해당하는 개수의 Pod를 생성합니다.

 

만약 Rollback을 실행하게 된다면, 새로 생성한 ReplicaSet2 내 Pod를 없애고, ReplicaSet1의 Pod를 기동합니다.

 

필요 명령어

 

 

2.  Application Commands

: 컨테이너는 OS를 점유하지 않고 특정한 task나 process를(ex.webserver, app server, db) 실행하기 때문에,
task가 완료되면 컨테이너는 exit 된다. DockerFile 내 CMD에 사용되는 "bash"는 웹 서버 혹은 DB 같은 프로세스가 아니라 터미널의 입력을 돕는 명령어입니다. 우분투 이미지로부터 컨테이너를 만들어 bash 프로그램을 시작하면, 기본값으로 Dokcer는 실행중일 때 컨테이너에 터미널을 연결하지 않습니다. 그렇기에 bash는 터미널을 찾지 못해 연결이 끊기는 것이죠.

 

[ 1 ] CMD : RUN 명령어가 이미지를 빌드할 때 실행되는 것과 달리, 이미지로부터 컨테이너를 생성하여 최초로 실행할 때 수행됩니다.

 

[ 2 ] ENTRYPOINT : 컨테이너가 생성되고 최초로 실행할 때 수행되는 명령어를 지정합니다.

 

둘의 차이점은 ENTRYPOINT는 항상 실행이 되고, CMD는 docker run 명령어를 실행할 때, 변경이 가능합니다. 두 개를 혼합하는 가장 보편적인 사용 사례는 컨테이너 시작 작업을 자동화하는 것이다. CMD를 사용하여 매개 변수를 정의하고 ENTRYPOINT 명령을 사용하여 실행 파일을 정의할 수 있다.

FROM centos:7
ENTRYPOINT ["echo", "Hello,"]
CMD ["Darwin"]

 

docker build -t hello:together .
docker run hello:together
Hello, Darwin # 매개변수 없이 컨테이너를 실행하면 CMD에 지정한 인자 사용
docker run hello:together world
Hello, world # 매개변수 넘겨주면 CMD 기본값은 오버라이딩되어 무시됨

 

 

 

 추가로 Dokcerfile의 ENTRYPOINT는 k8s Pod .yaml 파일 내 command에 대응되고, Dokcerfile의 CMD는 k8s Pod .yaml 파일 내 args에 대응됩니다.

 

 

 

3. Configure Application

: ConfigMap을 활용해 환경변수를 적용할 수 있습니다. 2가지 방법이 있습니다.

1) Imperative

 

 

: 위 방법은 직접적으로 환경 변수를 선언하는 방식이고, 아래는 너무 많은 환경 변수의 값이 필요할 대 해당 파일을 사용하는 방법입니다.

 

2) Declartive

 

: 위 방법은 선언적으로 사용하는 방안이고, config-map.yaml을 만들어서 사용할 수 있습니다.

 

 

 

4. Secret

: ConfigMap에 암호를 저장하기 보다는 민감한 정보 같은 경우는 Secret에 담으면 좋다. 인코딩된 형식으로만 저장되는 점은 제외하고는 비슷합니다. 생성 방법으로는 ConfigMap과 같이 2가지가 있고, .yaml의 전체적인 구조도 같습니다. 특히 값을 넣을 때 주의해야할 것은 인코딩된 형태로 넣어야합니다. 방법으로는 아래와 같이 이용할 수 있습니다. echo -n 'Text' | base64

 

해당 정보를 정확하게 보기 위해서는 > kubectl get secret (secret name) -o yaml 실행하면 됩니다. 암호화 과정과 해독하는 과정에서는 base64 커맨드를 통해 사용됩니다.

 

 

 

5. Multi Container Pods

: 대형 모놀리식 애플리케이션을 마이크로서비스로 독립적이고 작은 하위 부품으로 나워서 재사용 가능한 코드를 개발 및 배포할 수 있도록 해줍니다. 하지만 예로 Log Agent, Web Serber가 함께 필요할 수도 있습니다. 각각 따로 개발하고 배포하길 원하기에 이를 합쳐서 사용하는 것은 좋지 않습니다.

 

같은 Lifecycle을 공유하고, 다중 컨테이너 Pod가 있는데 함께 생성되고 파괴됩니다. 같은 네트워크 공간을 공유하고, 서로를 로컬 호스트라고 부를 수 있다는 뜻 입니다. 또한 같은 Storage 볼륨에 접근할 수 있습니다.

 

이렇게 하면 Pod끼리 볼륨 공유나 서비스를 설정하지 않아도 됩니다. spec/containers/ 부분에 Pod를 추가하면 다중 컨테이너 Pod 생성이 가능합니다.

 

다중 컨테이너 Pod를 설계하는 데 3가지 일반적인 패턴이 있습니다. 1) SIDECAR        2) ADAPTER         3) AMBASSADOR 

 

 

 

6.  InitContainers

: 멀티 컨테이너 파드에서 각각의 컨테이너는 파드의 라이프 사이클을 따른다. 반면에, 하나의 프로세스를 수행하고 완료되는 컨테이너가 필요할 때도 있다. 예를 들어, 코드를 레포지토리에서 받아오는 프로세스가 있다. 이러한 작업은 파드가 생성되었을 때 한번만 수행되어야 한다. 또는 실제 애플리케이션이 실행되기 전에 서비스나 데이터가 실행될 때까지 기다리는 작업이 대표적인 예시이다.

 

파드가 처음 실행되면 initContainer가 실행되고 initContainer의 작업은 실제 컨테이너의 작업이 실행되기 전에 완료된다.

initContainer도 여러 개를 정의할 수 있다. 주의해야 할 점은 멀티 컨테이너와 달리, multi init container는 한번에 하나씩 순차적으로 실행된다.

 

만약 initContainer 중 일부가 실패하면 쿠버네티스는 모든 initContainer들이 성공적으로 완료될 때까지 반복적으로 파드를 재시작한다.