Kubernetes Deployment

https://subicura.com/k8s/guide/deployment.html

Deployment

 

 

pod 을 직접 만들었을때 사실 pod 을 직접 만드는 일은 잘 없고 replicaset 을 만들면 replicaset이 pod 을 만든다고 했다.

하지만 replicaset 도 직접 만들일은 잘 없고 deployment 를 직접 만든다!

 

Deployment 만들기

echo-deployment.yml

apiVersion: apps/v1
kind: Deployment # 이 부분 
metadata:
  name: echo-deploy # 이 부분 
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1

 

위는 deployment 를 생성하는 yml 이다.

이전의 replicaSet을 생성하는 yml 파일과의 차이점은 kind, name 부분 밖에 없다.

 

 

echo-deployment.yml 을 apply 했다.

replicas:4 이므로 4개의 pod 들이 생겼다.

 

Deployment가 이미지 버전을 변경하는 방법

apiVersion: apps/v1
kind: Deployment 
metadata:
  name: echo-deploy 
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v2 # v1 -> v2 로 변경

 

image 의 버전을 v2로 변경했고 나머지 부분은 그대로다.

 

 

변경된 yml 파일을 apply 후 상태를 보면 위와 같다.

 

pod 들 중 어떤 pod 은 실행중이고, 어떤 pod 들은 생성중인 상태다.

그리고 pod 의 이름을 잘 보면 기존에 있던 pod 중 사라진 pod 이 있다.

 

또한 replicaset 은 기존에 1개 였는데 2개가 생겼으며 원하는 상태인 DESIRED 가 나는 분명 replicas:4로 설정했는데 3과 2로 제각각이다.

 

이유는 Deployment 가 버전을 변경하는 방법에 있다. (아래 참고) 

 

(https://tose33.tistory.com/1348)

Deployment

 

• 배포 버전을 관리한다

버전을 변경할때 replicaset을 이용하는데 흐름은 다음과 같다.

버전1에서 버전2로 바꾸고 싶다면?

 

1. 버전2를 갖는 pod를 1개, 버전1을 갖는 pod를 2개로 설정한다.

 

pod 3개 보유 중인 replicaset 이 각각 pod 2개 ,1개를 갖는 두개의 replicaset으로 나뉜다.

 

 

2. 버전 2를 갖는 pod를 2개, 버전1을 갖는 pod를 1개로 설정한다.

 

3. 버전 2를 갖는 pod를 3개로 설정한다.

 

이런 방식으로 deployment는 겉으로 봤을때 모든 pod 들이 자연스럽게 버전 변경이 되도록 할수 있다.

 

 

조금 더 시간이 지난 후 상태를 보면 내가 원하던 상태인 4개의 pod 이 실행중이다.

 

버전 관리, 롤백

Deployment는 변경된 상태를 기록한다.

# deploy/echo-deploy 의 기록 보기
kubectl rollout history deploy/echo-deploy

 

 

deploy/echo-deploy 에 대한 기록을 볼 수 있다.

 

# deploy/echo-deploy의 revison=1 의 상세
kubectl rollout history deploy/echo-deploy --revision=1

 

 

Image: .../echo:v1 확인 가능하다.

 

 

롤백 (undo)

이런식으로 deployment 는 과거의 변경 기록을 저장하고 있다.

따라서 현재 버전에 문제가 생겼을때 롤백이 가능하다.

# undo 로 바로 전 버전으로 롤백
kubectl rollout undo deploy/echo-deploy

 

 

undo 커맨드를 사용한 후에 상태를 보면 어떤 pod 들은 취소되고 있고 어떤 pod 들은 생성되고 있다.

버전 변경과 같은 매커니즘으로 이전 버전으로 되돌아가고 있는 것이다.

 

특정 revision 으로 롤백

# revision=2 로 롤백
kubectl rollout undo deploy/echo-deploy --to-revision=2

 

 

배포 전략 설정

버전이 변경될때 동시에 몇개의 pod이 죽고, 몇개가 새로 생겨나는지 설정할 수 있다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echo-deploy-st
spec:
  replicas: 4
  selector:
    matchLabels:
      app: echo
      tier: app
  minReadySeconds: 5 # 최소 대기 시간 5초 
  strategy: # 배포 전략
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3 #
      maxUnavailable: 3 # 최대 비활성화 되는 pod 갯수 (기본값 25퍼센트)
  template:
    metadata:
      labels:
        app: echo
        tier: app
    spec:
      containers:
        - name: echo
          image: ghcr.io/subicura/echo:v1
          livenessProbe:
            httpGet:
              path: /
              port: 3000

 

type: RollingUpdate

오래된 pod 들을 새 파드로 점진적으로 교체하는 롤링 업데이트 전략.

maxSurge: 3 

롤링 업데이트 중에 원하는 파드 수 이상으로 생성할 수 있는 파드의 최대 수 또는 백분율.

maxUnavailable: 3

롤링 업데이트 중에 사용할 수 없는(실행 중이 아닌) 파드의 최대 개수 또는 백분율.

(기본값은 25%)