쿠버네티스 deployment

쿠버네티스 deployment

🫠쿠버네티스 deployment는 replicaSet의 상위 버전이라고 이해하시면 됩니다.

replicaSet과의 차이점이라면 RollingUpdate와 RollBack을 지원한다는 것입니다.

출처 : 쿠버네티스 - 롤링 업데이트 수행하기

🥳예를 들어서 nginx:1.14버전의 pod가 3개(A,B,C)가 띄워진 상황이라고 가정하겠습니다.
이 때 nginx:1.15로 바꾸고 싶다면 RollingUpdate를 하면 되는데 RollingUpdate를 하게 될 경우 아래와 같이 진행되게 됩니다.

1. nginx:1.15 이미지를 갖는 컨테이너를 생성 (이 때 pod의 개수가 순간적으로 4개가 됩니다.)
2. nginx:1.15 컨테이너가 생성의 성공하게 되면 nginx:1.14 이미지를 갖는 pod 하나를 제거 (제거 후 pod는 다시 3개로 변경됩니다.)
3. 위 1,2번 과정을 모든 pod가 nginx:1.15가 될 때까지 진행

😁위와 같은 과정을 통해 서비스를 종료하지 않고 update를 진행할 수 있게 됩니다.(서비스의 종류에 따라 달라질 수 있습니다.)

Deployment yaml 파일 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        ports:
        - containerPort: 8080
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

🤗보시면 ReplicaSet과 매우 비슷한 것을 확인 할 수 있습니다. 추가된 부분이 있다면 맨 아래 strategy의 RollingUdpate 부분이 추가 되었습니다.
maxSurge : 한 번에 몇개씩 업데이트를 진행할 것인가?
maxUnavailable : 한 번에 몇개씩 종료 시킬 것인가?

명령어를 통해 적용하는 방법은 아래와 같습니다.

명령어

• kubectl set image deployment/my-deployment my-container=my-image:v2
deployment에 있는 my-container라는 이름을 가진 컨테이너의 이미지 버전을 v2로 변경하는 명령어입니다. 이를 실행하면 rollingUpdate를 하는 것을 확인 할 수 있습니다.

• kubectl rollout history deployment [deployment 이름]
deployment의 변경 이력을 확인 할 수 있는 명령어입니다. 기본적으로는 10개의 이력을 저장하게 되는데 이를 통해 언제 어떤 변경이 있는지 확인 할 수 있습니다.

• kubectl rollout undo deployment [depolyment 이름] --to-revision=1
rollback하는 명령어입니다. kubectl rollout undo deployment [depolyment 이름]만 작성할 경우 바로 전 단계로 rollback하며 --to-revision을 이용하여 원하는 버전으로 변경할 수 있습니다. 이 때 --to-revision의 경우 뒤로 몇 몇번째로 rollback하는 것이 아닌 위에서 history로 확인 한 결과물에서 나온 순서?(옆에 1,3 이런식으로 숫자가 적혀있습니다.)로 이동한다는 개념입니다.

예를 들어서 아래와 history가 아래와 같을 때

1 version1
2 version2
3 version3
4 version4

kubectl rollout undo deployment [depolyment 이름] --to-revision=1를 사용한다면

version1로 변경이 되며 history 또한 아래와 같이 변경됩니다.

2 version2
3 version3
4 version4
5 version1

추가

😎update를 하고 나면 replicaSet을 확인 해 보시면 기존 값들이 유지되고 새로 만든 replicaSet이 이용되는 것을 확인 할 수 있는데 이는 후에 rollback을 위해 남겨두는 것으로 이해하시면 됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  ...
  revisionHistoryLimit: 3
  ...

revisionHistoryLimit를 통해 해당 replicaSet의 개수를 변경할 수 있습니다.