Home 7. kubernetes deploy State
Post
Cancel

7. kubernetes deploy State

kubernetes depoloy

Kubernetes 어플리케이션 상태와 배포

새로운 버전이 점진적으로 배포되는 롤링 업데이트 배포된 버전을 내부적으로 저장함으로써 원하는 버전의 디플로이먼트로 복귀 새롭게 배포되는 포드의 앱이 사용자 요청을 처리할 준비가 됐는지 확인

Deployment를 통한 rolling update

운영상의 앱인 경우, 보통은 deployment를 생성하고, 그 안에 속한 replicaset이 포드를 생성하는 것이 일반적이다. 이때 revision( –record 옵션 )을 통해 원하는 버전의 앱으로 롤백할 수 있다.

Recreate 방식은 기존 버전의 포드를 전부 삭제한 뒤, 새로운 버전의 포드를 생성하는 방식이며, rollingupdate의 경우 디플로이먼트를 업데이트 하는 도중에도, 사용자의 요청을 처리할 수 있는 포드가 계속 존재한다.

  • maxUnavailable
  • maxSurge

blue-green 배포

블루 그린 배포는 기존 버전의 포드를 그대로 놔둔 상태에서, 새로운 버전의 포드를 미리 생성해 두고 서비스의 라우팅만 변경하는 배포방식을 뜻한다. Service의 라벨을 변경하는 방식을 사용하면 쿠버네티스에서도 간단하게 구현할 수 있다.

Pod - Lifecycle

1
2
3
4
5
6
7
8
1) Pending
2) Running -
    - Init Container : 시작단게
    - postStart : 컨테이너 실행/삭제 시 특정 작정 수행
    - livenessProbe, readinessProbe : 상태검사
3) Completed
4) Error
5) Terminating -

Init Container가 차례대로 실행되고 -> 컨테이너 내부에서 postStart 훅이 실행되고 나야 -> Pod가 Running 상태로 바뀐다.

그 다음단계로, 사용자의 요청을 처리할 수 있는 상태인지를 판별하는 것이 livenessProbe, readinessProbe 이다.

  • livenessProbe : 컨테이너 내부 앱이 살아있는지(liveness) 검사
  • readinessProbe : 내부 앱이 사용자 요청을 처리할 준비가 됐는지(readiness) 검사.

반대로 Terminating의 경우는 다음과 같은 작업들이 이루어진다.

deletionTimestamp(리소스 삭제예정을 의미하는 값)이 포드의 데이터에 추가 -> 포드는 Terminating으로 바뀜 ->

1) prestop 훅 실행 2) 레플리카 관리영역에서 벗어남 3) 라우팅 대상에서 제외됨

-> SIGTERM이 컨테이너로 전달 (이때 init 프로세스 종료) -> 이후에도 종료 안되면 SIGKILL 시그널이 전달되어 강제종료

HPA Auto-Scaling

HPA(Horizontal Pod Autoscaler) : 리소스 사용량에 따라 디플로이먼트의 포드 개수를 자동으로 조절하는 기능

  • 하지만 잠시동안만 CPU를 소모하는 JVM 기반 APP의 경우, 포드 생성시간이 아닌, CPU 사용률을 기준으로 오토스케일링을 진행하기 때문에, 불필요하게 포드는 계속 스케일아웃 될것이고, 포드가 증식하는 연쇄작용을 불러일으킬 수도 있다.

Q1. 쿠버네티스는 포드를 생성할 때, master node에 디폴드로 설정한 [ ]를 통해 worker node 에 포드가 할당되게끔 한다.

Q2. Taints가 가지는 effect에는 NoSchedule, NoExecute, PreferNoSchedule 이 있다. 이 중에서 NoSchedule과 NoExecute 의 차이는 무엇인가?

Q3. drain 등으로 Eviction이 발생하는 경우, drain되는 포드개수를 1개로 유지하기 위해서는 어떻게 해야 하는가? ( 범용적으로는 일정한 비율로 유지하는데 사용하기도 함 )

Q4. 운영상에서 버전관리(원하는 버전으로 롤백 등)를 하기 위해, deployment에서 관리하는 replicaset의 변경사항을 저장한 것을 무엇이라 하는가?

Q5. Pod의 상태가 ‘Running’ 이 되기 위해서는 내부적으로 어떤 동작들이 이루어져야 하는가?

Q6. Pod의 상태가 ‘Terminating’ 이 되고 나서 유예기간이 지나도 여전히 프로세스가 종료되지 않는 경우, 프로세스로 어떤 시그널이 전달되는가?

Q7. 쿠버네티스에서 HPA를 통한 오토스케일링을 위해서는 어떤 도구를 별도로 설치해야하는가? 이유는?


A1. Taint (521pg) A2. NoSchedule은 노드에 설정하더라도 기존에 실행하던 포드는 정상적으로 동작한다. 하지만 NoExecute의 경우는 스케줄링도 하지 않을 뿐더러, 별도의 toleration이 설정되어 있지 않다면 해당 노드에서 실행 중인 포드를 아예 종료시킨다.(524pg) A3. PodDisruptionBudget을 정의하고, 설정으로 maxUnavailable( 혹은 minAvailable을 n-1로) 값을 1로 세팅한다. (531pg) A4. revision(537pg) A5. Init-Container 실행 , postStart 훅 실행 (552pg) A6. SIGKILL(559pg) A7. metrics-server, 사용중인 자원량(CPU, Memory등)에 대한 정보를 쿠버네티스가 자체적으로 수집하지는 못하기 때문.

This post is licensed under CC BY 4.0 by the author.