ref: 시작하세요 도커/쿠버네티스
디플로이먼트(Deployment)
레플리카셋, 포드의 배포를 관리한다.
1. 사용하기
레플리카셋만 사용해도 충분히 마이크로서비스 구조의 컨테이너를 구성할 수 있을 것 같지만, 실제 쿠버 운영 환경에서 레플리카셋을 yaml파일에서 사용하는 경우는 거의 없다.
대부분은 레플리카셋과 포드의 정보를 정의하는 디플로이먼트(Deployment)라는 이름의 오브젝트를 yaml파일에 정의해서 사용
따라서 포드와 함께 가장 많이 보게 될 오브젝트이다.
디플로이먼트는 레플리카셋의 상위 오브젝트임.
- 따라서 디플로이먼트를 생성하면 해당 디플로이먼트에 대응하는 레플리카셋도 함께 생성된다.
- 따라서 디플로이먼트를 사용하면 포드와 레플리카셋을 직접 생성할 필요가 없음.
오 개좋은데?디플로이먼트 생성 예시
레플리카셋의 yaml 파일이랑 비교해보면,
kind만 바뀌고 전체적인 건 거의 비슷함.
위의 yaml파일로 디플로이먼트 생성
kubectl apply -f [deployment 파일명]
kubectl get deployment
kubectl get deploy
응 이럴줄 알았어 한번에 해줄리가 없어...^^ㅋㅋㅋㅋㅋ ready 왜저래.. ㅠㅠㅠㅠㅠㅠㅠㅠ
는 그냥 배포중이었다고 한다. 조금 기다리니까 됐음
그러나 알아야 할 것은, 일정 개수의 포드가 유지되도록 생성하는 것은 레플리카셋이기 때문에, 실제로는 디플로이먼트와 함께 레플리카셋 또한 생성되어 있음.
아래에 있는 것은 지난번에 쓰고 안지운 5개짜리 레플리카셋
방금 deployment로 작성한 게 위에 있는 세개, 전에 레플리카셋으로 작성한게 아래 다섯개!
가운데 하나는 이전에 수동으로 올려본것..
디플로이먼트로부터 생성된 레플리카셋과 포드는 6b4b7f7cdc라는 특이한 해시값을 포함한 이름으로 생성되었음. 이 해시값은 포드를 정의하는 템플릿으로부터 생성된 것임. 자세한 것은 2번에서
2. 디플로이먼트를 사용하는 이유
쿠버는 왜 레플리카셋을 그대로 사용하지 않고 굳이 상위 개념인 디플로이먼트를 사용하는 걸까? 굳이 간접적으로 레플리카셋을 생성해서 쓰는 이유는?
나도 진짜 진심으로 이게 궁금했어디플로이먼트를 사용하는 핵심적인 이유 중 하나는 애플리케이션의 업데이트와 배포를 더욱 편하게 만들기 위해서이다.
이름에서 알 수 있듯, 디플로이먼트는 컨테이너 애플리케이션을 배포하고 관리하는 역할을 담당한다.
예를 들어 애플리케이션을 업데이트할 때 레플리카셋의 변경 사항을 저장하는 리비전(revision)을 남겨 롤백을 가능하게 해주고, 무중단 서비스를 위해 포드의 롤링 업데이트 전략을 지정할 수도 있다.
전에 봤던 롤백, 무중단 배포/수정을 가능케 하는게 디플로이먼트라는 소리인듯하다.
몇 개의 비슷한 포드를 만들어두고 하나씩 업데이트하는 거,
docker compose랑 다른 건 이런 차이점이라고 이해했었음.좀 더 쉬운 이해를 위해 디플로이먼트를 이용해 애플리케이션의 버전을 업데이트해 배포하는 간단한 (?) 예시를 알아보자.
이전과 동일한 yaml파일로 디플로이먼트를 생성하면서, --record라고 하는 옵션을 추가한다.
다음 버전에서는 --record가 없어질 거라는 메시지가 떴다.
근데 뭘로 바뀔거라는 말을 안해주네?여튼, 컨테이너 애플리케이션의 버전이 업데이트되어 포드의 이미지를 변경해야 한다고 가정했을 때, 디플로이먼트에서 생성된 포드의 이미지를 변경할 때는 kubectl get image 명령어를 사용할 수 있다.
자세히 설명하면, 포드 이미지 버전을 nginx:1.11로 변경하고 싶을 때,
kubectl set image deployment my-nginx-deployment \
nginx=nginx:1.11 --record띠용?
apply만 했을 때는 pods가 6b4b7f7cdc 세개만 보였는데, 업데이트를 하고 나니까
6b4b7f7cdc 이거는 하나밖에 안남고 55bbf495bd가 세개 생겼다.ㅋㅋㅋㅋㅋ
그리고 replicasets도 6b4b7f7cdc는 0개고 55bbf495bd가 3개 생긴 것을 확인할 수 있다.
55bbf495bd는 이미지를 업데이트함으로써 방금 새롭게 생성된 레플리카셋이고, 6b4b7f7cdc는 replicas의 값이 0으로 설정되어 포드를 생성하지는 않고 있지만 첫번째 생성했던 레플리카셋이 남아 있는 것을 알 수 있다.
이처럼 디플로이먼트는 새로운 레플리카셋으로 업데이트하면서도 이전 버전의 레플리카셋을 삭제하지 않고 남겨두고 있다.
즉, 포드의 정보에 변화가 생겼을 때 이전의 정보를 리비전으로써 보존한다.
리비전(revision) - 롤백하기
리비전 정보는
kubectl rollout history deployment my-nginx-deployment를 통해 확인할 수 있다.
--record=true옵션으로 디플로이먼트를 변경하면 변경 사항을 위와 같이 디플로이먼트에 기록함으로써 해당 버전의 레플리카셋을 보존한다.
롤백하고 싶다면 --to-revision=[롤백하고싶은 리비전 번호]을 사용할 수 있다.
kubectl rollout undo deployment my-nginx-deployment --to-revision=1
55bbf495bd가 떠있던 아까와 달리 6b4b7f7cdc가 떠있는 것을 알 수 있다.
포드 템플릿으로부터 계산된 해시값(6b4b7f7cdc)은 각 레플리카셋의 라벨 셀렉터(matchLabels)에서 pod-template-hash라는 이름의 라벨값으로서 자동으로 설정된다.
따라서 여러 개의 레플리카셋은 겹치지 않는 라벨을 통해 포드를 생성할 수 있다.
쿠버 리소스의 자세한 정보를 출력해보자.
kubectl describe deploy my-nginx-deployment
--record를 사용하지 않아도 이전의 레플리카셋은 보존되지만, 어떤 명령어를 통해 변경됐는지 기록하는 CHANGE-CAUSE 항목에 < NONE >으로 표시가 된다. 따라서 가능하다면--record를 사용하는게 좋다는데 이제 명령어가 없어진다고 한다.
그럼 그냥 써도 record 옵션을 넣은 것처럼 되는건가?
이처럼 디플로이먼트는 여러 개의 레플리카셋을 관리하기 위한 상위 오브젝트이다.
디플로이먼트를 사용하면 레플리카셋의 리비전 관리뿐만 아니라 다양한 포드의 롤링 업데이트 정책을 사용할 수도 있다는 장점이 있다.
