[Kubernetes] 파드의 생애주기(Lifecycle)와 배포 전략

🔊 해당 포스팅은 시작하세요! 도커/쿠버네티스 서적을 읽고 개인적인 목적 하에 작성되는 글입니다. 포스팅에 사용되는 모든 자료는 제가 직접 재구성하였음을 알립니다.
 

Kubernetes

---

쿠버네티스에서는 파드를 관리할 때, 파드의 상태값에 따라 관리하게 된다. 그리고 이 파드의 상태는 파드의 생애주기(Lifecycle)라는 것 안에 다양한 상태 종류로 존재한다. 이번 포스팅에서는 파드의 생애주기를 알아보면서 파드의 상태에 어떤 종류들이 있고, 그 의미가 무엇인지, 더 나아가 이 생애주기를 발생시키는 배포 전략(a.k.a 블루 그린, 롤링 업데이트)에 대해서 알아보도록 하자.
 
지금까지는 파드, 디플로이먼트, 레플리카셋 등 모든 쿠버네티스 리소스 오브젝트를 단순히 kubectl apply -f 라는 명령어를 이용해서 배포해왔다. 좀 더 고도화된 방식으로 요즘은 Spinnaker, Helm, Kustomize, ArgoCD, Jenkins 와 같은 지속적 배포 도구(CD)를 이용하기도 한다. 이번 포스팅에서는 이러한 외부의 배포 도구에 대한 설명 보다는 쿠버네티스에서 자체적으로 제공하는 파드 배포 전략에 대해 다루어 보려고 한다.
 
우선 배포 전략은 대체 왜 필요할까? 하나 예시를 들어보자. 우리는 현재 v1 이라는 이름의 애플리케이션 파드를 쿠버네티스에 배포한 상태이다. 그런데 애플리케이션에 추가 기능이 필요해서 추가 기능에 대한 로직이 반영된 v2 라는 이름의 애플리케이션 파드를 새롭게 배포해야 하는 상황에 직면했다. v1에서 v2 애플리케이션으로 배포하는 가장 단순무식(?)한 방법은 kubectl delete, create 명령어를 이용하는 것이다. 말 그대로 v1 이름의 애플리케이션 파드를 kubectl delete 명령어로 삭제하고, 곧바로 v2 이름의 애플리케이션 파드를 kubectl apply 명령어로 새롭게 배포하는 것이다.
 
하지만 이러한 방법은 바람직하지 않다. 왜냐하면 v1을 삭제하고 v2을 배포할 때, 그 중간에 애플리케이션의 다운 타임이 발생하게 된다. 또한 v1을 삭제하는 순간 그 순간에 클라이언트의 요청을 v1 파드가 처리하고 있을 수도 있을텐데, 처리하는 중간에 파드를 삭제해버리면 클라이언트는 v1 애플리케이션 파드로부터 알 수 없는 응답을 받게 될 수도 있다.

1. 디플로이먼트를 이용해 롤링 업데이트 수행하기

방금 소개한 상황 즉, 새로운 버전의 파드로 다운타임 없이 옮기기 위해서 쿠버네티스는 디플로이먼트 리소스 오브젝트를 이용한 기능을 제공한다. 구체적으로 롤링 업데이트 기능이라고 하는데, 사실 이 기능은 이전 디플로이먼트를 배우는 포스팅에서 소개한 적이 있었다. 디플로이먼트는 레플리카셋을 관리하며 레플리카셋의 리비전 관리, 롤백 기능, 롤링 업데이트 기능을 제공한다. 디플로이먼트는 레플리카셋의 변경 사항을 저장하는 리비전(reivison)을 관리함으로써 애플리케이션의 롤백, 롤링 업데이트를 쉽게해줄 수 있다.
 
이전 포스팅에서도 소개했지만 디플로이먼트를 생성하는 매니페스트를 정의하고 kubectl apply 명령어 수행 시, --record 옵션을 수행하게 되면 해당 디플로이먼트가 관리하는 레플리카셋에 대한 정보가 해당 디플로이먼트의 히스토리에 기록된다. 참고로 디플로이먼트가 히스토리로 관리하는 여러 버전의 레플리카셋의 개수를 제한시킬 수도 있는데, 이는 디플로이먼트를 정의하는 매니페스트에 spec.revisionHistoryLimit 으로 값을 명시해줄 수 있다.
 
디플로이먼트가 롤링 업데이트라는 일종의 배포 전략 기능을 제공한다고 했는데, 사실 롤링 업데이트 말고도 ReCreate 라는 배포 전략 기능도 제공한다. ReCreate 방법은 롤링 업데이트와는 달리 다운 타임을 고려하지 않는 배포 전략이다. ReCreate와 롤링 업데이트의 차이점에 대해서 도식화 해보면 다음과 같다.
 

디플로이먼트가 Recreate 방식으로 배포 전략을 수행한다면?

 
t0 에서 t2 로 시간이 흐른다고 가정해보자. t0에서는 version 1 이라는 레플리카셋이 생성되어 있는 상태이다. 그리고 이제 새로운 버전의 레플리카셋인 version 2를 배포했다고 해보자. 이 때, 만약 디플로이먼트의 배포 전략이 Recreate인 상태라면 t1 일때 version 1 이라는 레플리카셋이 모두 삭제된다. 그리고 난 뒤, t2 시점에 가서야 version 2 라는 새로운 버전의 레플리카셋이 생성된다. 이런 Recreate 배포 전략은 당연하게도 t1 시점에는 다운타임이 발생하게 된다. 따라서 Recreate 배포 전략은 일시적으로 클라이언트의 요청을 처리하지 못해도 괜찮은 애플리케이션일 때 사용한다. 디플로이먼트에 배포 전략을 Recreate로 명시하는 예시는 다음과 같다.
 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-reCreate
