본문 바로가기
Server-side 개발 & 트러블 슈팅/🚢 Kubernetes (쿠버네티스)

[minikube] 쿠버네티스 디플로이먼트(Deployment)를 이용한 롤링 베포, 롤백 가이드 (rolling, rollout)

by 코딩하는 동현 2025. 4. 30.

쿠버네티스 Deployment(디플로이먼트) 이해와 활용 가이드

쿠버네티스에서 Deployment는 포드를 관리하는 가장 일반적인 방법이다. 레플리카 세트의 기능을 확장하여 애플리케이션의 지속적인 배포와 업데이트를 가능하게 해주는 리소스이다. 이 글에서는 디플로이먼트의 개념, 구조, 그리고 실제 활용 방법에 대해 상세히 알아보도록 한다.

디플로이먼트란 무엇인가

디플로이먼트는 쿠버네티스에서 기본적으로 레플리카 세트를 관리하는 더 고급 수준의 컨트롤러이다. 레플리카 세트의 모든 기능을 포함하면서 추가로 롤링 업데이트와 롤백과 같은 배포 관련 기능을 제공한다. 가장 큰 장점은 가동 중지 시간 없이 애플리케이션을 업데이트할 수 있다는 점이다.

디플로이먼트는 레플리카 세트를 생성하고 관리하며, 레플리카 세트는 포드를 생성하고 관리한다. 이렇게 계층적인 구조를 통해 애플리케이션의 배포와 확장을 더욱 유연하게 제어할 수 있다.

디플로이먼트의 구조

디플로이먼트의 기본 구조는 레플리카 세트와 매우 유사하다. 아래는 기본적인 디플로이먼트 YAML 파일의 구조이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  selector:
    matchLabels:
      app: webapp
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: richardchesterwood/k8s-fleetman-webapp-angular:release0-arm64

디플로이먼트의 주요 필드는 다음과 같다:

  • replicas: 유지해야 할 포드의 개수
  • selector: 디플로이먼트가 관리할 포드를 선택하는 기준
  • template: 생성할 포드의 템플릿 정의

여기에 롤링 업데이트를 조정하기 위한 추가 필드들도 사용할 수 있다:

  • minReadySeconds: 새로 생성된 포드가 사용 가능한 상태로 간주되기 전에 대기해야 하는 최소 시간(초)
  • strategy: 업데이트 전략 (RollingUpdate가 기본값)
  • rollingUpdate.maxUnavailable: 업데이트 중 사용할 수 없는 최대 포드 수
  • rollingUpdate.maxSurge: 업데이트 중 추가로 생성될 수 있는 최대 포드 수

디플로이먼트와 레플리카 세트의 관계

디플로이먼트는 레플리카 세트를 관리하는 상위 개념이다. 디플로이먼트를 생성하면 그 아래에 레플리카 세트가 자동으로 생성되고, 레플리카 세트는 포드를 생성한다. 이 계층 구조는 애플리케이션의 버전 관리와 롤백을 가능하게 한다.

애플리케이션을 업데이트할 때, 디플로이먼트는 새로운 레플리카 세트를 생성하고 이전 레플리카 세트의 크기를 점진적으로 0으로 줄인다. 이렇게 함으로써 서비스 중단 없이 애플리케이션을 업데이트할 수 있다.

중요한 점은 업데이트 후에도 이전 레플리카 세트가 삭제되지 않고 유지된다는 것이다. 이는 문제 발생 시 이전 버전으로 쉽게 롤백할 수 있도록 하기 위함이다.

롤링 업데이트 작동 방식

디플로이먼트의 롤링 업데이트는 다음과 같은 방식으로 작동한다:

  1. 새 버전의 이미지로 디플로이먼트 설정을 업데이트한다.
  2. 디플로이먼트 컨트롤러는 새로운 레플리카 세트를 생성한다.
  3. 새 레플리카 세트의 포드가 생성되고 준비 상태가 된다.
  4. 일정 수의 새 포드가 준비되면 이전 레플리카 세트의 포드를 점진적으로 줄인다.
  5. 최종적으로 모든 트래픽이 새 버전의 포드로 전달되고, 이전 레플리카 세트의 포드 수는 0이 된다.

이 과정에서 minReadySeconds 설정은 새 포드가 준비된 것으로 간주되기 전 대기해야 하는 시간을 지정한다. 이는 애플리케이션이 완전히 초기화되고 트래픽을 처리할 준비가 되었는지 확인할 시간을 제공한다.

 

