개발/구름

[쿠버네티스 인 액션] 09. rollout과 readinessProbe

소년택이 2021. 7. 16. 14:10

클러스터를 구성하는 container가 생성 즉시 가용상태가 된다고 보장할 수 없다. 어떤 container는 만듬과 동시에 가용할 수도 있고, 어떤 container는 일정 시간이 경과해야 가용할 수 도 있다. 또 다른 container는 초기에는 거짓으로 가용한것 처럼 보여주므로 일정 시간 이후 부터 가용성을 확인해야 할 수도 있다. k8s는 가용성을 판별하기 위한 readinessProbe와 무분별한 rollout 진행을 막기 위한 minReadySeconds 설정 등을 제공하고 있다.

rollout 레벨

minReadySeconds를 지정하면 새 pod 생성 후 해당 시간만큼 rollout을 중지한다. 어떤 pod가 초기화 하는데 t 시간이 반드시 필요하다면 그만큼을 minReadySeconds로 지정하는것이 타당하다. 새로 만든 pod의 가용성을 확인하기도 전에 다음 rollout 단계를 밟으면 - pod에 결함이 있는 경우 - 클러스터 전체를 update 하고나서 전혀 요청을 받지 못하는 대참사가 일어날 수 도 있다. 다만 readinessProbe가 없는 경우 minReady Seconds는 rollout 속도를 늦추는 것 외이는 아무 역할을 하지 않는다. progressDeadlineSeconds는 rollout의 타임아웃을 지정한다. 이 시간을 경과하면 timeout 오류가 남고 kubectl rollout status {...}를 수행중이었다면 종료한다. rollout 자체를 임의로 조작하지는 않으므로 관리자가 수작업으로 처리를 해야한다.

.spec.minReadySeconds

  • 새 pod 생성 후 지정한 시간동안 rollout을 중지한다.
  • minReadySeconds 이후 부터 pod의 READY를 확인하는 시점에 다음 단계로 넘어간다.
  • minReadySeconds 경과 후 pod가 UNREADY > READY 상태로 변경된다면 다음 단계로 넘어간다.
  • 한번 readiness를 확인한 pod에 미련을 가지지 않는다.

.spec.progressDeadlineSeconds

 

  • 지정한 시간을 경과하면 timeout 경고를 기록한다.
  • rollout을 임의로 중단하지 않으며 대기 상태로 놔둔다.
  • 비록 progressDeadlineSeconds를 경과해도 pod가 READY 상태가 되면 rollout을 계속 수행한다.
  • progressDeadlineSeconds는 반드시 minReadySeconds보다 커야 한다.

readiness에 따른 rollout 순서도

 

pod레벨

k8s은 pod 단위로 서비스에 투입한다. UNREADY 상태의 pod는 service에서 배제하여 요청을 받지 못하도록 한다. 단 주의해야 할 점은 readinessProbe는 container 단위로 지정한다는 것이다. 복수의 container가 존재하는 경우 모두 READY 상태여야 pod의 상태를 READY로 판단한다. 단 여기서는 설명을 용이하게 하기 위해 pod:container = 1:1로 가정하고 설명한다.

k8s는 원칙적으로 readinessProbe를 성공해야 pod의 상태를 READY로 판정한다. 하지만 readinessProbe를 지정하지 않았다면 이 pod는 생성과 동시에 READY 한 것으로 가정한다. pod의 상태는 앞서 설명한 rollout의 속행 여부를 판단하는 중요한 기준이기도 하며 동시에 service에서 해당 endpoint에 서비스 요청을 전달할것인지 여부를 판단하는 기준이기도 하다.

service에서 특정 pod를 배제한 상태

비록 service에서 pod를 배제했지만 k8s는 계속해서 readinessProbe를 수행하다가 pod가 ready 상태가 되면 다시 서비스에 투입한다. 

참고.
pod의 서비스 투입은 전적으로 readinessProbe에 따르며, 앞서 설명한 rollout 파라미터들과는 무관하다.

 

.spec.containers.readinessProbe

  • container의 READY 상태를 판별하는 방법을 정의한다.
  • readinessProbe를 정의하지 않는다면 해당 container는 항상 READY 한것으로 간주한다.

.spec.containers.readinessProbe.initialDelaySeconds

  • container 생성 후 첫 readinessProbe 까지의 지연시간을 지정한다.
  • container 초기화 단계에서 readinessProbe가 무의미한 경우 지정한다.
  • FALSE READY / FALSE UNREADY를 방지할 수 있다.
  • initialDelaySeconds 동안 container는 UNREADY 상태를 유지하므로 요청을 받지 않는다.

.spec.containers.readinessProbe.periodSeconds

  • 기본값 10, 최솟값 1
  • readinessProbe를 수행하는 주기를 지정한다.
  • 서비스 투입/배제 여부와 상관없이 POD가 살아있는 한 readinessProbe는 계속 된다.

.spec.containers.readinessProbe.failureThreshold

  • 기본값 3, 최솟값 1
  • conatiner가 READY > UNREADY 되기 까지 연속하여 허용할 readinessProbe failure의 횟수를 지정한다.
  • 만약 container가 READY 상태라면 해당 횟수만큼 failure를 허용한다.
  • 해당 횟수에 도달하면 container는 UNREADY 상태가 된다.

.spec.containers.readinessProbe.successThreshold

  • 기본값 1, 최솟값 1
  • container가 UNREADY > READY 되는데 필요한 연속 readinessProbe success 횟수를 지정한다.
  • 만약 container가 UNREADY 상태라면 해당 횟수만큼 readinessProbe를 성공해야 READY 상태가 된다.
  • failureThreshold와 반대 역할이다.

readinessProbe 순서도

1 2 3 4 5 6 7 ··· 9