spec:
  replicas: 3
  selector:
    matchLabels:
      app: testApp
  strategy:
    type: Recreate
  template:
    metadata:
      name: nginx-pod
      labels:
        app: testApp
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

 
이제 다음으로 알아볼 배포 전략은 롤링 업데이트 방식이다. 롤링 업데이트 방식은 Recreate 방식과 다르게 다운 타임이 없는 것을 보장한다. 그림으로 표현하면 다음과 같다.
 

디플로이먼트가 RollingUpdate 방식으로 배포전략을 가져간다면?

 
그림을 보면 t1 과 t2 일 때 version 1 과 2의 레플리카셋이 공존하는 형태를 볼 수가 있다. 즉, 롤링 업데이트 방식은 기존의 파드와 새로운 파드를 조금씩 삭제 및 생성하면서 진행된다. 이렇게 하면 다운타임을 발생시키지 않으면서 새로운 버전의 디플로이먼트로 배포할 수 있다. 
 
롤링 업데이트에 대한 위 예시에서는 시간이 흐름에 따라 파드 하나씩을 삭제 및 생성하도록 나타내었지만, 몇 개를 한 번에 삭제하거나 생성할지도 사용자가 매니페스트에 선언적으로 명시할 수 있다. 우선 롤링 업데이트 전략을 가져가는 디플로이먼트의 예시 매니페스트는 다음과 같다.
 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-rollingupdate
spec:
  replicas: 3
  selector:
    matchLabels:
      app: testApp
  strategy:
    type: RollingUpdate   # 배포 전략을 변경
    rollingUpdate:        # 롤링 업데이트 시 옵션 명시
      maxSurge: 2
      maxUnavailable: 2
  template:
    metadata:
      name: nginx-pod
      labels:
        app: testApp
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

 
위 매니페스트의 spec.strategy 영역을 보자. RollingUpdate 로 type을 바꾼 뒤, maxSurge, maxUnavailable 이라는 옵션을 사용해서 롤링 업데이트의 설정을 명시해주었다. 이 옵션은 롤링 업데이트의 속도를 조절할 수 있다. 위 예시에서는 숫자 값을으로 '개수'를 명시했지만, '비율(%)'형태로도 명시가 가능하다. 참고로 비율을 명시할 경우, maxSurge의 소수점 값은 반올림되고, maxUnavailable은 소수점이 내림처리된다. 각 옵션의 의미는 다음과 같다.
 

• maxUnavailable : 롤링 업데이트 도중 사용 불가능한 상태 즉, 삭제 대상 파드이자 기존 버전의 파드를 한꺼번에 최대 몇 개를 삭제할지를 명시한다. 예를 들어, 이 값을 2로 설정했다면, 한꺼번에 삭제될 파드 개수는 최대 2개임을 의미.
• maxSurge : 롤링 업데이트 도중 전체 파드의 개수가 디플로이먼트의 replicas 개수보다 얼마나 더 많이 존재할 수 있는지 설정한다. 즉, 새롭게 생성할 파드이자 새로운 버전의 파드를 한꺼번에 생성할 개수를 간접적으로 의미한다. 이 간접적으로 의미한다는 뜻은 아래 예시에서 이해해보자.

maxSurge 와 maxUnavailable에 대한 개념을 좀 더 명확하게 이해하기 위해 아까 위에서 살펴본 그림을 가지고 이해해보도록 하자.
 

 
t0 시점에는 version 1의 레플리카셋이 운영되고 있다가 t1 시점이 되어 version 2의 레플리카셋이 배포되었다. 그런데 이 때, version 1의 파드는 1개만 삭제되었다. 1개만 삭제가 된 이유는 매니페스트의 maxUnavailable이 2이기 때문이다. 즉, version 1이 한꺼번에 삭제될 수 있는 파드의 '최대' 개수는 2개이므로(반드시 2개가 아니며 엄밀히 말하면 2개 이하이다) 위 예시에서는 1개만 삭제되도록 예시를 들었다. 그와 동시에 version 2라는 새로운 버전의 파드는 한꺼번에 3개가 생성되었다. 이것이 가능했던 이유는 maxSurge 값이 2이기 때문이다. 왜냐하면 새롭게 생성될 파드의 최대 개수는 replicas 값과 maxSurge 값의 합으로 결정이 되는데, 위 예시 상으로는 replicas가 3이고, maxSurge가 2이므로 두 합이 5이다. 다시 말해, 롤링 업데이트 도중 존재할 수 있는 파드의 전체 개수는 최대 5개까지 가능하다는 이야기다. t1 시점에 version 2라는 새로운 버전의 파드 3개가 모두 생성되더라도 version 1의 파드 2개랑 개수를 합쳐도 5개이므로 새로운 버전의 파드 3개가 한꺼번에 생성되는 것이 가능해진다. 그리고 t2 시점에 version 1의 파드 2개를 한꺼번에 삭제할 수 있게 된다. 2개를 한꺼번에 삭제할 수 있는 이유도 maxUnavailable이 2이기 때문이다.
 
이러한 롤링 업데이트 방식에서 주의할 점은 위 그림에서 t1 시점처럼 version 1과 version 2의 파드들이 동시에 존재하는 순간이 있다는 것이다. 이 말은 클라이언트 측에서 보내는 요청을 version 1, version 2 모두 받아낼 수 있는 인터페이스 상태여야 한다. 만약 클라이언트 측에서 보내는 요청에 맞지 않는 인터페이스를 가진 version의 파드는 교체될 때 에러가 발생하게 됨에 주의하자.
 
