11.3.1 디플로이먼트를 통해 롤링 업데이트

디플로이먼트를 이용한 레플리카 셋이 버전 관리 디플로이먼트를 사용하는 이유 : 리비전 관리 kubectl apply -f deployment.yaml --record kubectl rollout history deployment <deployment name>

디플로이먼트를 통한 롤링 업데이트 설정 배포 전략(strategy type)

recreate
- 기존 버전의 포드를 모두 삭제한 디 새로운 버전의 포드를 생성. 일시적으로 중단 발생
rollingupdate
- 디플로이먼트의 기본 배포 전략
- 포드를 조금씩 삭제하고 생성
- 옵션
- maxSurce : 롤링 업데이트 도중 전체 포드의 개수가 디플로이먼트의 replica 값 보다 얼마나 더 많이 존재할 수 있는지 설정. 새로운 포드가 얼마나 많이 생성될 수 있는지를 의미.
- maxUnavailable : 롤링업데이트 중 사용 불가능한 상태가 되는 포드의 최대 개수. 배포 도중 실행되어야 할 포드 개수 설정.
bluegreen
- 기존 버전의 포드를 놔둔 상태에서 새로운 버전의 포드를 미리 생성해 둔 뒤 서비스의 라우팅만 변경하는 배포 방식.
- 특정 순간에 두 버전이 애플리케이션이 공존하지 않음
- 중단 시간이 발생하지 않음
- 특정 순간에는 디플로이먼트에 설정된 replica 보다 두배 많은 포드가 실행되기 때문에 일시적으로 전체 자원을 많이소모할 수 있음
canary
- 사용자의 범위를 늘려가며 피드백을 통해 배포하는 방식

11.3.2 포드의 생애 주기(Lifecycle)

pending : 생성하는 요청은 승인됐지만, 실제로 생성되지 않은 상태. ex) 노드에 스케줄링되기 전.
running : 포드가 정상적으로 실행된 상태. 제일 바람직한 형태
completed : 포드가 정상적으로 종료. (init process의 종료코드가 0)
error : 포드가 정상적으로 실행되지 않은 상태로 종료. (init process의 종료코드가 0이 아님)
terminating : 포드가 삭제 또는 퇴거 되기 위한 상태에 머물러있는 경우

Completed, Error와 restartPolicy

restartPolicy
- pod 설정 파일에 설정 (spec.restartPolicy)
- 옵션
- Always : 포드의 컨테이너가 종료됐을 때 자동으로 다시 시작
- Never : 포드가 종료되어도 다시 시작하지 않음
- OnFailure : error 상태인 경우에만 다시 시작
- pod이 다시 시작할 때 CrashLoopBackOff 상태에 잠시 머무르게 된다. 실패를 반복할수록 CrashLoopBackOff에 머무는 시간이 늘어난다.

11.3.2.2 Running 상태가 되기 위한 조건

컨테이너이 애플리케이션이 정상적으로 동작한다는 것을 보장하기위한 기능

init container
postStart
livenessProbe, readinessProbe

Running 상태가 되기 위한 조건 - Init 컨테이너 포드의 컨테이너 내부에서 애플리케이션이 실행되기 전에 초기화를 수해아는 컨테이너. 포드의 애플리케이션ㅇ 컨테이너가 실행되기 전에 특정 작업을 미리 수행하는 용도로 사용. 다른 디플로이먼트가 생성되기를 기다릴 수도 있다. pod 정의 spec.initContainers에 container 옵션과 동일하게 작성

Running 상태가 되기 위한 조건 - postStart 포드의 컨테이너가 실행되거나 삭제될 때, 특정 작업을 수행하도록 라이프사이클 훅을 yaml spec.containers.licecycle.poststart에 설정할 수 있다. 단, postStart는 컨테이너의 Entrypoint와는 비동기적으로 실행되며, 어떠한 것이 먼저 수행된다는 보장은 없다.

postStart의 방식

Http : 컨테이너가 시작한 직후, 특정 주소로 HTTP 요청 전송
Exec : 컨테이너가 시작한 직후, 컨테이너 내부에서 특정 명령어를 실행

11.3.2.3 애플리케이션의 상태 검사 - livenessProbe, readinessProbe

