🚌 쿠버네티스 ReplicaSet, ReplicationController

https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

ReplicaSet

ReplicaSet은 replica Pod이 언제든지 실행될 수 있도록 안정된 set을 유지하기 위해 사용함.
특정 식별자를 가지는 Pod의 유효성을 보장하기 위함.

ReplicaSet 동작

• ReplicaSet은 필드로 정의되어 있음.
  • 사용 가능한 Pod를 식별할 수 있는지를 명시한 selector,
  • 유지 되어야 하는 Pod의 개수가 몇 개인지 replica의 개수,
  • replica가 유지되어야 할 개수의 기준을 만족하기 위해, 새로운 Pod의 데이터를 명시하는 탬플릿(Template)
• ReplicaSet은 요구되는 개수의 Pod를 생성/삭제하는 것을 만족하는데 목적을 둠.

• 새로운 Pod를 ReplicaSet이 생성할때 Pod탬플릿을 사용한다.

• ReplicaSet은 본인의 Pods내부에 존재하는, 현재 객체가 어떤 리소스에 의해 소유되는지 명시하는 metadata.ownerReferences 필드를 통해 연결되어 있음.
  • Pod 내부에 metadata.ownerReferences 필드가 존재하고 거기에 ReplicaSet이 연결되어있음.
  • 해당 필드를 통해서 ReplicaSet은 Pod의 상태를 확인하고 유지한다.

• ReplicaSet은 select를 사용하여 획득 가능한 새로운 Pod를 식별한다.
  • ownerReference가 없거나 Controller가 아니거나, ReplicaSet의 Selector에 일치하게 되면 즉시 ReplicaSet에 속하게 된다.
  • Controller : apiserver와 원하는 상태로 전환하는 방법을 통해 클러스터의 공유된 상태를 감시하는 제어 루프

    ReplicaSet vs ReplicationController

    • 레플리카셋이 더 풍부한 표현식 포드 셀렉터를 사용 가능
    • 레플리케이션 컨트롤러: 특정 Label을 포함하는 포드가 일치하는지 확인

ReplicaSet 사용

• ReplicaSet은 pod replica의 특정 수가 유지되는 것을 보장한다.
• 하지만, Deployment는 Replica를 관리하는 상위 레벨이고, Pod에 사용 특징을 선언적으로 수정으로 제공한다.
• 그래서 ReplicaSet을 직접 쓰기보다 Deployment를 대신 사용하는 것을 권장함
  • 커스텀 업데이트 오케스트레이션이나 업데이트를 사용하지 않으면 괜찮음.
• Deployment를 사용하면 ReplicaSet 객체를 직접 작성할 필요가 없다.
  (애플리케이션의 스펙 섹션에서 정의)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # modify replicas according to your case
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

spec 필드에 label selector를 사용하여 다양한 selector 설정이 가능하다.

spec:
  matchLabels:
    tier: frontend

spec:
  selector:
    matchExpressions:
    - key: tier
      operator: In
      values:
      - frontend

spec:
  selector:
    matchLabels:
      key: value
    matchExpressions:
      - {key: keyName, operator: In, valeus: [valueName]} #[] : value리스트

사용

kubectl create -f <replicaSet.yaml> : 레플리카셋 생성
kubectl get rs : 레플리카셋 조회
kubectl describe rs <Replicaset 이름> : 레플리카셋 상세 조회
kubectl delete rs <Replicaset 이름> : 레플리카셋 삭제

• 스케일링 : replicas의 개수를 변경하여 pod의 개수를 늘림

---

ReplicationController

https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/

Replication을 너무 많이 발생시키면 오버헤드 발생, 워커노드가 복구될 시간을 부여해서 레플리케이션을 적게하기도 함.

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx

  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

• replicas: 유지해야할 포드의 개수
• selector: 레플리케이션 컨트롤러가 관리하는 포드 범위를 결정하는 Label Selector
• template: 포드 탬플릿
  • pod 디스크립터 형태와 동일하게 작성
  • labels에 key:value와 selector의 key:value를 통일하여 작성
    

---

ReplicationController 실행

kubectl create -f <replication.yaml>

레플리케이션 컨트롤러 확인

kubectl get rc
kubectl describe rc <ReplicationController 이름>

• Pod를 임의로 정지시켜 확인하면
  kubectl delete pod <파드네임>
kubectl get pod : AGE가 바뀌는것을 확인할 수 있음.
  

명령어로 설정파일 접근

kubectl edit rc <ReplicationController 이름>

레플리케이션 컨트롤러 삭제

kubectl delete rc <replicationController 이름> : 하위 Pod들도 모두 삭제됨
kubectl delete rc <replicationController 이름> --cascade=false : 포드는 계속 실행유지하고 레플리케이션 컨트롤러만 삭제