방금 언급한 롤링 업데이트의 단점 즉, 2가지 버전의 파드가 공존한다는 점도 해결하고 다운타임이 없도록 할 수 있는 블루 그린 배포 방식이라는 것도 존재한다. 블루 그린 배포는 기존 버전의 파드를 그대로 놔둔 상태에서 새로운 버전의 파드를 미리 모두 생성해놓고, 서비스 리소스 오브젝트의 라우팅만 기존 버전에서 새로운 버전으로 변경하는 배포 방식을 의미한다. 그림으로 표현하면 아래와 같다.
 

블루 그린 배포 방식을 선택한다면?

 
쿠버네티스에서는 기본적으로 블루 그린 배포 방식을 제공하지는 않는다. 하지만 외부 도구를 사용하지 않고, 직접 매니페스트를 사용자가 수정함으로써 적용해볼 수 있다. 즉, 새로운 버전의 디플로이먼트를 모두 생성해놓은 뒤, Service 리소스 오브젝트가 바라보는 라벨을 기존 디플로이먼트에서 새로운 디플로이먼트로 변경하여 라우팅만 변경해주면 된다. 물론 이런 경우 기존 디플로이먼트는 사용자가 직접 삭제해주어야 한다. 이러한 블루 그린 방식은 롤링 업데이트와 Recreate 방식의 단점을 모두 보완하긴 하지만, 기존 디플로이먼트와 신규 디플로이먼트 2개가 모두 한꺼번에 생성된다는 점에서 일시적으로 전체 자원을 많이 소모할 수 있다는 단점이 있다.

2. 롤링 업데이트가 바라보고 있는 것 : 파드의 생애주기(Lifecycle)

1번 목차에서 알아본 배포 전략 중 롤링 업데이트 방식을 수행할 때는 기존 파드가 정상적으로 잘 종료되었는지, 또 새로운 파드가 정상적으로 잘 실행되어 클라이언트의 요청을 맞이할 준비가 되어 있는지 확인하는 것이 중요하다. 일단 기존 파드가 종료될 시에, 처리하고 있던 클라이언트의 요청을 끝까지 완결성 있게 처리한 후 종료되어야 한다. 또한 새롭게 생성된 파드의 상태(status)가 Running이 되었다고 하더라도, 파드 컨테이너의 init 프로세스(컨테이너가 실행될 때 진입하는 entrypoint로서 실행되는 프로세스)가 생성되는 데 꽤 시간이 걸린다면 그 동안에는 클라이언트의 요청을 처리할 준비가 안되어있을 상태일 수도 있다.
 
쿠버네티스는 이렇게 기존 파드가 종료될 때 처리 중이던 요청을 마무리해서 처리하고 종료하도록 하는 Graceful Shutdown을 하도록, 그리고 새로운 파드가 생성된 뒤 애플리케이션이 클라이언트의 요청을 처리할 준비가 되었는지 확인할 수 있는 별도의 기능을 지원한다. 대표적으로 livenessProbe, readinessProbe, startupProbe가 있다. 다만 이러한 종류들의 기능을 알아보기 전에 우리는 파드가 생성되기 부터 종료될 때까지의 단계를 의미하는 파드의 생애주기(Lifecycle)에 대해서 알아볼 필요가 있다.
 
파드의 생애주기로는 아래와 같이 종류가 있다. 개괄적으로 먼저 의미를 살펴보고, 세부적인 의미를 각각 살펴보도록 하자.

• Pending : 파드를 생성하는 API 요청이 kupe api server에 의해 승인되었지만, 어떠한 이유로 파드가 아직 실질적으로 생성되지 않은 상태를 의미. 여기서 '어떠한 이유'라 함은 대표적으로 파드가 스케쥴링될 노드가 아직 선정되지 않는 경우가 있다.
• Running : 파드에 포함된 모든 컨테이너들이 잘 생성되어 파드가 정상적으로 실행된 상태. 이러한 상태를 쿠버네티스에서는 바람직한(Desired) 상태라고 부름. 다만, 위에서도 언급했지만 Running 상태가 됐더라도 무조건적으로 클라이언트의 요청을 맞이할 준비가 되었다는 것을 의미하진 않음
• Completed : 파드가 정상적으로 실행된 뒤 종료되었음을 의미. 즉, 파드 컨테이너의 init 프로세스 종료 코드(exit code)가 0을 반환한 경우를 의미(이 '종료 코드'라 함은 예전 리눅스 셸 스크립트 포스팅에서 배운적이 있으므로 참고)
• Error : 파드가 정상적으로 실행되지 않은 상태로 종료되었음을 의미. 즉 파드 컨테이너의 init 프로세스 종료 코드가 0이 아닌 값을 반환한 경우를 의미
• Terminating : 파드가 삭제 또는 퇴거(Eviction)되기 위해 삭제 상태에 머물러 있는 경우에 해당

2-1. 잘 종료되었거나 말거나 : Completed, Error

먼저 알아볼 파드의 생애주기 상태 값으로는 Completed 와 Error이다. 이 상태 값들은 파드 컨테이너의 init 프로세스가 종료 코드를 0으로 반환했느냐 또는 0이 아닌 다른 숫자를 반환했느냐에 따라 달라진다. 여기서 'init 프로세스' 라는 것에 대해서 생소할 수 있다. init 프로세스는 리눅스 시스템이 구동될 때 가장 먼저 실행되는 프로세스로서 일반적으로 PID 값이 1번인 프로세스를 의미한다. 우리에게 익숙한 Docker로 치면 Dockerfile 파일 내용에 설정된 CMD와 ENTRYPOINT 명령어의 조합이 init 프로세스가 된다. 또한 현재 실행중인 컨테이너들의 목록을 볼 수 있는 "docker ps" 명령어를 수행하면 콘솔에 출력되는 내용 중 "COMMAND" 항목에 해당하는 것이 init 프로세스가 된다.
 