실습: 디플로이먼트 생성 및 업데이트

이제 실제로 디플로이먼트를 생성하고 업데이트하는 과정을 살펴보도록 한다.

 

기존 리소스 정리

먼저 기존에 실행 중인 레플리카 세트를 삭제하여 초기 상태로 돌아간다.

kubectl delete rs webapp

레플리카 세트를 삭제하면 그에 속한 포드들도 자동으로 종료된다. 이 과정은 kubectl get all 명령으로 확인할 수 있다.

 

디플로이먼트 YAML 파일 생성

이제 디플로이먼트를 정의하는 YAML 파일을 생성한다. 기존 레플리카 세트 파일을 수정하여 kind: ReplicaSet을 kind: Deployment로 변경한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  selector:
    matchLabels:
      app: webapp
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: richardchesterwood/k8s-fleetman-webapp-angular:release0-arm64

디플로이먼트 생성

작성한 YAML 파일을 적용하여 디플로이먼트를 생성한다.

kubectl apply -f pods.yaml

kubectl get all 명령으로 생성된 리소스를 확인한다. 디플로이먼트가 생성되고, 그 아래에 레플리카 세트와 포드가 함께 생성된 것을 볼 수 있다.

 

 

디플로이먼트 업데이트 준비

롤링 업데이트를 수행하기 위해 디플로이먼트 설정에 minReadySeconds 필드를 추가하고, 이미지 태그를 변경한다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  minReadySeconds: 30
  selector:
    matchLabels:
      app: webapp
  replicas: 2
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: richardchesterwood/k8s-fleetman-webapp-angular:release0-5-arm64

minReadySeconds: 30은 새 포드가 사용 가능한 상태로 간주되기 전에 30초 동안 대기해야 함을 의미한다. 이렇게 설정하면 업데이트 과정을 더 명확하게 관찰할 수 있다.

 

롤링 업데이트 수행

수정된 YAML 파일을 적용하여 롤링 업데이트를 시작한다.

kubectl apply -f pods.yaml

kubectl get all 명령을 반복적으로 실행하면 업데이트 과정을 관찰할 수 있다:

  1. 새로운 레플리카 세트가 생성된다.
  2. 새 레플리카 세트에서 첫 번째 포드가 생성되고 준비 상태가 된다.
  3. 두 번째 포드가 생성되고 준비 상태가 된다.
  4. 이전 레플리카 세트의 포드 수가 점진적으로 0으로 줄어든다.

이 과정에서 웹 애플리케이션은 계속 응답하며, 업데이트가 완료되면 새 버전이 표시된다. 가동 중지 시간 없이 업데이트가 완료된 것이다.

디플로이먼트 모니터링

디플로이먼트의 상태는 다음 명령으로 모니터링할 수 있다:

kubectl get all

 

 

이 명령은 모든 리소스의 상태를 보여주지만, 롤아웃 상태만 보려면 다음 명령을 사용한다:

kubectl rollout status deployment webapp

이 명령은 롤아웃이 완료될 때까지 진행 상황을 실시간으로 보여준다.

 

기다린 결과

 

디플로이먼트 버전 컨트롤

 

디플로이먼트 변경 이력 조회\

kubectl rollout history deploy webapp

 

 

디플로이먼트 직전 버전으로 롤백

kubectl rollout undo deploy webapp

 

 

 

이전 디플로이먼트(replicaset.apps/webapp-c64f8b446) 완전히 삭제하지 않고 pod만 삭제한후, 다시 똑같은 레플리카셋을 불러옴으로써 베포 속도를 더 효율적으로 한다.

결론

디플로이먼트는 쿠버네티스에서 애플리케이션을 관리하는 가장 효과적인 방법이다. 레플리카 세트의 기능을 확장하여 가동 중지 시간 없는 롤링 업데이트와 롤백 기능을 제공한다. 이를 통해 애플리케이션의 지속적인 배포와 업데이트를 안정적으로 수행할 수 있다.

실제 프로덕션 환경에서는 대부분의 워크로드가 디플로이먼트로 관리되며, 이를 통해 마이크로서비스 아키텍처에서 각 서비스를 독립적으로 업데이트하고 관리할 수 있다. 따라서 쿠버네티스를 사용할 때 디플로이먼트의 개념과 활용법을 잘 이해하는 것이 중요하다.

반응형

댓글