쿠버네티스(2) - 컨트롤러

2-1 컨트롤러란?

쿠버네티스 컨트롤러는 파드를 관리하는 역할을 한다.

즉 파드(컨테이너)의 상태를 판단해 문제가 생기면 재생성, 관리를 해주는 역할을 한다.

 

컨트롤러는 다양한 목적에 따라 쿠버네티스에서 제공하는 컨트롤러를 사용하면 된다. 쿠버네티스에서 제공하는 컨트롤러의 종류로는 "레플리케이션 컨트롤러", "레플리카 세트", "디플로이먼트", "데몬" , "스테이트풀세트", "크론잡" 등이 있다.

 

2-2 각 컨트롤러의 용도

일반적으로 상태를 유지하지 않아도 되는 파드를 관리하는 경우

• 레플리케이션 컨트롤러(Relication Controller) // 디플로이먼트(레플리카 셋) 때문에 거의 사용안함
• 레플리카 셋(Replica Set) // 레플리카 셋을 직접적으로 사용안하고 디플로이먼트를 사용
• 디플로이먼트(Deployment) // 디플로이먼트가 레플리카 셋을 관리함

 

클러스터 전체에 배포가 필요한 파드를 관리하는 경우

• 데몬 셋(Deamon Set)

상태관리가 필요한 파드를 관리하는 경우

• 스테이트풀세트(Stateful Set)

배치성 작업을 진행하는 파드를 관리하는 경우

• 잡(Job)
• 크론잡(Cronjob)

 

2-3 레플리케이션 컨트롤러

레플리케이션 컨트롤러는 쿠버네티스에서 파드의 안정적인 상태를 유지하기 위해 사용된다.

이는 지정된 수의 파드가 항상 실행되도록 보장한다.

예를 들어, 파드가 종료되거나 삭제되면 레플리케이션 컨트롤러는 새 파드를 생성하여 원하는 상태를 유지한다.

 

주요 기능:

• 복제: 지정된 수의 파드를 유지
• 자체 복구: 파드가 종료되면 자동으로 새로운 파드를 생성.

apiVersion: v1
kind: ReplicationController
metadata:
  name: my-rc
spec:
  replicas: 3
  selector:
    app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx

 

2-4 레플리카 셋

레플리카 셋은 레플리케이션 컨트롤러의 발전된 형태이다.

레플리카 셋은 동일한 기능을 제공하지만, 더 유연한 라벨 셀렉터를 지원한다.

이는 복잡하고 세밀한 조건을 통해 파드를 선택할 수 있게 한다.

 

주요기능:

• 레플리케이션 컨트롤러의 기능 포함: 지정된 수의 파드를 유지.
• 향상된 라벨 셀렉터: 더 유연한 파드 선택 가능.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      
	  혹은
	  
		matchExpressions:
      - key: app
        operator: In
        values:
          - my-app
          - another-app
      - key: tier
        operator: NotIn
        values:
          - backend
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx

 

2-5 디플로이먼트

디플로이먼트는 레플리카 셋을 관리하는 더 높은 수준의 쿠버네티스 오브젝트이다.

디플로이먼트를 사용하면 애플리케이션을 선언적 방식으로 배포, 업데이트 및 롤백할 수 있다.

디플로이먼트는 파드의 상태를 관리하며, 새로운 버전의 애플리케이션을 배포하거나, 기존 버전으로 롤백할 수 있는 기능을 제공한다.

 

주요 기능:

• 레플리카 셋 관리: 자동으로 레플리카 셋을 생성하고 관리.
• 롤링 업데이트: 애플리케이션의 무중단 배포 가능.
• 롤백: 이전 버전으로 쉽게 롤백 가능.
• 스케일링: 파드 수를 쉽게 조정 가능.

 

2-6 데몬 셋

데몬셋은 쿠버네티스에서 모든 노드에 특정 파드를 실행하도록 보장하는 리소스 유형이다.

데몬셋(DaemonSet)은 각 노드에 정확히 하나의 파드가 실행되어야 하는 경우에 사용된다.

예를 들어, 로깅이나 모니터링 에이전트와 같은 작업을 모든 노드에 배포할 때 유용하다.

대표적인 예가 kube-proxy 프로세스로, 서비스가 정상 작동하려면 모든 노드에서 실행되어야 한다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx

 

2-7 잡

잡은 쿠버네티스에서 일회성 작업을 수행하기 위한 리소스이다.

잡은 특정 작업을 한 번 실행한 후 완료되는 것을 목표로 한다.

잡이 성공적으로 완료되면, 작업이 성공적으로 실행되었음을 나타낸다.

잡은 여러 종류의 패턴으로 실행될 수 있다.