이러한 init 프로세스를 실행시키는 명령어가 잘 동작했다면 종료 코드를 0으로, 잘 동작하지 않았다면 0이 아닌 다른 값을 반환한다.(init 프로세스의 종료 코드는 마치 함수의 return 이라고 생각하면 된다) 그래서 종료 코드가 0이면 파드의 상태가 Completed를, 0이 아니라면 Error 상태가 된다.
 
그런데 여기서 우리는 이 Completed, Error와 관련되어서 파드 매니페스트에 작성할 수 있는 restartPolicy 라는 특성에 대해서 이해해야 한다. restartPolicy는 이름 그대로 파드가 재시작하는 정책을 무엇으로 할 것인지 명시하는 값이다. 종류에는 다음과 같이 존재한다.

• Always : 파드의 종료 상태가 Completed 던, Error이던 파드가 계속해서 다시 실행(Restart)된다.
• Never : 파드의 종료 상태가 Completed 던, Error이던 파드는 더 이상 다시 실행되지 않는다.
• OnFailure : 파드의 종료 상태가 Error 일 때만 파드가 계속해서 다시 실행 된다.

그런데 이 restartPolicy 값을 별도로 명시하지 않으면 기본적으로 Always 라는 값이 명시되어 파드가 생성된다. 그래서 만약 "내가 생성한 파드가 잘 종료되면 더 이상 실행되길 원하지 않아" 라고 의도했는데, 해당 파드가 계속 재시작해서 RESTART 항목 수가 계속 증가한다면 restartPolicy 값을 의도에 맞게 명시해보도록 하자. 실제로, Never, OnFailure 와 같은 restartPolicy 값을 사용하는 파드는 주로 쿠버네티스트의 Job이나 CronJob 리소스 오브젝트로부터 생성되는 파드들에서 사용한다.
 
그리고 참고로 파드의 상태가 Error로 발생해서 파드가 종료되고 재시작할 때, 즉시 재시작되는 것은 아니다. 중간에 파드가 생애주기의 또 다른 상태 값에 잠시 머무르는데, 이 상태가 바로 CrashLoopBackOff 라는 상태이다. 이 상태는 쿠버네티스에서 어떠한 작업이 실패했을 때, 일정 간격을 두고 해당 작업을 재시도하는데, 이 때 일정 간격동안 파드가 머물러있는 상태가 바로 CrashLoopBackOff이다. 다만, 이 CrashLoopBackOff 상태에 머무는 기간이 파드가 실패하고 재시작하는 횟수가 늘어남에 따라 점점 지수적으로 증가한다. 예를 들어, 어떤 파드의 작업이 첫번째에 실패했을 때 재시작 전 CrashLoopBackOff 상태에 머무르는 시간보다 9번째, 10번째 실패했을 때 재시작 전 CrashLoopBackOff 상태에 머무르는 시간이 훨씬 더 길어진다는 의미이다.

2-2. 파드가 잘 생성되었지만 정말 잘 생성되었나? : Running

이번에는 파드가 잘 생성된 상태를 의미하는 Running에 대해 알아보자. 그런데 [목차 2-2] 제목이 이게 무슨 소리인가 싶다. 파드가 잘 생성된거면 된거지 정말 잘 생성된 것이라니? 이 의미를 이해하기 위해서 [목차 2] 인트로에서 잠시 언급했던 이야기를 다시 해보자. 
 
파드의 상태가 Running이 되었다고 하더라도 그 Running 상태가 반드시 해당 파드가 클라이언트의 요청을 처리할 준비가 되었다는 것을 보장하는 것은 아니라고 했다. 단적인 예로, 어떤 파드의 init 프로세스가 스토리지에서 파일을 다운로드 받고 애플리케이션 서버가 initialize 하는 2가지 단계를 거친다고 해보자. 그런데 이 때, 스토리지에서 파일들 다운로드 받는 시간에는 약 10초가 소요된다고 가정해보자. 이럴 경우, 스토리지에서 파일을 다운로드 받는 동안은 여전히 파드의 상태는 Running이다. 하지만 아직 애플리케이션 서버가 initialize 된 것이 아니므로, 파드의 상태는 Running 상태이지만 이 순간에 클라이언트가 해당 파드로 요청을 보내면 파드는 그 요청을 처리할 준비가 되지 않았으므로 요청이 실패한다. 그래서 이러한 상황을 비유로 들어, "파드가 잘 생성되었지만 정말 잘 생성되었나?" 라고 제목을 지은 것이다. 
 
이러한 문제를 막기 위해 쿠버네티스에서는 파드의 상태가 Running 이지만, 파드가 실제로 클라이언트의 요청을 받기 위한 준비도 완료가 된 것인지 체크하기 위해 init Container, postStart, livenessProbe/readinessProbe 라는 기능들을 지원한다. 하나씩 살펴보도록 하자. 참고로 init Container, postStart는 애초에 파드가 Running 상태로 전환하기위한 필수 조건을 구성하는 기능을 한다. 반면 livenessProbe/readinessProbe 기능은 직전 문단에서 언급한 문제와 같이 파드가 Running 상태로 전환되었지만 클라이언트의 요청까지 처리할 상태까지 되었는지 확인하기 위한 용도이다. 이에 대해 헷갈릴 것 같아 그림으로 나타내보았다. 
 