애플리케이션이 사용자의 요청을 처리할 수 있는 상태인지 판별하기 이해 spec.containers.livenessProbe, spec.containers.readinessProbe를 제공.

livenessProbe : 컨테이너 내부의 애플리케이션이 살아있는지 확인. 검사에 실패할 경우 해당 컨테이너는 restartPolicy에 따라서 재시작.
readinessProbe : 컨테이너 내부의 애플리케이션이 사용자의 요청을 처리할 준비가 됐는지 검사. 검사에 실패할 경우 컨테이너는 서비스 라우팅 대상에서 제외.

검사 방식

httpGet : Http 요청을 전송해 상태를 검사
exec : 컨테이너 내부에서 명령어를 실행해 상태 검사
tcpSocket : tcp 연결이 수립될 수 있는지 체크.

세부 옵션

preidSeconds : 상태 검사 진행할 주기를 설정. 기본 10초
initialDelaySeconds : 포드가 생성된 뒤 상태 검사를 시작할 때까지의 대기 시간 설정. 기본 값은 없음
timeoutSeconds : 요청에 대한 타임아웃 시간 설정. 기본 1초
successThreshold : 상태 검사에 성고앴다고 간주할 검사 성공 횟수. 기본 1
failuerThreshold : 상태 검사가 실패했닫고 간주할 검사 실패 횟수를 설정. 기본 3

11.3.2.4 Terminatin 상태와 애플리케이션의 종료

기존 법전의 포드를 무사히 종료시키는 것도, 새로운 포드가 준비됐는지 확인하는 것 만큼이나 중요하다. 애플리케이션 단에서도 graceful shutdown을 위한 준비가 필요하다. (db connection 정리하기 등)

포드 삭제 시나리오

리소스가 삭제될 예정이라는 의미의 deletionTimestamp 값이 포드의 데이터에 추가되고, 포드는 Terminating 상태로 전환
아래 작업 동시에 실행
1. prestop hook 실행
2. 포드가 레플리카 셋으로부터 생성된 경우 해당 포드는 레플리카 셋의 관리 영역에서 벗어나며, 레플리카 셋은 새로운 포드를 생성하려고 시도
3. 포드가 서비스 리소스의 라우팅 대상에서 제외
preStop 훅이 완료되면 리눅스 시그널 중 SIGTERM이 포드의 컨테이너에 전달. 컨테이너의 init 프로세스는 SIGTERM을 수신한 뒤 종료되어양 함.
특정 유예 기간(terminationGracePeriodSeconds, 기본 30초)이 지나도 컨테이너 내부의 프로세스가 여전히 종료되지 않으면 프로세스 SIGKILL 시그널이 전달.

사용자는 prestop, SIGTERM 시그널 핸들러를 설정해서, 어떤 행동을 취할 것인지 별도의 장치를 마련할 수 있다.

11.3.3 HPA를 활용한 오토스케일링

리소스 사용량에 따라 디플로이먼트 포드 개수를 자동으로 조절하는 기능을 제공한다. HPA를 사용하기 위해서는 metrics-server라는 리소스 메트릭 수집 도구가 필요하다.

apiVersion: autoscaling/v1
kind: HorizontalPidAutoscaler
metadata : 
    name : <hpa name>
spec:
    scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: <deployment hostname>    # 해당 서버에서
    targetCPUUtilizationPercent: <cpu 사용량> # cpu 활용율이 <cpu 사용량> 이상이면
    maxReplicas: <num> # 포드를 최대 <num> 까지
    minReplicas: <num> # 포드를 최소 <num> 까지

주의할 점 : targetCPUUtilizationPercent : 포드의 절대적인 리소스 사용량이 아닌 포드에 할당된 request 대비 얼마나 리소스를 사용하고 있는지를 기준으로 삼는다. (모든 포드의 현재 사용량/request 의 평균값을 기준으로)

JVM 등, 일시적으로 cpu를 과도하게 사용하는 경우라면 오토 스케일이 좋은 선택은 아니다. 쿠버네티스 컨트롤러에서 매니저(kuve-controller-manager)에서 --horizontal-pod-autoscaler-sync-period 갑슬 수정해서 포드 개수 싱크 주기를 설정할 수 있다.

engal1991 / Docker-Kubernetes