ReplicaSet과 Deployment

squareBird·2022년 3월 28일

deployment k8s kubernetes object replica set 쿠버네티스

Kubernetes

목록 보기

16/17

Replica Set과 Deployment

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

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

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

Kubernetes 시리즈의 글을 처음 작성할 때, Kubernetes에 대해서

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

이라고 정의했습니다.

그럼 Kubernetes는 어떻게 배포할 Container를 선택하고, 갯수를 선택하고 Deploy와 Scaling까지 관리해 주는걸까요?

Controller

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

Controller 역할

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

Auto Healing
- Pod 또는 Pod이 실행되고 있는 Node에 문제가 생겼을 경우 자동으로 복구하는 기능
- ex) ReplicaSet, DaemonSet
Software Update
- Pod을 업데이트 하는 기능, 롤백 기능도 제공
- ex)Deployment
Auto Scaling
- Pod의 리소스가 부족할 때 Pod을 추가적으로 생성하는 기능
Job
- 일시적인 작업을 위해 필요한 순간에만 Pod을 만들었다가 삭제할 수 있는 기능
- ex) job, cron job

Replica Set

Replica Set은 Pod의 숫자를 보장해주는 Controller입니다.
아래는 Kubernetes백서의 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 라는 Labels을 가지고 있고,
Replica Set은 spec.selector을 통해 tier:frontend 라는 Labels을 가지고 있는 Pod들의 갯수를 보장해주게 됩니다.

Replica Set의 단점

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

Deployment

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

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

라고 정의 되어있습니다.

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

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

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

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

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