2-2-1. 애플리케이션 컨테이너 실행 전 최초로 실행되는 컨테이너 : init Container

가장 먼저 알아볼 것은 init Container이다. init Container는 생성될 파드의 애플리케이션 컨테이너가 실행되기 전에 실행할 수 있는 즉, 일종의 초기화를 수행하는 컨테이너를 의미한다. 애플리케이션 컨테이너와 init Container 간의 차이점이라고 한다면 init Container가 애플리케이션 컨테이너보다 단순히 먼저 실행되는 것 밖에 없다. 그래서 애플리케이션 컨테이너가 실행되기 전에 어떤 작업이 선행되어야 할 때 init Container를 사용한다. 직전에서 언급한 "스토리지에서 파일을 다운로드 받고 애플리케이션 서버가 intialize" 되는 경우를 들었는데 여기서 "스토리지에서 파일을 다운로드 받는" 작업을 init Container에서 실행해도 된다.(물론 init Container 와 애플리케이션 컨테이너가 emptyDir 볼륨을 이용해야 함. emptyDir 볼륨에 대해서는 이전 PV, PVC 포스팅 참조)
 
init Container는 파드 매니페스트 YAML 파일에 initContainers 항목으로 명시가 가능하며 여러 개의 init Container를 한꺼번에 명시할 수 있다. 다만, 2개 이상의 init Container들을 명시하면 매니페스트 파일에 명시된 순서로 실행이 된다. 예시 매니페스트는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: init-container-test
spec:
  initContainers:
    - name: init-container-first
      image: busybox
      command: ["sh", "-c", "echo Hello init-container-first"]
    - name: init-container-second
      image: busybox
      command: ["sh", "-c", "echo Hello init-container-second"]
  containers:
    - name: nginx
      image: nginx:latest

 
init Container도 실패할 경우, 명시한 restartPolicy 종류에 따라 파드가 재시작한다. 그리고 init Container가 정상 실행되지 않는다면 그 이후의 애플리케이션 컨테이너 실행 단계로 절대 넘어가지 않는다. 이 init Container에서 하는 작업을 dig 나 nslookup 명령어를 이용해 수행하도록 하여 약간 응용하면 다른 디플로이먼트나 서비스들이 준비가 된 이후에 해당 파드가 실행될 수 있도록 간접적으로 의존성을 주입시켜볼 수도 있다.

2-2-2. 애플리케이션 컨테이너가 실행될 때 훅(Hook) 걸기! : postStart

이번에 알아볼 postStart는 init Container가 아닌 애플리케이션 컨테이너가 실행될 때 어떤 작업을 수행하도록 하는 라이프사이클 훅을 파드 매니페스트에 정의를 할 수 있다. postStart는 아래의 2가지 방식으로 동작하는 것을 지원한다.
 

• HTTP : 애플리케이션 컨테이너가 시작한 직후, 특정 주소로 HTTP 요청을 전송
• Exec : 애플리케이션 컨테이너가 시작한 직후, 특정 명령어를 수행

둘 중 Exec 방식의 매니페스트 예시는 다음과 같다.
 

apiVersion: v1
kind: Pod
metadata:
  name: post-start-hook
spec:
  containers:
    - name: nginx
      image: nginx:latest
      lifecycle:
        postStart:
          exec:
            command: ["sh", "-c", "touch/test.log"]

 
이 postStart에 명시된 HTTP 요청 또는 Exec 명령어도 정상적으로 실행되지 않으면 애플리케이션 컨테이너를 Running 상태로 전환되지 않는다. 주의할 점은 이 postStart는 init 프로세스와 비동기로 실행되기 때문에 둘 중에 어떤 것이 먼저 실행된다는 보장은 없다. 그래서 postStart 와 init 프로세스가 수행하는 각 로직이 서로 디펜던시가 있도록 하는 것은 바람직하지 않는 듯 하다. 왜냐하면 postStart가 수행하는 로직도 마찬가지로 제대로 실행이 안되면 애플리케이션 컨테이너를 Running 상태로 전환되지 않고 restartPolicy 에 의해 재시작될 것이기 때문이다. 그리고 postStart 실행 로그는 에러가 발생하지 않는 한 별도로 확인할 수 없다는 점도 주의하자.

2-2-3. 애플리케이션 컨테이너가 클라이언트 요청을 받을 준비가 되었는지를 보장! : livenessProbe, readinessProbe, startupProbe

이번에 알아볼 내용은 애플리케이션 컨테이너의 상태가 Running으로 전환되었다고 해도 정말 클라이언트의 요청을 받을 상태까지 된 것인지 체크할 수 있는 기능들인 livenessProbe, readinessProbe, startupProbe에 대해서 알아보도록 하자. 이 3가지 기능이 동작하는 순서를 그림으로 나타내면 다음과 같다.
 

 
3가지 기능에 대한 설명은 다음과 같다.

• starupProbe : 애플리케이션이 시작될 때 수행되는 초기화 작업 등(init container, postStart에서 수행했던 작업이라던지, ...)이 잘 완료되었는지 확인. 이 startupProbe가 성공해야 livenessProbe, readinessProbe가 시작되며, startupProbe도 실패하게 되면 파드의 restartPolicy에 따라 파드가 재시작됨
• readinessProbe : 애플리케이션이 클라이언트의 요청을 처리할 준비가 되었는지 검사함. 검사에 실패할 경우, 해당 파드 컨테이너는 k8s 서비스의 라우팅 대상에서 제외가 됨
• livenessProbe : 애플리케이션이 살아있는지 검사함. 검사에 실패할 경우 해당 컨테이너는 restartPolicy에 따라 재시작함

