[kubernetes] Replication Controller & ReplicaSet

Kubernetes 워크로드와 컨트롤러 

Kubernetes에서 워크로드는 클러스터에서 실행되는 애플리케이션을 의미하며, 컨트롤러는 파드 집합의 원하는 상태를 관리한다. 컨트롤러는 파드가 지정된 상태와 일치하도록 관리하며, 실패한 파드를 자동으로 교체하는 등의 작업을 수행한다. Kubernetes는 여러 종류의 빌트인 컨트롤러를 제공하여 다양한 애플리케이션 유형을 처리한다.각 컨트롤러는 애플리케이션의 요구 사항에 따라 적합하게 선택할 수 있다. 

Replication Controller

Replication Controller는 Kubernetes에서 파드의 복제본을 관리하는 오래된 방식이다. 현재는 Deployment와 ReplicaSet이 대부분의 경우에 더 적합하지만, 여전히 사용할 수 있는 리소스로 파드의 수를 원하는 상태로 유지하는 기능을 한다. 

Replication Controller의 동작 방식

• 파드 수 조정: Replication Controller는 설정된 replicas 수에 맞게 파드의 수를 유지한다. 예를 들어, replicas가 3으로 설정되면, 클러스터에서 실행 중인 파드가 3개가 되도록 자동으로 관리한다.파드가 너무 많으면 추가 파드를 제거하고, 파드가 너무 적으면 부족한 만큼 새로운 파드를 생성한다. 
• 자동 복구: Replication Controller는 관리하는 파드가 실패하거나 삭제되었을 때, 자동으로 새 파드를 생성하여 대체한다. 수동으로 생성한 파드는 이 기능이 적용되지 않는다. 
• 프로세스 감시자: Replication Controller는 여러 노드에서 실행되는 파드를 관리하며, 이를 "프로세스 감시자"라고 비유할 수 있다. 파드가 종료되거나 실패하면 이를 감지하고 자동으로 새로운 파드를 생성하여 애플리케이션의 가용성을 유지한다. 
• 애플리케이션 단일 인스턴스 유지: 예를 들어, 단 하나의 파드만 실행되도록 요구하는 애플리케이션이라면, Replication Controller를 통해 해당 파드를 영구적으로 실행할 수 있다. 시스템에서 파드가 실패하거나 삭제되면 Replication Controller가 자동으로 파드를 다시 생성한다. 

apiVersion: v1
kind: ReplicationController
metadata:
  name: myweb-rc
spec:
  replicas: 3  # 생성할 파드 수
  selector:
    app: web  # Pod의 레이블과 일치하는 파드를 선택
  template:
    metadata:
      labels:
        app: web  # 파드의 레이블
    spec:
      containers:
        - name: myweb
          image: httpd
          ports:
            - containerPort: 80
              protocol: TCP

명령어 예시

• 스케일링: kubectl scale rc <RC_NAME> --replicas=5
• 배포 파일 적용: kubectl replace -f <파일명.yml>
• 패치 적용: kubectl patch rc <RC_NAME> -p '{"spec": {"replicas": 2}}'
• 편집: kubectl edit rc <RC_NAME>
• 로그 확인: kubectl logs rc/<RC_NAME>

RC의 주요 필드 설명

• replicas: 원하는 파드의 개수
• selector: 관리할 파드를 선택하는 레이블 쿼리
• template: 파드 생성 템플릿 정의
• minReadySeconds: 새로 생성된 파드가 준비 상태로 간주되기까지의 최소 대기 시간

ReplicaSet (RS)

ReplicaSet은 Replication Controller의 후속 객체로, 동일한 기능을 제공하면서 디플로이먼트(Deployment)와 함께 사용하는 것이 일반적이다. ReplicaSet은 더 유연하고 강력한 파드 관리 기능을 제공하며, 디플로이먼트가 ReplicaSet을 관리하게 되어 주로 디플로이먼트에서 사용된다.

• ReplicaSet은 지정된 수의 파드를 항상 유지한다.
• ReplicaSet을 직접 사용하지 않고, 디플로이먼트를 사용하여 ReplicaSet을 관리하는 것이 일반적이다.
• 디플로이먼트는 파드의 선언적 업데이트 기능을 제공하며, 롤링 업데이트와 롤백을 손쉽게 처리할 수 있다. 

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myweb-rs
spec:
  replicas: 2  # 파드의 개수
  selector:
    matchLabels:
      app: web
      env: dev  # 파드의 레이블
  template:
    metadata:
      labels:
        app: web
        env: dev  # 파드의 레이블
    spec:
      containers:
        - name: myweb
          image: nginx
          ports:
            - containerPort: 8080
              protocol: TCP

• ownerReferences: ReplicaSet은 파드를 소유하며, 파드는 ownerReferences를 통해 자신이 어떤 ReplicaSet에 의해 관리되고 있는지 확인할 수 있다. 

ReplicaSet과 Replication Controller의 차이점

• 관리 방식: ReplicaSet은 파드를 소유하며, ownerReferences를 통해 파드를 관리한다. 반면, Replication Controller는 파드를 관리하지만, 파드에 대한 소유자 정보를 명시하지 않는다.
• 업데이트 및 관리: ReplicaSet은 디플로이먼트와 함께 사용되는 경우가 많으며, 디플로이먼트가 ReplicaSet을 관리한다. Replication Controller는 주로 기본적인 파드 관리 작업에 사용된다. 
• 디플로이먼트와의 관계: ReplicaSet은 디플로이먼트 내에서 관리되며, 디플로이먼트는 파드의 선언적 업데이트를 지원한다

스케일링 예시

• ReplicaSet 스케일링:
  • kubectl scale rs <RS_NAME> --replicas=3
  • kubectl replace -f <파일명.yml>
  • kubectl patch rs <RS_NAME> -p '{"spec": {"replicas": 2}}'

패치 및 업데이트

• 패치 사용 예시:
  • kubectl patch rs <RS_NAME> -p '{"spec": {"replicas": 3}}'
  • 파일을 사용한 패치: kubectl patch -f <파일_이름.yml> -p '{"spec": {"replicas": 3}}'

현재의 권장 사항

Kubernetes에서 Replication Controller는 과거에는 중요한 역할을 했지만, 이제는 Deployment와 ReplicaSet을 사용하는 것이 더 권장된다. Deployment는 애플리케이션의 상태를 더욱 세밀하게 관리하며, ReplicaSet은 여러 파드를 복제하여 관리하는 데 적합한 최신 방법이다. 

Replication Controller는 Kubernetes의 오래된 리소스로, 여전히 간단한 용도로 사용되지만, 복잡한 업데이트나 자동 롤백 기능이 필요한 경우 Deployment나 ReplicaSet을 사용하는 것이 일반적이다. Deployment는 확장성, 고가용성 및 애플리케이션 업데이트 관리에 더 적합하므로, Replication Controller는 현재 대부분의 Kubernetes 배포에서 권장되지 않는다.