[쿠버네티스] - Deployment

chancehee·2023년 9월 19일

deployment k8s kubernetes 배포 쿠버네티스

쿠버네티스

목록 보기

7/17

[ 개요 ]

시간이 지남에 따라 어플리케이션 버전 관리 필요 -> ReplicaSet은 어플리케이션 업데이트에 관한 기능을 제공하지 않는다.
이를 해결하기위해 사용하는 것이 Deployment

[ Deployment ]

Pod와 ReplicaSet에 대한 선언적 업데이트를 제공한다.
ReplicaSet의 상위 개념으로, Pod와 ReplicaSet에 대한 배포를 관리한다.
-> 즉, 롤백하거나 특정 버전으로 돌아갈 수 있는 기능을 제공한다.

[ Deployment Update ]

Deployment는 다양한 방식의 배포 전략이 있다.

Rolling Update (Default)

설명 : 기존 버전 Pod을 하나씩 삭제하고 새로운 버전 Pod 생성, 순차적(점진적) 교체
장점
- 다운타임 발생 안함
- 구버전의 환경을 재활용하거나 롤백하기 쉬움
단점
- 기존 버전의 Pod과 새로운 버전의 Pod 공존하는 시간 발생
- 사용중인 인스턴스에 트래픽이 몰리는 문제 가능성 존재
- 버전 호환성 문제 가능성 존재
Recreate

설명 : 기존 버전 Pod 모두 삭제 후 새로운 버전 Pod 생성
장점
- 단순함
단점
- 다운타임 발생 가능 (무중단 배포 불가능)
Blue/Green

설명 : 기존 버전 Pod 유지한채로 새로운 버전 Pod 생성, Service가 트래픽을 전달하는 대상을 교체한 뒤 기존 버전 Pod 삭제
장점
- 다운타임 발생 안함
- 기존 버전의 Pod과 새로운 버전의 Pod 공존하는 문제 해결
단점
- 배포시 자원을 2배로 사용함
- 새로운 환경에 대한 테스트가 전제되어야 함
Canary

설명 : 기존 버전 Pod과 신버전 Pod을 모두 구성한 뒤, 트래픽의 양을 조절하여 테스트 진행 후 교체
장점
- 문제 상황 빠르게 감지 가능
- A/B 테스트로 활용 가능
단점
- 구현 복잡성 존재(평가 방식, 트래픽 배분 등)
- 롤링 배포와 마찬가지로 호환성 문제 발생 가능

[ Deployment 만들기 ]

sudo vi [yaml 파일]

apiVersion: apps/v1
kind: Deployment
metadata:
  name: [Deployment 이름]
spec:
  replicas: 4 # 원하는 Pod 개수 선언 
  selector:
    matchLabels:
      app: [App 이름]
      tier: [tier 이름]
  minReadySeconds: 5
  strategy:
    type: RollingUpdate # update(배포) 전략 선언  
    rollingUpdate:
      maxSurge: 3 # Default값은 25%
      maxUnavailable: 3
  template:
    metadata:
      labels:
        app: [App 이름]
        tier: [tier 이름]
    spec:
      containers:
        - name: [컨테이너 이름]
          image: [이미지]
          livenessProbe: # 컨테이너 상태 모니터링 필요에 따라 추가
            httpGet:
              path: /
              port: 3000

kubectl apply -f [yaml 파일]
이후 이미지 등 리소스를 업데이트 할 때, 선언된 배포 방식에 따라 업데이트가 된다.
(새로운 ReplicaSet을 만들고, Pod 개수 조정하는 형태로 업데이트 수행)

[ Deployment 생성 분석 ]

Deployment Controller는 Deployment조건을 감시하면서 현재 상태와 원하는 상태가 다른 것을 체크
Deployment Controller가 원하는 상태가 되도록 ReplicaSet 설정
ReplicaSet Controller는 ReplicaSet조건을 감시하면서 현재 상태와 원하는 상태가 다른 것을 체크
ReplicaSet Controller가 원하는 상태가 되도록 Pod을 생성하거나 제거
Scheduler는 API 서버를 감시하면서 할당되지 않는 unassigned Pod이 있는지 체크
Scheduler는 할당되지 않은 새로운 Pod을 감지하고 적절한 노드에 배치
이후 노드는 기존대로 동작

[ Deployment 업데이트 테스트 ]

kubectl set image deploy/[Deployment 이름] [컨테이너 이름]=[변경하고자 하는 이미지] : 이미지 변경 (명령어로)

kubectl describe deploy/[Deployment 이름] : 이벤트 확인

[ Deployment 버전관리 ]

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

kubectl rollout history deploy/[Deploy 이름] : 히스토리 확인
kubectl rollout history deploy/[Deploy 이름] --revision=1 : revision 1 히스토리 상세 확인
kubectl rollout undo deploy/echo-deploy : 바로 전으로 롤백
kubectl rollout undo deploy/echo-deploy --to-revision=2 : 특정 버전으로 롤백

[ 예제 : Nginx Deployment 만들기, 업데이트 ]

sudo vi nginx-dp.yml

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx
spec:
  replicas: 3
  selector:
    matchLables:
      app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:1.14.2

kubectl describe deploy/nginx

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx
spec:
  replicas: 5 # 복제 개수 변경 
  selector:
    matchLables:
      app: nginx
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
          - name: nginx
            image: nginx:1.19.5 # 이미지 버전 변경