배경
쿠버네티스 기본 구성 중 중요한 객체들이 있습니다.
Pods, Deployment, Services, Volume 등이 있고 이런 객체들은 쿠버네티스의 명령이 실행되면서 생성됩니다.
우선 앞에서 보았던 Pod가 있습니다. Pod에서 중요한 개념이 있습니다. 바로 'Pod는 임시적'이라는 것입니다. Pod가 쿠버네티스에 의해 관리되면서 교체되거나 삭제되면 컨테이너를 포함한 Pod의 모든 리소스는 삭제됩니다.
물론 볼륨 스토리지를 통해 유지할 수 있지만 디폴트로는 손실됩니다. 새로운 내용으로 보기보다는 컨테이너 특성과 비슷하게 여길 수 있습니다.
그렇다고 일일이 컨테이너를 관리한다면 쿠버네티스가 필요없습니다. 그래서 Pod를 우리가 생성하는 것이 아닌 deployment 객체를 만들게 됩니다.
deployment 객체
deployment 객체는 pod 객체를 생성하고, 생성 및 관리가 필요한 pod, container 수를 제시하고 제어합니다. 즉, deployment 객체를 통해 pod 객체를 자동 생성 및 관리합니다.
deployment 객체가 pod 객체를 만들고 이는 워커 노드로 이동하게 됩니다. 워커 노드에는 pod를 실행하기 위한 CPU와 메모리가 충분할 것입니다.
그리고 deployment를 일시 중지하거나 삭제, 롤백할 수 있습니다. 그 과정에서 오류가 나더라도 이전에 작동했던 deployment롤 돌아갈 수 있습니다.
또 다른 장점은 deployment는 오토 스케일링이 된다는 점입니다. 수신 트래픽과 CPU 사용률 메트릭을 설정하면 기준 초과시 더 많은 pod를 생성하고 부하가 줄어들면 pod 수도 줄어들게 됩니다.
deployment 생성
minikube가 실행된 상태에서 터미널에 다음을 입력합니다.
kubectl create deployment <deployment_name> --image=<docker_hub_image>위 명령어를 통해 이미지를 불러와 minikube에 deployment 객체를 생성합니다.
이미지 옵션에서 보면 도커 허브의 이미지를 불러오는데, 도커 허브의 이미지는 공유될 수 있기 때문입니다.
minikube가 로컬의 가상머신에서 실행되는 상태이긴 하지만 로컬 호스트 상으로 인식하지 않고 별개의 머신으로 대하기 때문에, 로컬 이미지를 적용하지 못하고 도커허브를 통해 이미지 공유를 합니다.만약 로컬이미지를 불러와서 실패했다면
kubectl delete deployment <deployment_name>을 통해 삭제하면 됩니다.
잘 생성되었는지 확인하려면 minikube status 또는 minikube dashboard를 통해 확인할 수 있습니다. 두번째 명령어는 상세정보를 웹페이지로 띄워주기 때문에 가시적이지만 딜레이가 살짝 있습니다.
scaling
이렇게 생성된 컨테이너는 모니터링되고 실패시 종료 후 새로운 컨테이너가 재시작됩니다.
이 때 쿠버네티스는 무한 루프를 방지하기 위해 재시작을 할 때 마다 대기시간을 점점 더 오래 대기합니다.
그리고 명령어를 통해 스케일링을 설정할 수 있습니다.
$ kubectl scale deployment/<deployment_name> --replicas=<pods_count>이렇게 실행상태에 놓을 pod 갯수를 지정할 수 있습니다.
rebuild
코드를 수정하고 다시 쿠버네티스의 deployment에 보내야 하는 경우에 업데이트 하는 방법입니다.
우선, 수정된 컨테이너 이미지를 도커 허브에 푸쉬합니다. 그리고 set image명령어를 사용합니다.
$ kubectl set image deployment/<deployment_name> <now_image_name>:<tag>=<new_image_name>:<tag>여기서 태그는 필수입니다. 만약 태그가 없고 이전 사용된 이미지와 같은 이름이라면 쿠버네티스는 업데이트까지 하긴하지만 변경사항을 감지하지 못하고 이전과 같은 이미지를 주게됩니다. 태그를 등록합시다!
Rollback & History
deployment가 정상적으로 실행되지 않는 경우가 생길 수 있습니다. 바로 위에서 set image를 할 때 없는 태그를 써버리는 실수를 했다고 해보겠습니다.
$ kubectl rollout status deployment/<deployment_name>이 명령어를 통해 현재 진행중인 deployment의 진행중인 작업을 알 수 있습니다. 태그를 잘못썼다면 완료되기를 계속 기다리고 있을 것입니다.
minikube dashboard를 통해 확인할 수도 있습니다.
아마 새로운 이미지를 가져오더라도 이전 pod가 종료되지 않는 것을 볼 수 있습니다. 쿠버네티스의 실행 전략 덕분에 이전의 문제없는 pod로 진행중인 것입니다. 이제 다음 명령어를 통해 잘못 적용된걸 롤백합니다.
$ kubectl rollout undo deployment/<deployment_name>최근의 deployment가 undo 됩니다. 그리고 바로 이전의 버전의 deployment로 돌아가게 되는데 옵션을 통해 더 이전의 버전으로 돌아갈 수 있습니다.
우선 history 명령어로 원하는 revision을 찾고, undo 명령어에 --to-revision옵션을 달아줍니다.
$ kubectl rollout history deployment/<deployment_name>
[출력 결과]
REVISION CHANGE-CAUSE
1 <none>
2 <none>
4 <none>
$ kubectl rollout undo deployment/<deployment_name> --to-revision=1
무사히 실행되었더라도 아직 접근하지 못합니다. 앞에서 컨테이너의 외부 노출은 service 객체를 통해 가능하다고 했습니다.
다음 글에서 service를 다루면서 컨테이너와 통신해보겠습니다.
