kubernetes - pod & deployment

 Pod

• 쿠버네티스에서 다루는 가장 작은 유닛이다.
• 파드는 컨테이너를 보유하고 있고, 쿠버네티스는 이러한 파드와 컨테이너를 관리한다.
• 파드는 하나 이상의 컨테이너를 가진다.
• 파드는 컨테이너에서 활용하는 볼륨과 같은 공유 리소스 역시 가지고 있다.
• 클러스터 외부에서도 파드와 통신할 수 있다.
• 파드는 컨테이너와 같이 임시적이며 제거하거나 교체하면 모든 상태를 잃는다.

 

 

deployment

• 개발자는 쿠버네티스에게 파드를 자동으로 생성, 제거, 교체하기를 지시할 수 있다.
• 이는 쿠버네티스 사용의 핵심 아이디어이다.
• 개발자는 수동으로 pod 객체를 생성하여 특정 워커 노드에 할당하지 않다.
  • 그럴 거면 쿠버네티스를 쓸 이유가 없다.
• 대신 deployment 객체를 생성한다.
• deployment 객체에게 생성하고 관리해야 할 파드와 컨테이너 수에 대한 지침을 제공한다.
• deployment 객체는 하나 이상의 파드를 제어할 수 있으며, 지침에 따라 스스로 파드, 컨테이너를 생성하고 관리한다.
• deployment 객체를 사용하면 배포를 일시 중지하거나, 삭제하고, 롤백할 수 있다.
• deployment 역시 오토 스케일링을 설정할 수 있다.

 

 

deployment 객체의 역할

• 현재 실습에 사용 중인 노드 서버의 app.js 파일이다.
• /error로 의도적인 에러를 발생시킬 수 있다.

 

• 현재 클러스터 안의 파드에서 실행 중인 노드 앱이다.

 

• /error라는 url로 접속하니 서버가 다운되었다.
  • 이는 의도적으로 에러를 일으킨 것이다.

 

kubectl get pods

• 의도적으로 서버를 다운시킨 후 몇 초 간격으로 계속 pods의 상태를 모니터링하자 STATUS가 Error였다가 새롭게 Running으로 바뀌는 것을 확인할 수 있었다.
• 아무것도 설정하지 않았는데 에러로 중단되었던 파드가 다시 실행되는 것이다.
• 이는 deployment 객체를 생성했기 때문에 발생하는 동작이다.
  • deployment 객체가 파드나 컨테이너, 애플리케이션이 실패했을 때 다시 생성되며 파드는 컨테이너를 재시작해야 한다고 스스로 결정한 것이다.

 

minikube dashboard

minikube dashboard

• minikube dashboard에 들어가 이벤트를 확인해 보면 에러가 발생한 후 이미지를 도커허브에서 다시 당겨와 컨테이너를 만들고 실행하는 부분까지 스스로 작동하고 있음을 확인할 수 있다.

 

• 서버는 다시 정상적으로 작동하고 있다.

 

 

스케일링(Scaling)

• 현재 파드는 한 개가 작동중에 있다.

 

kubectl scale deployment/first-app --replicas=3

• replica는 파드의 인스턴스를 뜻한다.
• kubectl scale 명령어를 사용하여 파드의 인스턴스 개수를 2개 더 늘렸다.
• 원래 가지고 있던 파드(74hp4) 이외에 2개의 파드가 더 생겼음을 확인할 수 있다.
• 3개의 파드 모두 동일한 컨테이너를 실행하고 있다.
• 로드 밸런서가 있어 트래픽이 발생할 때 고르게 분산된다.

 

로드 밸런싱 테스트

• minikube dashboard를 통해서도 파드가 세 개 정상적으로 Running 상태임을 확인할 수 있다.

 

• 고의적으로 에러를 발생시켜도 모든 파드가 죽지 않는다면 살아있는 파드로 트래픽이 분산된다.

 

