Deployment 과 ReplicaSet 무슨 차이?
ReplicaSet이 replicas를 조절하면서 pod의 수를 조절하는데 왜 굳이 Deployment를 사용할까?
deployment는 pod의 수를 조절하기 위함이 아닌 replicaSet을 버전에 따라 관리하기 위함이다.
Deployment => ReplicaSet => Pod
label이 같은 2개의 deployment가 배포되면, selecting은 어떻게?
2개의 deployment가 동일한 label이 붙어 배포되더라도, 이 둘은 독립적으로 관리되고 배포된다.
replicaset을 describe 해서 selector 필드를 확인해보면 pod-template-hash라는 값이 부여되어 있다. replicaset은 이 pod-template-hash 값을 이용해서 pod가 자신의 pod인지 다른 replicaset의 pod인지 구분하여 관리한다.
마찬가지로 deployment 또한 replicaset을 hash값을 통해서 관리하며,
다음과 같은 구조를 통해서 deployment는 replicaset을, replicaset은 pod를 관리한다.
Deployment[test] ⇒ ReplicaSet[test-106449474] ⇒ Pod[test-106449474-abcde]
Rollout 속도 통제하기
maxSurge와 maxUnavailable를 이용하여 한번에 대체되는 Pod의 수를 조절한다.
- maxSurge: 존재를 허용하는 최대 pod 수
- maxUnavailable: 사용할 수 없는 최대 pod 수
minReadySeconds VS Readinessprobe
-
minReadySeconds
- 앱이 Ready 상태가 되기까지 최소 기다리는 시간을 지정해주며, 설정된 시간동안 트래픽을 받지 않는다.
- 준비가 완료되기전가지 rollout 프로세스가 진행되지 않는다.
- App 특성상 health check를 할 수 없으면, readinessprobe 대신 사용하기도 한다.
-
readinessProbe
- pod가 Ready 상태가 되었는지 health check를 하며, readinessProbe가 ok 상태여야 트래픽을 받을 수 있게 된다.
- readinessProbe의 check가 완료되면, minReadySeconds의 설정은 무시되고 트래픽을 허용한다.
Graceful shutdown 구현
Rollout 중 pod가 종료되어야 하는 상황에서 Kubelet은 먼저 pod에 SIGTERM 신호를 보낸다.
SIGTERM을 받은 pod는 기존에 처리중이던 요청을 마무리한 후, 새로운 요청을 받지 않도록 개발되어야 한다.
kubelet이 pod에 SIGTERM을 보낸 후에도 일정시간(terminationGracePeriodSeconds/default 30초) 동안 shutdown이 되지 않는다면, kubelet은 SIGKILL을 보내 강제로 pod를 종료시킨다.
Reference
