Replica Set과 Deployment

이전글에서 쿠버네티스의 기본 오브젝트 4개에 대해서 정리했습니다.
쿠버네티스는 4개의 기본 오브젝트에 여러가지 기능을 추가하여 더 효율적으로 사용할 수 있는 오브젝트들을 추가했습니다.

오늘은 그 중에서 가장 많이 사용되는 오브젝트들인 Replica Set과 Deployment에 대해 알아보겠습니다.

쿠버네티스는 어떻게 Pod의 개수를 보장할까?

쿠버네티스 시리즈의 글을 처음 작성할 때, 쿠버네티스에 대해서

"컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 시스템"

이라고 정의했습니다.

그럼 쿠버네티스는 어떻게 배포할 컨테이너를 선택하고, 갯수를 선택하고 배포와 스케일링까지 관리해 주는걸까요?

컨트롤러

쿠버네티스 구조글을 보면 쿠버네티스는 여러 컴포넌트들의 상호작용을 통해 동작합니다.
그 중에서도 클러스터의 Pod들을 관찰하여 관리자가 선언한 Pod의 갯수를 보장해주는 기능을 Controller들이 수행해주고, 오늘 주제인 Replica Set과 Deployment가 이 Controller의 한 종류입니다.

컨트롤러의 역할

컨테이너를 감시하고 수를 보장해주는 컨트롤러에는 크게 4가지 역할이 있습니다.

1. Auto Healing

   • Pod 또는 Pod이 실행되고 있는 노드에 문제가 생겼을 경우 자동으로 복구하는 기능
   • ex) ReplicaSet, DaemonSet

2. Software Update

   • Pod을 업데이트 하는 기능, 롤백 기능도 제공
   • ex)Deployment

3. Auto Scaling

   • Pod의 리소스가 부족할 때 Pod을 추가적으로 생성하는 기능

4. Job

   • 일시적인 작업을 위해 필요한 순간에만 Pod을 만들었다가 삭제할 수 있는 기능
   • ex) job, cron job

   ---

Replica Set

레플리카셋은 Pod의 숫자를 보장해주는 컨트롤러입니다.
아래는 K8S백서의 Replica Set 문서에서 가져온 yaml파일 입니다.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

코드를 보면 ReplicaSet 오브젝트를 선언하고 있으며,
ReplicaSet은 3개의 Replicas로 구성되어 있습니다.
이는 아래 template에 정의한 Pod가 3개 배포된다는 의미입니다.

template을 보면 배포될 Pod들은 tier:frontend 라는 라벨을 가지고 있고,
Replica Set은 spec.selector을 통해 tier:frontend 라는 라벨을 가지고 있는 Pod들의 갯수를 보장해주게 됩니다.

Replica Set의 단점

Replica Set을 이용하면 Pod의 숫자가 보장되기 때문에 관리자가 원하는 어플리케이션을 안정적으로 배포할 수 있습니다.
하지만, 시간이 흐르게 되면 해당 어플리케이션을 업그레이드하여 배포해야하는 경우가 생기게 되는데, Replica Set은 이런 업데이트에 관한 기능을 제공하지 않습니다.
이를 해결하기위해 사용하는 것이 Deployment라는 오브젝트입니다.

Deployment

Kubernetes 백서에는 Deployment의 역할에 대해

"파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다"

라고 정의 되어있습니다.

이전에도 설명했듯이 쿠버네티스는 선언적으로 동작합니다.
스펙을 선언하면 해당 스펙에 맞는 상태로 변화시키려고 하는 특징이 있습니다.

Deployment는 위와 같은 형태로 동작합니다.

Deployment는 Pod와 ReplicaSet에 대한 선언적 업데이트를 제공합니다.
하위에 Replica Set을 제어하고, Replica Set이 하위의 Pod을 제어하는 구조이며,
Deployment가 Replica Set을 제어하므로, 관리자는 Deployment 하단의 Replica Set을 직접 관리하면 안됩니다.
어차피 Deployment에 선언해놓은대로 돌아오기 때문입니다.

위의 사진에서 보다시피 Deployment는 V1, V2, V3처럼 Replica Set이 지원하지 못했던 업데이트에 관한 기능을 함께 지원합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Deployment를 생성하는 yaml코드를 보면 Replica Set의 yaml코드와 매우 유사한 것을 알 수 있습니다.

Deployment Update

Deployment는 다양한 방법으로 업데이트를 지원합니다.

1. Rolling Update

먼저 Rolling Update는 별다른 설정을 하지 않을시 기본적으로 적용되는 방식입니다.
V1을 V2로 업데이트 할 때, V2를 하나 생성한 뒤 V1을 삭제하는 방식으로 Pod를 하나씩 점진적으로 교체해나가는 방법입니다.

이 방법은 무중단배포가 가능하다는 장점이 있지만, V1과 V2의 Pod이 공존하는 순간이 있다는 단점이 있습니다.

2. Recreate

두번째는 Recreate 즉 재생성입니다.
그림에서 보다시피 기존의 Pod을 모두 삭제한 뒤, 새로운 버전의 Pod을 선언한 갯수만큼 생성해주는 방식입니다.

단점으로는 순간적으로 Pod이 존재하지 않는 순간이 있다는 점입니다.

3. Blue/Green

세번째는 Blue/Green 배포입니다.
Blue/Green배포는 기존 버전의 Pod을 유지한채로 새로운 버전의 Pod을 선언한 갯수만큼 생성하고 Service가 트래픽을 전달하는 대상을 교체한 뒤 기존의 Pod을 삭제하는 방식입니다.

이 방법은 무중단 배포가 가능하고, 기존에 Rolling Update가 가지고있던 V1, V2가 공존하는 순간이 있는 문제를 해결할 수 있지만, 배포시에 자원을 2배로 사용한다는 단점이 있습니다.

4. Canary

Canary는 테스트라는 특징을 가지고 있는 업데이트 방법입니다.
구버전과 신버전 Pod을 모두 구성한 뒤, 트래픽의 양을 조절하여 테스트를 진행한 다음 교체하는 방식입니다.