• 하나의 파드가 살아있어 정상적으로 작동하는 모습을 확인할 수 있다.

 

 

deployment 객체 업데이트 하기

• 현재 앱 메인 화면의 글자를 수정해보았다.

 

• 이미지를 재빌드 하고

 

docker push wonyongg/kub-first-app

• docker push로 docker hub에 있는 레파지토리에 변경 사항을 반영한다.

 

kubectl set image deployment/first-app kub-first-app=wonyongg/kub-first-app

• 그다음 set image 명령어를 사용하면?
• 아무런 변화가 없다.
• 이유는 deployment 객체가 새로운 이미지에 태그가 기존의 태그와 다른 경우에만 새 이미지를 다운로드하기 때문이다.
• 따라서 위의 과정에 전부 새로운 태그를 붙여야 한다.

 

docker build -t wonyongg/kub-first-app:2 .
docker push wonyongg/kub-first-app:2
kubectl set image deployment/first-app kub-first-app=wonyongg/kub-first-app:2

• 기존 이미지에 2라는 태그를 달아 이미지를 다시 build -> push 하고
• set image로 기존의 deployment 객체에 업데이트해 주었다.  

 

• 정상적으로 업데이트된 이미지가 반영됨을 확인할 수 있다.

 

• Minikube dashboard에서도 태그 2의 이미지를 docker hub에서 당겨와 컨테이너를 실행했음이 기록되어 있다.

 

 

deployment rollback

kubectl set image deployment/first-app kub-first-app=wonyongg/kub-first-app:3
kubectl rollout status deployment/first-app

• 이번에는 존재하지 않는 태그의 이미지를 사용하여 deployment의 이미지를 업데이트하는 방식으로 고의적으로 에러를 발생시킨 다음 롤백하는 과정을 진행했다.
• 기존의 태그 2 이미지를 연결한 상태에서 rollout status를 통해 deployment의 업데이트 상태를 확인해 보니 deployment "first-app" successfully rolled out이라고 나오는 걸 확인할 수 있다.
  • 참고로 kubectl rollout status는 업데이트 상태를 확인하는 명령어이다.
• 다음으로 docker set image를 이용하여 등록되지 않은 태그 3 이미지를 deployment 객체의 새 이미지로 세팅해 보았다.
• 태그 3으로 이미지를 세팅하고 rollout 해보니 Waiting for deployment "first-app" rollout to finish: 1 old replicas are pending termination...이라고 나온다.
  • 해석을 해보면 deployment가 끝나기를 기다리고 있다, old replicas(오래된 레플리카)가 종료되고 있다는 뜻이다.
  • 업데이트는 에러로 인해 강제로 중지하지 않는 이상 끝나지 않아 ctrl + c로 직접 종료해야 한다.

 

• Minikube dashboard에서 파드를 확인해 보니 2로 설정한 이전 태그의 이미지는 작동 중이고
• 새롭게 3으로 설정한 존재하지 않는 태그의 이미지는 Imagerpull 에러가 발생했음을 알 수 있다.
  • 3이라는 태그로 이미지를 빌드한 적이 없으니 당연한 결과이다.
• 새 파드가 기존 파드를 대체할 수 없기 때문에 기존 파드가 여전히 작동 중이다.

 

kubectl rollout undo deployment/first-app

• undo 명령어를 실행하니 원래로 돌아왔다.

 

kubectl rollout history deployment/first-app

• history를 사용하면 지금껏 deployment 객체가 변화된 이력을 확인할 수 있다.

 

Kubectl rollout history deployment/first-app --revision=1

• --revision을 붙이면 이력 내용까지 확인이 가능하다.

 

kubectl rollout undo deployment/first-app --to-revision=1

• --to-revision으로 해당 이력의 deployment 객체로 돌아갈 수도 있다.

 

 

 

참고

Udemy - Docker & Kubernetes : 실전 가이드