오늘 지윤의 Agenda
1. Replication Controller
2. ReplicaSets
3. DaemonSets
4. Cronjob

[Replication Controller]

Replication Controllers 란

• Replication controller는 pod가 항상 실행되도록 보장하는 쿠버네티스 리소스.
• 만약 어떤 이벤트로 인하여 클러스터의 node에서 pod가 제거되면, ReplicationController가 missing pod를 인식하고, 대체할 pod를 만들어낸다.
• Pod의 실제 수를 label selector를 통해 monitoring.

Replication Controller 동작

1. 실행중인 pod 목록을 지속적으로 monitoring
2. 지정한 “type”의 pod 실제 수가 desired count와 일치하는지 확인
3. Pod가 부족하면 새 복제본을 작성
4. Pod가 많으면 초과 복제본을 제거 (많은 경우 - 누군가 manual하게 pod 만드는 경우 등..)

Replication Controller 구조

3가지의 파트로 이루어져 있음

• Label Selector : Replication Controller가 담당할 pod의 범위를 지정
• Replica Count : 실행할 Pod의 desired number를 지정
• Pod template : new pod 복제본을 생성할 때 이용

장점

• Pod가 항상 실행되도록 보장 : 기존 포드가 없어졌을 때 new pod를 시작
• Cluster node에 장애가 발생하면 장애가 발생한 node에서 실행 중이던 모든 pod에 대한 Replicas를 만듦
• 수평 스케일링이 쉽게 가능
  kubectl scale rc <name> —replicas=N

RC를 만들어보자!

apiVersion: v1
kind: ReplicationController
metadata:
  name: kubia  ## 이름 적고
spec:
  replicas: 3
  selector:
        app: kubia.    # Which pod에 RC가 작동할지 결정!
template:
  metadata:
    labels:
      app: kubia.    ## 여기 라벨이 selector의 라벨조건과 일치해야함
  spec:
    containers:
    - name: kubia
      image: luksa/kubia
      ports:
      - containerPort: 8080

Note) Pod를 수동으로 지워본 후 Replica가 복원하는 과정

$ kubectl delete pod kubia-53thy
pod "kubia-53thy" deleted

$ kubectl get pods
NAME          READY     STATUS              RESTARTS   AGE
kubia-53thy   1/1.       Terminating         0                3m
kubia-oini2   0/1.         ContainerCreating   0          2s
kubia-k0xz6   1/1.        Running             0                3m
kubia-q3vkg   1/1.        Running             0                3m

Replication Controller 지워보기

kubectl delete rc <name> —cascade=false
Cascade=false옵션을 사용하면 rc만 삭제하고 pod들은 실행상태로 남는다

[ReplicaSets]
ReplicationController는 deprecated되고 Replciasets로 모두 대체됨. New generation of ReplicationController.

무슨 차이가 있느냐?

• 똑같이 동작하지만, 더 많은 표현이 가능한 pod selectors를 가지고 있음
• Replication Controller : 이 라벨을 가진애만 고르는 것 가능
• ReplicaSets: 특정 라벨 포함하는 것 / 특정 라벨을 포함하지 않는 것 / 특정 라벨의 키만 일치하는 것, multiple label조건 .. 다 가능

ReplicaSets생성

apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
  name: kubia
spec:
  replicas: 3
  selector:
    matchExpressions:
      - key: app
        operator: In
        values:
         - kubia
  template:
    metadata:
      labels:
        app: kubia
    spec:
      containers:
      - name: kubia
        image: luksa/kubia

Selector에 표현식을 추가할 수 있다 . 각 표현식은 키, 연산자, 가능한 값이 포함되어야 한다

• In: label의 값이 지정된 값 중 하나와 일치해야 한다
• NotIn: label의 값이 지정된 값과 일치하지 않아야 한다
• Exists: Pod는 지정된 Key를 가진 label이 포함되어야 한다. (Value 상관없음)
• DoesNotExist: pod에 지정된 키를 가진 label이 포함되어 있지 않아야 한다.

[Daemonsets]

• 전체 Cluster에 무작위로 분산되어 배포되는 ReplicaSets와 달리, Daemonsets은. 각 노드에서 하나의 pod 복제본을 생성한다.
  (Exactly one replica on each node)
• 주로 system pod(예를 들면 ssd-monitor 같은 역할을 하는 pod) 를 배포할 때 node selector와 함께 이용한다.
  

DaemonSets 생성하기

apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
  name: ssd-monitor
spec:
  selector:
    matchLabels:
      app: ssd-monitor
  template:
    metadata:
      labels:
        app: ssd-monitor
    spec:
      nodeSelector:
        disk: ssd
      containers:
      - name: main
        image: luksa/ssd-monitor

[CronJob]

Job은 Pod의 컨테이너 내부에서 실행 중인 프로세스가 성공적으로 완료되면 컨테이너를 다시 시작하지 않는 pod를 실행할 수 있다

퀴즈타임

Q. CloudGenie 회사에 오늘 고용된 DevOps엔지니어인 클진 씨는 전임자에게 인수인계를 받지 못해 RC가 관리해야하는 Pod의 수를 알지 못한다. 첫 업무로 클러스터 안에서 RC에 의해 구동되고 있는 실제 pod들과 전임자가 의도했던 Pod들의 수가 맞는지 확인해보려면 어떤 작업을 해봐야할까?

A.

$ kubectl describe rc kubia
Labels:
Containers:   ...
 Name:
Namespace:
Selector: app=kubia
Labels: app=kubia
Annotations:    <none>
…생략

 Replicas:               3 current / 3 desired
Pods Status:          4 Running / 0 Waiting / 0 Succeeded / 0 Failed

Pod Template:
…

Q. Pod selector 라벨을 바꿔버리면 이미 RC에 의해 관리되던 pod들은 자동으로 스케줄링될까?