[Kubernetes] Replica Controller / ReplicaSet 차이점과 잘 사용하는 법

개요

쿠버네티스에서 지정한 파드의 수를 보장해주고, 파드가 문제가 생겨서 죽었을 때도 다시 파드를 생성해주는 역할이 바로 Replica 입니다.

Replica는 쿠버네티스의 고가용성을 유지해주고 안정성을 보장하는데요.

구버전 쿠버네티스에서는 Replica Controller를 사용했었는데 이제는 거의 대부분 ReplicaSet을 사용합니다.

그리고 단독으로 Replica를 생성하기 보단 Deployment와 함께 사용하기를 권장합니다.

Replica Controller와 ReplicaSet의 차이, 왜 Deployment와 함께 사용해야하는지 알아보겠습니다.

 

 

Replica Controller란?

레플리카 컨트롤러는 쿠버네티스의 컨트롤러 중 하나로 파드의 지정된 복제본 수를 유지하는 역할을 합니다.

하지만 equality-based 셀렉터만 사용가능하여 유연성이 떨어져서 최근에는 잘 사용하지 않습니다.

apiVersion: v1
kind: ReplicationController
metadata:
  name: my-replication-controller
spec:
  replicas: 3
  selector:
    app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: my-image

 

 

ReplicaSet이란?

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
    matchExpressions:
      - {key: environment, operator: In, values: [prod, staging]}
      - {key: tier, operator: NotIn, values: [frontend]}
  template:
    metadata:
      labels:
        app: nginx
        environment: prod
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 250m
            memory: 256Mi

레플리카셋은 레플리카 컨트롤러와 다르게 셀렉터의 matchExpressions를 사용하여 특정 조건의 파드만 유연하게 선택 가능합니다.

위의 셀렉터 설정은 nginx 앱인 파드, 운영 및 스테이징 환경, 프론트앤드 티어가 아닌 것만 골라서 선택합니다.

 

레플리카 컨트롤러와 레플리카셋의 차이점

정리하자면 레플리카 컨트롤러는 equality-based 셀렉터만 사용할 수 있고, Set-Based 셀렉터의 고급 기능은 사용할 수 없습니다.

Equality-based

selector:
  app: nginx
  environment: prod

 

Set-based 셀렉터

selector:
  matchExpressions:
    - {key: app, operator: In, values: [nginx, nginx-proxy]}
    - {key: environment, operator: NotIn, values: [dev, test]}

다만 운영관점에서 matchExpressions 라는 고급 셀렉터를 사용할 수 있어서 관리측면에서 더욱 유리합니다.

 

 

Deployment와 함께 잘 사용하는법

ReplicaSet은 단독으로 사용해도 파드의 개수를 보장하는 역할을 잘 수행하지만 deployment와 함께 사용하기를 권장합니다. 이유는 위와 같이 replicaset의 스펙이 변경되면 새로운 버전이 될텐데요. 그때 deployment가 쉬운 배포를 도와주기 때문입니다.

 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 최대 초과 생성 가능한 파드 수
      maxUnavailable: 0  # 업데이트 중 사용 불가능한 파드 수
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

# 이미지 업데이트
kubectl set image deployment/nginx-deployment nginx=nginx:1.15.0

# 업데이트 상태 확인
kubectl rollout status deployment/nginx-deployment

# 업데이트 이력 확인
kubectl rollout history deployment/nginx-deployment

replicaset만 사용했다면 이미지를 1.15.0 버전으로 업데이트 하려고 했을 때 replicaset을 삭제 후 다시 배포해야 하지만 deployment를 사용하면 위와 같이 명령어 한줄로 업데이트가 가능합니다.

 

Deployment가 ReplicaSet을 관리하는 방식

초기배포

 

업데이트 진행 중

 

업데이트 완료

 

결론

레플리카 컨트롤러와 레플리카셋의 차이점 그리고 왜 deployment와 함께 사용해야 하는지에 대해 알아봤습니다.

레플리카셋은 pod의 개수와 고가용성을 보장해주는 기능이며, 고급 셀렉터 기능으로 다양한 레이블과 라벨을 선택하여 pod를 지정할 수 있습니다.

 

*참고자료*

https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/?spm=a2c65.11461447.0.0.15d87863YiFv0v

https://medium.com/@manojkumar_41904/kubernetes-difference-between-replicaset-and-replication-controller-c2a14e44be34
https://dgjinsu.tistory.com/69