1. 단일 작업: 한 번만 실행되는 작업이다.
2. 병렬 작업: 동시에 여러 파드를 실행하여 작업을 병렬로 처리할 수 있다.

 

잡의 주요 속성

• 종료 후 유지: 기본적으로 잡이 완료되면 파드는 삭제되지 않습니다. 그러나 이를 수정하여 완료 후 파드를 삭제할 수 있다.
• 재시도: 잡이 실패하면 지정된 재시도 횟수만큼 다시 시도할 수 있다.
• 완료 상태: 잡이 성공적으로 완료되면 Succeeded 상태가 됩니다. 실패하면 Failed 상태가 된다.

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  ttlSecondsAfterFinished: 100  # 잡이 완료된 후 100초 뒤에 파드를 삭제 (default는 삭제되지않음)
  template:
    spec:
      containers:
      - name: example
        image: busybox
        command: ["echo", "Hello, Kubernetes!"]
      restartPolicy: Never

이 예제는 한 번 실행되어 "Hello, Kubernetes!"를 출력하는 잡을 정의한다.

 

2-8 크론잡

크론잡은 잡을 주기적으로 실행하기 위한 쿠버네티스 리소스이다.

크론잡은 UNIX의 cron 스케줄러와 유사하게 일정에 따라 잡을 실행한다.

크론잡의 주요 속성

• 스케줄: cron 형식으로 지정된 스케줄에 따라 잡을 실행한다. 예를 들어, */5 * * * *는 매 5분마다 작업을 실행한다.
• 잡 템플릿: 크론잡이 실행할 잡의 템플릿을 정의한다. 이 템플릿은 잡의 설정을 포함한다.
• 이력 관리: 완료된 잡의 이력을 관리할 수 있습니다. 유지할 성공적인 잡과 실패한 잡의 최대 개수를 지정할 수 있다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: example-cronjob
spec:
  schedule: "*/5 * * * *" # 5분마다 실행되어 "Hello, Kubernetes CronJob!"을 출력
  jobTemplate:
    spec:
      ttlSecondsAfterFinished: 60  # 완료된 후 60초 후에 삭제
      template:
        spec:
          containers:
          - name: example
            image: busybox
            command: ["echo", "Hello, Kubernetes CronJob!"]
          restartPolicy: OnFailure
    successfulJobsHistoryLimit: 1  # 성공한 Job을 1개만 유지
    failedJobsHistoryLimit: 1      # 실패한 Job을 1개만 유지

위의 예시에서 Cron Job은 5분마다 Job을 생성하며, 각 Job은 Pod를 생성하여 "Hello, Kubernetes CronJob!"을 출력한다.

successfulJobsHistoryLimit과 failedJobsHistoryLimit를 설정하면 지정된 개수 이상의 성공한 Job및 실패한 Job은 자동으로 삭제된다.

ttlSecondsAfterFinished를 설정하면 Job이 완료된 후 지정된 시간이 지나면 Job이 자동으로 삭제된다.

이렇게 설정하면 CronJob이 생성한 Job과 Pod가 무한정 쌓이는 것을 방지할 수 있다.

 

2-9 Deployment Update

 

1. Rolling Update(Default) : Pod를 하나씩 점진적으로 교체해나가는 방법 (무중단 배포)

...
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 30% # 업데이트 중에 사용할 수 없는 파드의 최대 수를 지정합니다. (Default 25%)
      maxSurge: 30% # 업데이트 중에 추가로 생성할 수 있는 파드의 최대 수를 지정합니다. (Default 25%)

 

 

2. Recreate : 기존의 Pod을 모두 삭제한 뒤, 새로운 버전의 Pod을 선언한 갯수만큼 생성해주는 방식 (Pod가 존재하지 않는 순간이 존재할 수 있음)

...
spec:
  replicas: 3
  strategy:
    type: Recreate

 

 

3. Blue/Green : 기존 버전의 Pod을 유지한채로 새로운 버전의 Pod을 선언한 갯수만큼 생성하고 Service가 트래픽을 전달하는 대상을 교체한 뒤 기존의 Pod을 삭제하는 방식 (무중단 배포, 배포시 자원을 2배로 사용)

# Blue Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blue-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: my-container
        image: my-app:1.0.0
        ports:
        - containerPort: 80
---
# Green Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: green-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
      - name: my-container
        image: my-app:2.0.0
        ports:
        - containerPort: 80
---
# Blue Service
apiVersion: v1
kind: Service
metadata:
  name: blue-service
spec:
  selector:
    app: my-app
    version: blue
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---
# Green Service
apiVersion: v1
kind: Service
metadata:
  name: green-service
spec:
  selector:
    app: my-app
    version: green
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---
# Ingress for Traffic Switching
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: blue-service  # 이 부분을 green-service로 변경하여 blue/green 업데이트를 진행
            port:
              number: 80
              