여기서 헷갈릴 수 있는 점은 readinesProbe 와 livenessProbe인데, 비슷한 역할을 하는 것 같지만 목적은 엄연히 다르다. livenessProbe은 애플리케이션의 정상 상태를 지속해서 계속검사하는 것이고, readinesProbe는 애플리케이션이 시작한 뒤 초기화 작업이 완료가 되어서 클라이언트의 요청을 받을 준비가 되었는지 확인하는 것이 목적이다.
 
그래서 이 목적성에 부합하듯이, livenessProbe에서 실패하게 되면 파드가 restartPolicy에 따라 재시작하지만, readinesProbe은 실패하더라도 재시작하는 것이 아닌 단순히 k8s 서비스의 라우팅 대상에서 해당 파드의 IP가 제외되고 엔드포인트 리소스에서도 해당 파드를 제외시키기만 한다. readinesProbe는 어느정도 시간이 지난 뒤 애플리케이션 준비가 완료될 수도 있기 때문에 재시작까지는 하지 않으며 준비가 완료될 시 바로 서비스 라우팅 대상에 포함시키고, 엔드포인트 리소스에도 추가할 수 있도록 해준다.
 
이제 그럼 예제 매니페스트를 살펴보자. 먼저 livenessProbe 부터 살펴보자. 
 

apiVersion: v1
kind: Pod
metadata:
  name: liveness-probe-test
spec:
  containers:
    - name: nginx
      image: nginx:latest
      livenessProbe:
        httpGet:
          port: 80
          path: /

 
위 매니페스트를 보면 httpGet 이라는 것을 볼 수 있다. livenessProbe에는 아래의 3가지 방식 중 하나를 선택해서 애플리케이션 컨테이너의 상태를 검사한다.

• httpGet : HTTP GET 요청을 전송해 상태를 검사함. 요청을 전송한 뒤 종료 코드가 200 또는 300번 계열이 아닌 경우 검사에 실패한 것으로 간주해 파드가 재시작한다. 요청을 보낼 포트와 경로, 그리고 헤더, HTTPS 사용 여부 등을 추가로 지정할 수도 있다.
• exec : 애플리케이션 컨테이너 내부에서 명령어를 실행해 상태를 검사한다. 명령어의 종료 코드가 0이 아닌 경우에 검사에 실패한 것으로 간주해 파드가 재시작한다.
• tcpSocket : TCP 연결이 수립될 수 있는지를 체크해서 검사를 수행한다. 수립되지 않을 경우 검사에 실패한 것으로 간주해 파드가 재시작한다.

다음은 readinessProbe 예제 매니페스트인데, 매니페스트에 명시하는 값과 검사 방식(httpGet, exec, tcpSocket)이 livenessProbe와 동일하다. 여기서는 예제 매니페스트만 보고 넘어갈텐데, 아무래도 readinessProbe이기 때문에 라우팅을 위해 서비스 리소스 오브젝트 매니페스트도 같이 넣어놓았다.
 

apiVersion: v1
kind: Pod
metadata:
  name: readiness-probe-pod
  labels:
    readiness-probe: test
spec:
  containers:
    - name: nginx
      image: nginx:latest
      readinessProbe:
        httpGet:
          port: 80
          path: /
---
apiVersion: v1
kind: Service
metadata:
  name: readiness-probe-svc
spec:
  type: ClusterIP
  ports:
    - name: nginx
      port: 80
      targetPort: 80
  selector:
    readiness-probe: test

 
참고로 readinessProbe를 파드에 적용하기 어렵거나 애플리케이션 컨테이너의 초기화 시간이 꽤 필요한 경우에는 디플로이먼트 매니페스트에 minReadySeconds 라는 것도 사용할 수 있다. 해당 값을 사용하면 디플로이먼트의 롤링 업데이트 시 파드 컨테이너가 준비되기 위한 최소 대기 시간을 설정해서 새로운 파드가 생성된 뒤 minReadySeconds 만큼은 기존 파드가 유지되고, 그 이후에 기존 파드가 삭제되도록 할 수 있다.
 
마지막으로 livenessProbe, readinessProbe, startupProbe 모두 공통적으로 사용하는 세부 옵션들의 의미에 대해 열거해보고 다음 목차로 넘어가보도록 하자.

• periodSeconds : 상태 검사를 진행할 주기를 설정. 디폴트 값은 10초
• initialDelaySeconds : 파드가 생성된 뒤 상태 검사를 시작하기 전까지의 대기 시간을 설정. 기본적으로는 설정되어 있지 않음
• timeoutSeconds : 상태 검사 시 수행한 요청에 대한 타임아웃을 설정. 디폴트 값은 1초
• successThreshold : 상태 검사에 성공했다고 간주할 검사 성공 횟수를 설정. 예를 들어, 이 값이 3으로 설정되면 3번은 성공해야 상태 검사에 성공했다고 간주되어 그 다음 상태로 파드가 넘어갈 수 있음. 디폴트는 1
• failtureThreshold : 상태 검사에 실패했다고 간주할 검사 실패 횟수를 설정. 예를 들어, 이 값이 3으로 설정되면 3번은 실패해야 상태 검사에 실패했다고 간주되어 파드가 다음 상태로 넘어가지 못하게 함. 디폴트는 3
  • 이 값을 1로 설정하면 너무 민감(?)하게 상태 검사에 실패한 것으로 간주되어 robust 하지 않게 만들수도 있음에 유의

