YAML 파일을 쿠버네티스에 적용하기 - Deployments

Deployment

 

프로덕션 환경에서 애플리케이션을 배포하고자 한다.

여러 대의 서버 인스턴스가 돌아가는 애플리케이션을 어떤 식으로 배포해야 할까?

 

1. 배포할 때 모든 인스턴스를 한꺼번에 모두 업그레이드할 경우, 사용자가 애플리케이션에 접근할 때 영향을 줄 수 있으므로 하나씩 차근차근 업데이트하고자 할 것이다. → Rolling Update라고 한다.

 

2. 업그레이드 중에 문제가 발생할 경우 다시 예전 상태로 돌릴 수 있는 Rollback 기능을 이용한다.

 

3. 여러 가지 변경을 한 번에 적용하고자 할 때, 즉시 적용하는 것이 아니라 애플리케이션을 일시 정지한 뒤 모든 변경 사항을 한 번에 적용할 수 있도록 할 수도 있다.

 

위처럼 배포 시 필요한 기능(Rolling Update, Rollback, Pause 등)을 쿠버네티스는 Deployment를 통해 제공하고 있다.

 

 

Deployment yaml 파일을 작성할 때는 Replicaset과 동일하며, kind만 Deployment로 변경해주면 된다.

 

 

deployment.yaml 작성

deployment 생성 완료

 

배포를 위한 pod는 3개가 준비되어 있다. 왜? → yaml 파일에 복제본을 3개 만들어달라고 했으니께는~!

 

 

Update and Rollback

 

쿠버네티스에서 Deployment를 생성하거나 기존 Deployment의 이미지를 업그레이드할 때마다 롤아웃(Rollout)이 발생한다.

롤아웃이란? 애플리케이션 컨테이너를 점진적으로 배포하거나 업그레이드하는 과정

 

처음 Deployment를 생성하면 롤아웃이 발생한다. →  Deployment Version 1(Revision 1)이 생성됨

이후 애플리케이션을 업그레이드하고 새로운 컨테이너 버전으로 업데이트할 경우에 새로운 롤아웃이 발생하게 된다. → Deployment Version 2(Revision 2) 생성됨

 

롤아웃의 상태를 확인하기 위해서는 kubectl rollout status [Deployment 이름] 명령을 사용하면 되고,

애플리케이션의 롤아웃 기록을 확인하고 싶으면 kubectl rollout history [Deployment 이름] 명령을 사용하면 된다.

 

 

 

Deployment 전략 2가지 

1. Recreate 전략: 실행 중인 모든 인스턴스를 종료하고 새로운 버전의 애플리케이션 인스턴스를 한 번에 생성한다. → 사용자 접근 불가하므로 기본 배포 전략이 아님

2. RollingUpdate 전략: 기존 인스턴스를 하나씩 종료하고 새 버전의 인스턴스를 하나씩 실행한다.

 

Deployment 업데이트 방법 2가지

1. kubectl apply deployment 명령 사용: yaml 파일을 수정한 뒤 apply 명령어를 사용하여 변경 사항을 적용한다. 이 경우 새로운 롤아웃이 발생하고 새로운 Deployment 버전이 생긴다.

2. kubectl set image 명령 사용: 컨테이너 이미지를 업데이트를 위해서는 set image 명령을 사용할 수 있다. → yaml 파일에 영향을 주지 않으므로 기존 구성과 차이가 생길 수 있다.

 

롤백 방법

kubectl rollout undo 명령을 사용한다. 롤백이 완료되면 새로운 버전의 RepliaSet이 종료되고, 이전 버전의 ReplicaSet이 다시 실행된다.

 

kubectl create	Deployment 생성
kubectl get deployments	Deployment 목록 확인
kubectl apply	Deployment 업데이트
kubectl set image	Deployment 업데이트 (파일 영향 X)
kubectl rollout status	롤아웃 상태 확인
kubectl rollout undo	롤백

 

 

---

 

배포 및 롤아웃 실습

 

Deployment 파일 코드

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    tier: frontend
spec:
  selector:
    matchLabels: 
      app: myapp
  replicas: 3
  template:
    metadata:
      name: nginx-2
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

 

deployment를 생성할 때 rollout status를 재빠르게 실행하면,,, 현재 인스턴스가 하나씩 생성되는 모습을 확인할 수 있다.

 

 

rollout history 명령어를 사용하면 배포 버전을 확인할 수 있다. CHANGE-CAUSE의 경우 현재 <none>으로 뜨는데, 이는 deployment를 생성할 때 --record 옵션을 포함하여 실행하면 deployment의 변화 원인을 작성해준다. 보통은 실행 명령이 작성됨

--record 사용 X

--record 사용 O

 

 

배포 이미지 변경해보기 - 1 파일 변경

 

현재 등록된 이미지는 nginx이다.

이미지를 변경해보자

 

편집 명령을 입력하면 쿠버네티스가 작성한 파일이 열린다.

image의 이름을 nginx에서 nginx:1.18로 수정하고 저장한다.

 

저장을 끝낸 후 describe 명령을 사용하면 이미지가 변경된 것을 확인할 수 있고, 이전 버전의 레플리카셋은 종료되고 업데이트된 레플리카셋이 실행되는 것을 확인할 수 있다. 중요한 건 점진적으로(rollout) 실행되고 종료된다는 점을 기억하자.

 

 

 

배포 이미지 변경해보기 - 2 set image 명령어 사용하기

 

이미지를 nginx:1.18-perl로 변경하는 set image 명령어를 사용하고 롤아웃 상태를 확인해보았다.

변경된 레플리카셋을 업데이트하고 오래된 레플리카셋이 종료되는 것을 확인할 수 있다.

 

 

이미지를 두 번 변경했으니 현재 deployment의 버전은 3이 된 것을 확인할 수 있다.

 

 

버전 3의 pod가 정상적으로 작동되는 것을 확인할 수 있다.

 

 

롤백 해보기

이미지에 문제가 생겼으면 rollout undo 명령을 이용하여 이미지를 이전 버전으로 되돌릴 수 있다.

이전 버전으로 돌릴 것이다.

rollout undo 실행 화면

 

2버전의 nginx:1.18로 변경되었다.

2 버전이 삭제되고 4버전이 생성되었다.

 

이거 왜 2버전이 삭제되고 4로 변경되었을까?

쿠버네티스의 롤백은 단순히 과거의 특정 버전으로 되돌리는 것이 아니라, 해당 시점의 상태를 새 버전으로 배포하는 형태로 기록하기 때문이다. 

 

 

 

존재하지 않는 이미지로 배포해보기

 

edit 명령어를 이용해서 파일을 편집하되, 존재하지 않는 이미지를 집어넣고 파일을 저장한다.

이후 rollout 상태를 확인해보면 아래와 같이 멈춰버린다.

 

deployments의 상태를 확인해보니 존재하지 않는 이미지라는 에러가 뜬다.

강의는 리눅스를 사용하는데 리눅스는 오래된 것을 하나 먼저 지우고,,, 시작하는 것 같은데 windows는 오래된 이미지는 나중에 삭제하는 듯하다. 처음부터 아예 에러를 띄워주고 오래된 이미지는 그대로 잘 작동하고 있다.