# kubectl patch service blue-service -p '{"spec":{"selector":{"app":"my-app","version":"green"}}}'
# kubectl patch service blue-service -p '{"spec":{"selector":{"app":"my-app","version":"blue"}}}'

 

 

4. Canary : Canary는 테스트라는 특징을 가지고 있는 업데이트 방법이다. 구버전과 신버전 Pod을 모두 구성한 뒤, 트래픽의 양을 조절하여 테스트를 진행한 다음 교체하는 방식이다.

 

2-10 Deployment rollback

Deployment rollback은 이전 상태로 애플리케이션을 되돌리는 프로세스이다.

이는 애플리케이션을 업데이트하다가 문제가 발생했을 때, 또는 예상치 못한 이유로 원하는 이전 상태로 되돌아가야 할 때 유용하게 사용된다.

# 현재 상태 확인: 현재 Deployment의 상태와 롤아웃 히스토리를 확인한다.
$ kubectl get deployments
$ kubectl rollout history deployment <deployment-name>

# 가장 최근에 성공한 롤아웃으로 롤백 
$ kubectl rollout undo deployment <deployment-name>

# 특정 히스토리 버전으로 롤백
$ kubectl rollout undo deployment <deployment-name> --to-revision=<revision-number>

# 롤백 상태 확인
$ kubectl rollout status deployment <deployment-name>

# 상세한 히스토리 확인
$ kubectl rollout history deployment <deployment-name>

 

2-11 스테이트풀 세트

스테이트풀 세트는 Kubernetes에서 관리하는 파드의 새로운 형태로, 주로 지속적인 데이터를 가지는 애플리케이션에 적합한 컨트롤러이다.

 

스테이트풀 세트는 각 파드에 고유한 식별자를 할당하고, 파드의 배치 순서를 보장하여 안정적인 네트워킹과 저장 장치의 관리를 지원한다.

 

스테이트풀 셋의 사용예시:  DB Replication

statefulset뿐만 아니라 storageClass, headless svc, (pvc, pv동적 생성)을 통해서 Replication를 구현해야하고,어플리케이션내에서도 설정이 필요하다.

 

주요 특징과 사례

1. 고유한 식별자 (Stable Network Identity):
   • 스테이트풀 세트는 각 파드에 고유한 식별자를 부여한다. 이는 각 파드가 네트워킹에서 안정적으로 식별될 수 있도록 도와준다.
   • 예를 들어, myapp-0, **myapp-1**과 같은 식별자를 갖는 파드가 있다.
2. 순차적 배치 (Ordered, Graceful Deployment and Scaling):
   • 스테이트풀 세트는 파드를 순차적으로 배치하며, 일반적인 디플로이먼트와 달리 하나의 파드가 준비 상태가 되기 전에 다음 파드를 배포하지 않는다.
   • 이는 데이터베이스와 같은 상태를 가지는 애플리케이션에서 중요한 요구사항이다.
3. 볼륨 관리 (Persistent Storage):
   • 스테이트풀 세트는 각 파드에 지속적인 데이터를 관리하기 위한 볼륨을 제공할 수 있다. 예를 들어, PersistentVolumeClaim (PVC)를 사용하여 각 파드에 데이터베이스 파일을 마운트할 수 있다.
4. 고가용성 (High Availability):
   • 스테이트풀 세트는 파드를 정의된 순서대로 배치하고 재시작하여, 클러스터의 다양한 노드에 걸쳐 고가용성을 보장한다.
   • 각 파드는 그 자체로 다른 파드와 독립적으로 관리되며, 여러 노드에 걸쳐 분산될 수 있다.

 

스테이트풀 세트 vs 디플로이먼트

• 스테이트풀 세트: 각 파드가 고유한 식별자를 갖고, 순차적 배치와 안정적인 네트워크 식별을 지원하며, 지속적인 데이터를 가진 애플리케이션에 적합하다.
• 디플로이먼트: 무상태(stateless) 애플리케이션을 배포할 때 주로 사용되며, 파드의 순서나 식별자에 큰 의미가 없고, 빠르고 확장 가능한 배포를 위해 최적화되어 있다.

 

statefulset과 headless Service의 아키텍처

• 스테이트풀 세트는 spec.serviceName 필드를 가지고 있다. 여기에 service를 적어준다.
• .spec.podManagementPolicy: OrderedReady(default), Parallel StatefulSet은 Pod를 생성할때 순차적으로 기동되고, 삭제할때도 순차적으로 삭제한다. 그런데 만약 그런 요건이 필요 없이 전체가 같이 기동되도 된다면 .spec.podManagementPolicy 를 Parallel로 수정하면 된다.