Deployment , ReplicaSet , pods 계층적인 구조를 이루는 것을 확인
kind 이름 만 빼고 다 똑같다. ReplicaSet 의 부모이기 때문이다.
deployment를 실행시키니 이에 해당하는 replicaset도 저절로 생겨났다.
이름을 보면 deploy-nginx , replicaset , pod 순으로 구성된것을 확인할 수 있다. 동일한 deployment , 동일한 replicaset 서로다른 3개의 pod가 생겼구나 를 확인
Rolling Update = pod instance들을 점진적으로 업그레이드하여 서비스 중단 없이 배포를 하는것
set 명령어를 통해 rolling update 를 하게 된다.
새로운 replicaset yyy 를 생성하고 처음에는 replicas = 1 로 설정되어 업그레이드 용 pod 1.15 를 실행시킨다.
deployment 가 replicaset xxx의 replicas=2 로 변경하여 1개의 pod를 terminate시킨다.
이 과정을 반복하여 xxx는 0개 yyy는 3개가 될때까지 반복한다.
--record 로 기록을 해두어야 kubectl rollout history deployment app-deploy했을때 히스토리를 볼 수 있다.
위의 과정이 순식간에 일어난다. 차례대로 Terminating 된것을 볼 수 있다.
deployment.apps/ , pod/ 이런것은 resource type이다.
rollout status 명령어를 통해 진행 상황을 알 수 있다. 굉장히 빨리 쳐야한다.
rollout pause, resume 으로 중간에 멈추거나 다시 실행 시킬 수 있다.
history 들이 쭉 남게 된다.
yaml 파일로 rolling update 를 해보자
revisionHistoryLimit = 위의 히스토리를 몇개까지 가져갈꺼냐
progressDeadlineSeconds = 업데이트가 특정 시간이 넘어가면 업데이트를 취소 시킨다.
maxSurge = rolling update도중에 최대 몇개까지 가져갈 것이냐? 위의 공식 처럼 계산한다. 25%면 아까처럼 replicas =3 일떄 1개씩 new pod 돌리고 (그러면 현재 4개가 running) 그러면 1개의 old pod 죽임
50% 면 replicas = 3일떄 2개씩 new pod 돌리고 2개의 old pod 를 죽임
올라갈수록 업데이트 속도가 빨라진다.
maxUnavailable = 위와 동일한데 terminating 되는 pod의 갯수를 정한다. 위에것은 running에 관한것
rollback 을 해보자
revision 3 이 revision 6으로 이동된것을 확인
to revision 을 안쓰게 되면 바로 전 단계로간다. 근데 계속 쓰면 그냥 최근 버젼 이랑 바로 전 버젼을 와리가리 할 뿐이다. ㅋㅋㅋ
annotations 을 통해 kubectl history 를 간결하고보기좋게 할 수 있다.
yaml 을 통해 rolling update를 하면
kubectl apply -f depolyment-exam2.yaml 을 통해 실행을 하게 되는데 처음에는 annotatons 도 1.14, image: nginx 1.14 이거를 1.15바꾸고 실행하면 rolling update가 된다.
history 가 깔끔하게 남는다.