📍what is Controller?

• 쿠버네티스를 지속적으로 모니터링하며 이에 따라 반응 하는 API

📌 why Replication Controller

• 어떤 이유에서든 앱이 다운되고 Pod가 고장나면 사용자들이 액세스 할 수 없게 된다.
• 사용자가 앱에 대한 액세스를 잃지 않도록 하려면 한 개 이상의 인스턴스나 Pod가 동시에 실행되어야 한다.
• 복제 컨트롤러는 쿠버네티스 클러스터에 있는 단일 Pod의 다중 인스턴스를 실행하도록 도와준다. 👉 고가용성을 제공함
• Pod를 하나만 사용해도 Replication Controller가 기존 파드가 죽었을때 자동으로 새 Pod를 불러온다.
• 따라서 Replication Controller는 Pod가 항상 실행되도록 보장한다 (1개든 여러개이든)

📡 Load Balancing & Scaling

• Replication Controller가 필요한 또 다른 이유는 여러개의 Pod를 만들어 로드밸런싱 하기 위해서
• 사용자가 증가할 경우 Pod를 추가로 생성하여 로드밸런싱
• 더 많은 액세스가 이루어지고 첫 번째 노드에 리소스가 바닥난다면 클러스터 내 다른 노드에 Pod를 추가로 배치 할 수 있다.
• Replication Controller는 클러스터 내 여러 노드로 부하 분산이 가능하다.
• 추가로 auto scaling 까지

🆚 Replication Controller vs ReplicaSet

• RC는 구식 기술
• ReplicaSet이 대체 되고 있음
• 앞서 설명한 기능은 둘다 지원

📋rc-definition.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: front-end

spec:  
  template:
    metadata:
      name: myapp-pod
      labels: 
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx

replicas: 3

• spec 섹션 안에는 우리가 만들 개체의 사양이 들어간다.
• template은 컨트롤러가 복제본을 만들기 위해 사용할 Pod 템플릿이다
• Pod yaml 을 만들때 사용했던 섹션의 내용을 그대로 작성한다
• metadata 이하 내용을 그대로 사용해도 무방하다.
• 뭘 옮기든 template 섹션 아래 있어야 하고 자식 수준에 작성되어야 한다.
• metadata와 spec 섹션이 각 2개씩 작성되는데 하나는 Replication Controller, 하나는 Pod 정의이다.
• Pod 정의는 RC의 자식요소로 들어가야 한다.
• replicas는 RC의 spec 항목의 형제요소로 들어가야 한다.

🔨 RC 생성하기

$ kubectl create -f rc-definition.yaml

🚨 RC 생성 확인하기

$ kubectl get replicationcontroller
$ kubectl get pod // 3개의 pod 확인 가능

• 생성된 Pod의 이름은 모두 Replication Controller의 이름을 따라간다

📋 replicaset-definition.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end

spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx

replicas: 3 
selector:
  matchLabels:
    type: front-end

• apiVersion은 apps/v1 이다. 틀릴시 error 발생
• spec 섹션아래 template섹션을 자식요소로 작성하고 이전 Pod 생성 구문을 그대로 작성한다 (RC와 동일)
• RC와 RS의 큰차이는 selector
• selector는 replicaSet 아래 놓인 Pod를 식별하게 해줌
• RS는 자신의 RS의 일부로 만들어지지 않은 Pod들도 관리 할 수 있기 때문에 Selector로 식별해야함
• 만약 selector 섹션을 생략하면 RS 생성시 작성된 pod 정의의 labels과 동일하다고 추정한다.
• RS의 경우 사용자 입력이 이 속성에 요구된다.
• 많은 연산자 또한 제공한다

🔨 ReplicaSet 생성하기

$ kubectl create -f replicaset-definition.yaml

🚨ReplicaSet 생성 확인하기

$ kubectl get replicaset
$ kubectl get pods

❓왜 labels과 selector를 사용할까?

• 항시 작동하는 Pod를 보장하기 위해 사용한다.
• 생산된 Pod에 labels을 지정함으로써 어떤 파드를 모니터링 할지 결정
• labels와 selector는 쿠버네티스 전역적으로 사용

⚙️Scale

• 방법 1.

1. 정의 파일의 replicas 필드의 개수를 수정한다.
2. kubectl replace -f replicaset-definition.yaml 명령어로 업데이트한다.

• 방법 2.

1. kubectl scale --replicas=6 -f replicaset-definition.yaml 명령어 사용
2. kubectl scale --replicas=6 replicaset myapp-replicaset 명령어 사용

• 파일 이름으로 replicas를 수정할 경우 자동으로 업데이트 되지 않는다는 것을 명심
• auto scaling 은 추후에

⌨️ commands 복습

$ kubectl create -f replicaset-definition.yaml
$ kubectl get replicaset
$ kubectl delete replicaset <replicaset 이름>
$ kubectl replace -f <replicaset 파일 이름.yaml>
$ kubectl scale --replicas=6 -f <replicaset 파일 이름.yaml>