2-3. 파드가 종료되는 상태 : Terminating

다음으로 알아볼 파드의 생애주기 상태는 Terminating 이다. 영어단어 그대로 파드가 종료되는 상태를 의미한다. 다만, 여기서 '종료'라는 것은 몇 가지의 종료 방식을 내포하고 있다. 먼저 강제 종료이다. 강제 종료라 함은 파드가 현재 처리하고 있는 클라이언트의 요청이 있던 없던 바로 종료해 버린다는 것이다. 반면에 Graceful 종료가 있다. 이는 파드가 종료되더라도 현재 처리하고 있는 클라이언트의 요청들을 마저 마무리 짓고 종료하는 방식이다. 쿠버네티스에서의 Terminating은 후자인 Graceful 종료를 지향한다. 다만, 쿠버네티스에서 지원하는 기능만으로는 이 Graceful 종료 기능을 완벽히 구현하기는 힘들고 애플리케이션 서버의 소스코드 레벨의 로직과 함께 구현해야 가능하다.
 
이를 위해 먼저 우리는 쿠버네티스에서 파드를 종료할 때 어떤 단계로 종료되는지를 알아야 한다. 만약 사용자가 특정 파드를 삭제하기 위해 "kubectl delete $POD_NAME" 명령어를 입력했다고 해보자. 다만 이 파드는 레플리카셋으로 생성된 상태이고, 서비스의 라우팅 대상에 포함된 파드라고 가정한다. 그림으로 나타내면 다음과 같다.
 

 

1. 파드 리소스가 삭제될 예정이라는 의미의 deletionTimestamp 값이 파드의 데이터에 추가되고, 파드를 STATUS가 Terminating 으로 바뀜
2. 아래 3가지 작업이 동시에 실행됨
   • 파드 매니페스트에 preStop 라이프사이클 훅이 설정되어 있다면 preStop이 실행
   • 속했던 레플리카셋의 관리 영역에서 해당 파드가 벗어나며, 레플리카셋은 이제 새로운 파드를 생성하려고 시도
   • 서비스 라우팅 대상에서 해당 파드는 제외
3. preStop 훅이 완료되면 리눅스 시그널 중 SIGTERM이 파드의 컨테이너에 전달됨. 그리고 파드의 init 프로세스는 SIGTERM을 수신하고 프로세스가 종료됨
4. 파드 컨테이너가 SIGTERM을 수신했음에도 불구하고 모종의 이유로 특정 기간 동안 여전히 프로세스가 종료되지 않으면 SIGKILL 시그널은 전달. 여기서 '특정 기간'이라 함은 기본적으로 30초로 설정되어 있으며 파드의 terminationGracePeriodSeconds 항목을 통해 설정할 수 있음
   • 참고로 이 terminationGracePeriodSeconds을 0으로 설정한다는 것은 1~3번 단계도 수행되지 않고,바로 강제 종료한다는 의미다. 이는 권장되지 않는 방식이다. 이에 대해서는 SIGKILL 시그널이 의미하는 바를 알면되는데, SIGKILL에 대해 간단히 설명한 예전 포스팅 목차 1번 마지막을 참조해보자.

위 순서에서 등장한 preStop은 사실 [2-2-2. 목차]에서 배운 postStart 훅과 기능이 동일하되 언제 실행되느냐의 순서의 차이다. postStart는 파드 컨테이너가 실행하기 시작한 뒤에 실행되고, preStop은 파드 컨테이너가 종료될 때 실행되는 것 뿐이다. preStop을 매니페스트에 명시하는 방법 또한 postStart와 동일하므로 여기선 별도로 작성하지는 않겠다. 이 preStop이 바로 쿠버네티스에서 Graceful 종료를 위해 지원하는 기능 중 하나이다.
 
이제 쿠버네티스 말고 파드 컨테이너 즉, 애플리케이션 서버의 소스코드 레벨에서 Graceful 종료를 하기 위한 방법에 대해 알아보자. 위 단계에서 힌트를 얻을 수 있는데, 바로 3번 단계이다. 3번 단계에서 쿠버네티스는 파드 컨테이너에 SIGTERM 시그널을 송신한다고 했다. 그렇다면 애플리케이션 서버에서는 이 SIGTERM 시그널을 수신받았을 때 Graceful 종료를 하기 위한 로직(예를 들어, 처리하고 있던 요청을 마무리한다던지 등..)을 소스코드 레벨로 구현해놓으면 되는 것이다.
 
대표적인 예시로, 파이썬의 대표적인 WSGI 프레임워크인 gunicorn에서는 실질적인 요청을 처리하는 워커 프로세스에 TERM 이라는 시그널을 보내면 Graceful 종료를 하도록 작성되어 있음을  공식문서에서 확인할 수 있다.

3. 파드의 상태를 보고 Auto Scaling을 수행하자! : HPA

HPA(Horizontal Pod AutoScaler)는 파드의 리소스 사용량에 따라 디플로이먼트의 파드 개수를 자동으로 조절하는 기능을 제공하는 쿠버네티스 리소스 오브젝트이다. 그런데 직전까지 파드의 생애주기를 설명하다가 이 HPA가 왜 뜬금없이 등장했을까? 이유는 이 HPA도 파드의 상태를 보고 오토 스케일링을 수행하기 때문이다. 다만, HPA가 보는 상태는 우리가 지금까지 배운 Running, Completed, Error, Terminating과 같은 상태가 아닌 파드의 CPU, 메모리 사용률 상태를 본다.
 
