[Kubernetes] Deployment(Controller)

Deployment란

현재 운영중인 서비스를 업데이트/재배포하는 것에 도움을 주는 Controller 오브젝트

버전관리의 역할을 하기 때문에 ReplicaSet의 상위 개념이라고 불수도 있음

ReplicaSet을 생성하는 Deployment를 정의할 수 있고 배포 작업을 좀 더 세분화하여 조작가능

이러한 이유로 ReplicaSet만 사용하는 것 보다 Deplyment를 사용하는 추세

 

Deployment의 4가지 방식

1. Recreate

• 가장 단순한 배포 전략, 기존 버전의 Pod를 모두 삭제한 다음 새로운 파드를 생성
• 중단 시간 발생하기 때문에 일시적인 중단을 허용할 수 있는 서비스에서만 사용가능

 

Recreate 배포 구성 및 yaml 작성 예시

 

2. Rolling Update

• 기존 버전의 서버(Pod)를 하나씩 죽이고 새로운 버전의 서버(Pod)를 띄우면서 순차적으로 교체
• Recreate와 구성은 비슷하지만 점진적으로 새로운 or 기존 서버를 증/감한다는 차이  
• 배포중 사용자는 V1, V2 두 가지의 서버에 접근 가능
• 배포중에 추가적인 자원을 요구하지만 Downtime 발생 X

Rolling Update배포 구성 및 yaml 작성 예시

3. Blue/Green

• Deployment의 자체적인 기능 X
• Service의 Label을 변경하는 것으로 활용
• 문제 발생시 Label을 이전으로 되돌리는 것으로 RollBack이 간단함
• 새로운 버전을 추가하고 기존 버전과의 연결을 끝는 것으로 Downtime 발생 X
• 배포 중 자원이 2배로 필요하다는 단점 존재
• 이러한 이유로 현재 가장 많이 사용하는 배포 방식

4. Canary

• Deployment의 자체적인 기능 X
• 위험을 빠르게 감지할 수 있는 배포방법(카나리아 새의 어원에서 명칭)
• 테스트를 진행하면서 배포
• Downtime 발생 X 
• 테스트가 정상적으로 종료되면 새로운 버전의 서버를 증가하고 기존의 버전은 삭제
• 테스트가 진행되거나 테스트가 종료될 때 자원 사용량이 늘어났다가 다시 줄어듬

---

Deployment 실습

1. Recreate 방식 배포

Deployment 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-1
spec:
  selector:
    matchLabels:
      type: app
  replicas: 2
  strategy:
    type: Recreate
  revisionHistoryLimit: 1
  template:
    metadata:
      labels:
        type: app
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 10

생성된 Deployment와 2개의 Pod로 구성된 ReplicaSet 

Service 생성

selector에 type:app을 지정하여 Deployment의 label과 동일하게 구성(ReplicaSet의 Pod와 연결)

apiVersion: v1
kind: Service
metadata:
  name: svc-1
spec:
  selector:
    type: app
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080

생성된 서비스와 Deployment에 의해 생성된 Pod와의 연결

Console에서 Service의 Cluster Id로 접근

이러한 요청을 2초마다 진행하도록 함 (버전 변경을 확인하기 위해)

Deployment를 수정( image : ~/v2), 업데이트

업데이트동안,기존의 Pod가 삭제됨으로 Downtime 발생으로 접근이 불가되는 메시지 출력

새 버전의 Pod가 정상 가동 된 후 부터는 변경된 버전이 지속적으로 출력됨

이렇게 업데이트가 끝나도 기존의 버전(ReplicaSet)에 대해 보관

또한, 간단한 명령으로 이전 버전 Rollback이 가능

kubectl rollout undo deployment "deployment Name" --to-revision="버전 번호"

최초(version 1)상태로 변경하면 Deployment의 신규 ReplicaSet이 변경 적용됨

---

2. Rolling Update

Rolling Update Deployment 생성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2
spec:
  selector:
    matchLabels:
      type: app2
  replicas: 2
  strategy:
    type: RollingUpdate
  minReadySeconds: 10
  template:
    metadata:
      labels:
        type: app2
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 0

생성된 Deployment, ReplicaSet, Pod 확인

Service 생성

selector에 type: app2를 지정하여 ReplicaSet의 Label과 동일하게 구성(ReplicaSet의 Pod와 연결)

apiVersion: v1
kind: Service
metadata:
  name: svc-2
spec:
  selector:
    type: app2
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080

Pod와의 연결 확인

Console에서 Service의 Cluster ID로 접근 확인

버전 업데이트

Deployment에서 container image를 ~v2로 변경 업데이트

Rolling update는 순차적으로 기존의 버전을 줄이고 새 버전을 늘리기 때문에

    v1이 계속 출력 되다가 v1, v2가 같이 출력되고 최종적으로는 v2가 계속 출력 된다

---

3. Blue/Green 배포

블루에 해당하는 ReplicaSet 생성

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica1
spec:
  replicas: 2
  selector:
    matchLabels:
      ver: v1
  template:
    metadata:
      name: pod1
      labels:
        ver: v1
    spec:
      containers:
      - name: container
        image: kubetm/app:v1
      terminationGracePeriodSeconds: 0

Service 생성  

selector에 ver:v1을 지정하여 ReplicaSet의 Label과 동일하게 구성(ReplicaSet의 Pod와 연결)

apiVersion: v1
kind: Service
metadata:
  name: svc-3
spec:
  selector:
    ver: v1
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080

ReplicaSet으로 생성된 Pod와의 연결 확인

Console에서 Service의 Cluster ID로 접근 확인

 

 

v2의 ReplicaSet을 생성(green)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replica2
spec:
  replicas: 2
  selector:
    matchLabels:
      ver: v2
  template:
    metadata:
      name: pod1
      labels:
        ver: v2
    spec:
      containers:
      - name: container
        image: kubetm/app:v2
      terminationGracePeriodSeconds: 0

생성된 ReplicaSet과 Pod확인

Service의 selector을 v2로 변경 후 업데이트

업데이트한 직후 Downtime없이 즉시 v2로 접근/출력됨

이렇게 업데이트를 한 후에는 ReplicaSet을 삭제하거나 Pod구성을 0으로 변경

    - Rollback을 감안해서 Pod구성을 낮추는 것을 기본적으로 추천