[이론] 쿠버네티스 Controller

유튜브 강의 '따배쿠'와 책 '쿠버네티스 입문'을 정리한 자료입니다.

 

---

📌  Kubernetes Contoroller란?

쿠버네티스의 컨트롤러는 파드들을 관리하는 역할을 한다. 또한 파드의 개수를 보장해준다. 또한 쿠버네티스 안에는 다양한 역할을 하는 컨트롤러들이 존재한다. 

• 웹 서비스처럼 오랜 시간동안 계속 실행되어야하는 파드 --> Replication Controller, Replicaset, Deployment 등
• 클러스터의 전체 노드에 같은 파드를 실행할 때 --> DaemonSet
• 1회성 작업을 할 때 사용하는 Job, 주기적인 배치 작업을 할때 CronJob 컨트롤러 등이 있다

 

---

📌  Replication Contoroller

Replication Contoller는 쿠버네티스 프로젝트의 초기부터 있었던 가장 기본적인 컨트롤러이다. RC는 요구하는 Pod의 개수를 보장하며 파드 집합의 실행을 항상 안정적으로 유지하는 것을 목표로 한다. 요즘은 RC보다는 비슷한 역할을 하는 레플리카세트와 Deployment를 주로 사용하는 추세이다.

- Replication Controller의 특징

• 요구하는 Pod의 개수가 부족하면 template를 이용해 Pod를 추가
• 요구하는 Pod 수 보다 많으면 최근에 생성된 Pod를 삭제
• 기본 구성 - selector, replicas, template

# replication-controller.yaml

apiVersion: v1
kind: ReplicationController
metadata:
  name: <RC_NAME>
spec:
  replicas: <DEPLOY_NUM>
  selector:
    <KEY>: <VALUE>
  template:
    <CONTAINER TEMPLATE>
    
# label 확인
$ kubectl get pod --show-labels

 

---

📌  Replica Set

Replica Set는 레플리케이션 컨트롤러의 발전형이다. RC와 같은 동작을 하지만 집합 기반의 select를 지원하는 차이점이 있다.

또한,  RC는 kubectl에서 rolling-update 옵션을 사용할 수 있지만 RS는 사용할 수 없다는 차이점도 있다. 대안법으로 rolling-update옵션이 필요하다면 Deployment를 사용해야한다.

- Replica set Template 확인

apiVersion: v1
kind: Replica Set
metadata:
  name: <RS_NAME>
spec:
  selector:
    matchLabels:
      component: redis
    matchExpressions:
      - {key: tier, operator: In, values: [cache]}
      - {key: environment, operator: NotIn, values: [dev]
    replicas: 3
    tempalte:

• spect.selector : label 체크 조건
• spec.replicas : 원하는 Pod의 개수
• spec.template : 생성할 Pod의 명세

 

- label 주의점

ReplicaSet은 label을 체크해서 원하는 수의 Pod가 없으면 새로운 Pod를 생성한다. 그렇기 때문에 생성 될 Pod의 label을 신경써서 작성해줘야한다.

- matchExpression 연산자
In : key와 values를 지정하여 key, value가 일치하는 Pod만 연결
NotIn : key는 일치하고 value는 일치하지 않는 Pod에 연결
Exists : key에 맞는 label의 pod를 연결
DoesNotExist : key와 다른 label의 pod를 연결

 

---

📌  Rolling Update를 위한 Deployment

Deployment는 ReplicaSet을 컨트롤해서 Pod의 수를 조절하고 앱 배포를 더 세밀하게 관리한다. Deployment는 파드 개수를 보장하는 것 뿐만아니라 앱을 배포할 때 Rolling Update & Rolling Back 등의 기능도 지원한다.

Deployment의 Rolling Update

 

- Deployment Template 확인

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-deploy
spec:
  replicas: 4
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      labels:
        app: webui
    spec:
      containers:
        - name: web
          image: nginx:1.14
          ports:
          - containerPort: 80

template를 확인해보면 type을 제외하곤 ReplicaSet과 완전히 동일하다.

- Deployment 동작 원리

https://subicura.com/k8s/guide/

1. Deployment Controller는 Deployment조건을 감시하면서 현재 상태와 원하는 상태가 다른 것을 체크
2. Deployment Controller가 원하는 상태가 되도록 ReplicaSet 설정
3. ReplicaSet Controller는 ReplicaSet조건을 감시하면서 현재 상태와 원하는 상태가 다른 것을 체크
4. ReplicaSet Controller가 원하는 상태가 되도록 Pod을 생성하거나 제거
5. Scheduler는 API서버를 감시하면서 할당되지 않은unassigned Pod이 있는지 체크
6. Scheduler는 할당되지 않은 새로운 Pod을 감지하고 적절한 노드node에 배치
7. 이후 노드는 기존대로 동작

 

- Deployment 버전 관리와 배포 전략 설정

Deployment는 변경된 상태를 기록합니다.

# 히스토리 확인
kubectl rollout history deploy/app-deploy

# revision 1 히스토리 상세 확인
kubectl rollout history deploy/app-deploy --revision=1

# 바로 전으로 롤백
kubectl rollout undo deploy/app-deploy

# 특정 버전으로 롤백
kubectl rollout undo deploy/app-deploy --to-revision=2

 

 

Deploy는 다양한 배포 전략을 지원한다. 다음과 같이 미리 템플릿을 통해 지정할 수 있다.

strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%

• maxSurge로 업데이트  시, 동시에 Running 중인 최대 파드의 수를 정할 수 있다.
• maxUnavailable은 업데이트 시, 사용할 수 없는 최대 파드의 수를 지정하는 선택적 필드이다.
• replicas를 3개 운영중이라면
  • 50%일 때, 3 + 2(1.5의 반올림) = 5, 최대 5개를 운영하고
  • 25%라면, 3 + 1(0.75의 반올림) = 4, 최대 4개를 운영하라는 의미이다.

 

 

[참고] https://subicura.com/k8s/guide/