사실 HPA가 파드의 CPU, 메모리 사용률을 보기 위해서는 쿠버네티스 자체가 기능을 지원하지 않기 때문에 metrics-server 라고 하는 별도의 리소스 메트릭 수집 도구를 설치해야만 한다. 이는 모니터링과 관련된 내용이라 이에 대한 자세한 내용은 추후 k8s 모니터링 포스팅에서 소개할 예정이다. 여기서는 metrics-server가 존재한다고 가정하고, HPA가 어떻게 오토 스케일링을 수행하는지에 대해 중점적으로 소개해보려고 한다.
 
일단 HPA라는 쿠버네티스 리소스 오브젝트를 생성하는 예제 매니페스트부터 살펴보자.
 

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-sample-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deployment-sample-test
  targetCPUUtilizationPercentage: 50
  maxReplicas: 5
  minReplicas: 1

 
HPA가 오토 스케일링할 대상을 지정하는데, 위 매니페스트를 보면 디플로이먼트 리소스를 지정한 것을 볼 수 있다. 그리고 그 디플로이먼트가 관리하는 파드들의 CPU 사용률이 50%가 넘을 경우, 파드를 최대 5개 만큼 오토 스케일링한다는 의미이다.
 
그런데 여기서 CPU 사용률을 지정하는 targetCPUUtilizationPercentage의 단위에 대해서 알아볼 필요가 있다. 이 50%가 어떤 기준으로 계산된 50%일까? 바로 파드에 할당된 request 대비 얼마나 리소스를 사용하고 있는지를 기준으로 삼는다. 먼저 아래 그림을 보자.
 

 
현재 디플로이먼트에서 관리하는 파드의 request.cpu 값은 1000m 라고 해보자. 그리고 현재 파드가 1개일 때의 사용량이 600m이다. 그리고 HPA의 targetCPUUtilizationPercentage 값이 50(%)이라고 명시되었다. 그러면 이를 위 자료 속에 빨간색 글씨로 명시되어 있는 공식을 이용해 계산을 한다.
 

600 / 1000 * 100 = 60

 
각 숫자가 의미하는 바는 다음과 같다.

• 600 : 현재 1개의 파드로 운영할 때의 리소스 사용량
• 1000 : 해당 파드의 request.cpu 에 명시된 값
• 100 : 백분율로 계산하기 위해 곱하는 값

계산한 값이 60이다. 이 60은 targetCPUUtilizationPercentage에 명시된 50보다 높기 때문에 오토 스케일링 대상이 된다. 오토 스케일링을 수행해서 파드가 2개가 되었다. 그런데 여기서 궁금한 점은 오토 스케일링 시, 파드를 몇 개까지 늘릴지는 어떻게 결정이 될까? 즉, 위 예시에서는 2개로 파드 개수를 늘리긴 했지만, 파드를 3개, 4개, ..., 10개로 늘리면 안될까? 이렇게 파드를 몇 개까지 늘릴지 결정하는 기준도 위 자료의 빨간색 글씨의 공식을 사용한다. 다만, 오토 스케일링 되었을 때의 파드 개수로 나누어 평균 값을 적용하여 결정한다.
 
예를 들어, 위처럼 파드를 2개로 오토스케일링 했을 경우, 계산 공식은 아래와 같이 재계산된다.
 

(300 + 300) / 1000 / 2 * 100 = 30

 
위 계산식도 각 숫자가 의미하는 바는 다음과 같다.

• (300 + 300) : 2개의 파드로 운영할 때의 리소스 사용량 합(1개의 파드 당 300m 리소스를 사용중)
• 1000 : 해당 파드에 request.cpu에 명시된 값
• 2 : 파드 개수
• 100 : 백분율로 계산하기 위해 곱하는 값

이처럼 파드가 여러 개일때 계산하는 공식은 여러 개수의 파드로 운영하고 있을 때 오토 스케일링을 적용할지 여부를 결정할 때도 계산 로직은 동일하다. 즉, 그림으로 표현하면 다음과 같다.
 

 
마지막으로, 직전에서 HPA가 오토 스케일링을 하는 기준으로 바라보는 파드의 CPU, 메모리 상태 값들을 metrics-server로부터 받아온다고 했다. 이 말은 결국 HPA가 metrics-server로부터 상태 값들을 받아오는 텀이 길어지게 되면 HPA는 오토 스케일링이 리소스 사용량을 빠르게 반영하는 속도가 늦어진다는 셈이다. 실제 HPA가 metrics-server로부터 상태 값들을 받아오는 구조는 다음과 같다. 
 

 
그래서 HPA 입장에서는 --horizontal-pod-autoscaler-sync-period 옵션으로 metrics-server 로부터 파드의 리소스 사용량 상태값을 가져오는 주기를 조절할 수 있다. 다만, metrics-server도 HPA에게 전달해주는 리소스 사용량 상태값들을 쿠버네티스 클러스터의 각 노드에 붙어있는 kubelet의 CAdvisor 서버로부터 가져오는 것이다. CAdvisor로부터 리소스 사용량 상태값들을 가져오는 주기는 기본적으로 60초인데, 이 또한 --metrics-resolution 옵션 값으로 조절이 가능하다. 하지만 kubelet의 CAdvisor도 실제 파드가 얼마나 리소스를 사용하고 있는지 상태값들을 가져오는 주기가 15초로 설정되어 있으므로 --metrics-resolution을 15초 이하로 설정하는 게 사실 상 의미가 없을 수 있다. 
 
이 모니터링 구조 부분은 추후에 배울 모니터링 즉, Prometheus, Grafana 개념을 배울 때 도움이 될 내용이므로 이번 포스팅에서 그냥 가볍게 읽고 넘어가도록 하자.