Kubernetes Controller

이번 포스트에서는 ReplicaSet, Deployment, DaemonSet, CronJob에 대해 다루겠습니다.

 

쿠버네티스 컨트롤러의 주요 기능

쿠버네티스에서 컨트롤러는 클러스터의 상태를 관리하고 운영을 자동화하는 핵심 구성 요소입니다. 컨트롤러는 정의된 '원하는 상태(Desired State)'와 '현재 상태(Current State)'를 지속적으로 비교하며, 차이가 발생할 경우 이를 일치시키는 조정을 수행합니다.

주요 기능은 다음과 같습니다.

1. 오토 힐링 (Auto-Healing)

• 기능: 파드(Pod) 또는 파드가 스케줄링된 노드에 장애가 발생하여 다운될 경우, 컨트롤러가 이를 즉각 인지합니다.
• 동작: 장애가 발생한 파드를 대체하기 위해 사용 가능한 다른 노드에 새로운 파드를 자동으로 생성하여 서비스 연속성을 보장합니다.

2. 오토 스케일링 (Auto-Scaling)

• 기능: 파드의 리소스 사용량이 설정된 임계치(Limit)에 도달하는 등 부하가 증가하는 상태를 파악합니다.
• 동작: 컨트롤러는 부하를 분산시키기 위해 파드의 복제본(Replica) 수를 자동으로 늘려(Scale-out) 서비스의 안정성과 성능을 유지합니다.

3. 롤링 업데이트 및 롤백 (Rolling Update & Rollback)

• 기능: 다수의 파드에 대한 애플리케이션 버전 업그레이드를 자동화합니다.
• 동작: 컨트롤러를 통해 순차적으로 파드를 업데이트(롤링 업데이트)할 수 있습니다. 업그레이드 과정에서 문제가 감지되면, 이전의 안정적인 버전으로 자동 롤백하는 기능을 제공하여 배포 안정성을 높입니다.

4. 임시 작업 실행 (Job / CronJob)

• 기능: 일괄 처리나 스케줄링된 작업 등 일시적인 작업을 수행해야 할 경우 사용됩니다.
• 동작: 컨트롤러는 작업 수행에 필요한 순간에만 파드를 생성하여 작업을 이행합니다. 작업이 완료되면 해당 파드를 자동으로 삭제하여, 작업이 실행되는 동안에만 자원을 사용하고 즉시 반환함으로써 자원 효율성을 극대화합니다.

---

1. Replicaset

 

1. 템플릿 (Template) 기능

컨트롤러와 파드는 서비스(Service)와 파드의 관계처럼 라벨(Label)과 셀렉터(Selector)를 통해 연결됩니다. 특정 라벨이 부착된 파드가 있고, 이 라벨과 일치하는 셀렉터를 가진 컨트롤러를 생성하면 둘은 연결됩니다.

컨트롤러를 정의할 때는 파드 템플릿(Pod Template)을 명세에 포함해야 합니다. 컨트롤러는 연결된 파드가 다운될 경우, 이 템플릿을 기반으로 파드를 재생성하는 오토 힐링 특성을 가집니다.

이러한 특성을 이용해 수동으로 애플리케이션 버전을 업그레이드할 수 있습니다.

1. 컨트롤러 정의 파일 내의 템플릿 내용을 v2 이미지 등 신규 버전으로 수정하여 적용합니다.
2. 컨트롤러에 연결된 기존 v1 파드를 수동으로 삭제합니다.
3. 컨트롤러는 파드의 개수가 부족함을 인지하고, 수정된 v2 템플릿을 기반으로 새 파드를 재생성합니다.
4. 결과적으로 파드의 버전 업그레이드가 완료됩니다.

2. 레플리카 (Replicas) 기능

컨트롤러의 replicas 필드는 유지해야 할 파드의 개수를 정의합니다.

• 개수 유지: replicas 수가 1일 때 해당 파드가 삭제되면, 컨트롤러는 즉시 1개의 파드를 재생성하여 설정된 개수를 유지합니다.
• 스케일 아웃 (Scale-out): replicas 값을 3으로 상향 조정하면, 컨트롤러는 부족한 개수만큼(2개) 파드를 추가로 생성하여 총 3개를 맞춥니다.
• 전체 복구: replicas가 3인 상태에서 3개의 파드가 모두 삭제되더라도, 컨트롤러는 즉시 3개의 파드를 모두 재생성합니다.

3. 컨트롤러 표준 사용 방식 (템플릿 + 레플리카)

실제 운영 환경에서는 파드와 컨트롤러를 별도로 생성하지 않습니다. replicas 수와 template 내용을 포함한 컨트롤러 정의 파일 하나만 작성하여 배포하는 것이 표준 방식입니다.

예를 들어 replicas: 2로 설정된 컨트롤러를 템플릿과 함께 생성하면, 컨트롤러는 현재 연결된 파드가 0개임을 인지합니다. 즉시 replicas 수(원하는 상태)를 맞추기 위해 내장된 템플릿을 기반으로 2개의 파드를 자동으로 생성합니다.

4. 셀렉터 (Selector) 기능: ReplicationController vs. ReplicaSet

지금까지 설명한 템플릿과 레플리카 기능은 ReplicationController와 ReplicaSet 모두에 공통으로 존재합니다.

두 컨트롤러의 핵심적인 차이는 셀렉터의 지원 범위에 있습니다.

ReplicationController (RC)

• 셀렉터 방식: 단순 일치 셀렉터만 지원합니다.
• 동작: 셀렉터에 정의된 키와 값이 파드의 라벨과 완벽하게 일치해야만 연결됩니다. 키와 밸류 중 하나라도 다르면 연결되지 않습니다.

ReplicaSet (RS)

ReplicaSet은 ReplicationController의 모든 기능을 포함하며, 더 확장된 셀렉터 기능을 제공합니다.

1. matchLabels
   • ReplicationController와 동일하게 동작합니다.
   • 지정된 키와 밸류가 라벨과 모두 일치해야 합니다.
2. matchExpressions
   • 더 복잡하고 유연한 라벨 매칭 규칙을 정의할 수 있습니다.
   • Operators (연산자):
     • Exists: 해당 키를 가진 라벨이 존재하면 매칭됩니다. (밸류는 상관하지 않음)
     • DoesNotExist: 해당 키를 가진 라벨이 존재하지 않으면 매칭됩니다.
     • In: 라벨의 밸류가 values 필드에 명시된 목록 중 하나와 일치하면 매칭됩니다.
     • NotIn: 라벨의 밸류가 values 필드에 명시된 목록 중 어느 것과도 일치하지 않으면 매칭됩니다.

---

2. Deployment

 

쿠버네티스 Deployment 컨트롤러를 설명하기에 앞서, 일반적으로 사용되는 4가지 주요 애플리케이션 업그레이드 배포 방식을 먼저 이해할 필요가 있습니다.

1. Recreate (재생성)

• 방법: 기존 버전(v1)의 모든 파드를 한 번에 종료시킨 후, 새로운 버전(v2)의 모든 파드를 동시에 생성합니다.
• 장점:
  • 구현 방식이 매우 단순합니다.
  • v1과 v2가 동시에 존재하는 기간이 없어, 시스템 상태가 깨끗하게 전환됩니다.
• 단점:
  • v1이 종료되고 v2가 시작되기까지 반드시 서비스 중단 시간이 발생합니다.

2. Rolling Update (롤링 업데이트)

• 방법: v2 파드를 점진적으로 하나씩 생성하면서, v1 파드를 하나씩 순차적으로 종료시킵니다. v2 파드가 정상 실행(Ready) 상태가 된 것을 확인한 후 다음 v1 파드를 종료하는 방식입니다.
• 장점:
  • 서비스 중단 시간 없이 배포가 가능합니다.
  • 문제가 발생할 경우, 전체 클러스터가 아닌 일부 파드에만 영향을 미칩니다.
• 단점:
  • 배포가 완료되기까지 시간이 오래 걸립니다.
  • 배포 중간 단계에서 v1과 v2 버전이 공존하게 되므로, 하위 호환성 문제가 발생할 수 있습니다.

3. Blue / Green (블루/그린)

• 방법: 현재 운영 중인 환경(Blue, v1)과 동일한 규모로 신규 버전 환경(Green, v2)을 별도로 구축합니다. Green 환경이 완벽히 준비되고 테스트가 완료되면, 로드 밸런서(Service)의 트래픽을 Blue에서 Green으로 한 번에 전환합니다.
• 장점:
  • 서비스 중단이 없으며, 트래픽 전환이 즉각적입니다.
  • v2(Green)에 문제가 발생하면 트래픽을 즉시 v1(Blue)로 롤백할 수 있습니다.
• 단점:
  • 운영 환경 2세트가 동시에 필요하므로 2배의 리소스가 필요합니다.

4. Canary (카나리)

• 방법: v1이 운영 중인 상태에서, v2를 소수의 파드에만 배포합니다. 그리고 실제 운영 트래픽의 일부만 v2로 라우팅하여 안정성을 테스트합니다. v2가 안정적이라고 판단되면 점진적으로 v2의 비율을 100%까지 늘려나갑니다.
• 장점:
  • 실제 운영 트래픽을 대상으로 v2를 테스트할 수 있어 가장 안전한 방식입니다. (A/B 테스트)
  • 문제가 발생해도 영향을 받는 사용자가 극히 일부입니다.
• 단점:
  • 트래픽 라우팅 등 구현 방식이 4가지 중 가장 복잡합니다.
  • 전체 배포가 완료되기까지 가장 오랜 시간이 소요될 수 있습니다.

 

 

Deployment는 서비스 업데이트 및 재배포 시나리오에서 도움을 주는 고수준 컨트롤러입니다.

Deployment와 ReplicaSet의 관계

Deployment의 핵심적인 특징은 파드(Pod)를 직접 관리하지 않고, ReplicaSet을 관리한다는 점입니다.

1. 사용자가 Deployment를 생성할 때 YAML 파일에 selector, replicas, template 값을 정의합니다.
2. Deployment 컨트롤러는 이 값들을 직접 사용하지 않고, 이 명세를 그대로 가진 새로운 ReplicaSet(RS)을 생성하는 데 사용합니다.
3. 생성된 ReplicaSet은 본연의 역할, 즉 replicas 수만큼 template을 기반으로 파드들을 생성하고 관리합니다.
4. 쿠버네티스 서비스(Service)는 파드의 라벨을 셀렉터로 사용하므로, RS가 생성한 파드들에 자동으로 연결되어 트래픽을 라우팅합니다.

Deployment의 'Recreate' 전략

Deployment의 배포 전략을 Recreate로 설정하고 템플릿을 v2로 업데이트하면 다음과 같이 동작합니다.

1. 사용자가 Deployment의 파드 템플릿(예: 이미지 버전)을 v2로 수정 후 적용합니다.
2. Deployment 컨트롤러는 기존 v1 ReplicaSet의 replicas 값을 0으로 변경합니다.
3. v1 RS는 자신의 replicas 수를 맞추기 위해 모든 v1 파드를 즉시 삭제합니다.
4. 이 순간 서비스가 바라볼 파드가 없어지므로 다운타임이 발생합니다.
5. Deployment 컨트롤러는 v2 템플릿 정보를 기반으로 새로운 v2 ReplicaSet을 생성합니다.
6. v2 RS는 정의된 replicas 수만큼 v2 파드들을 생성합니다.
7. 서비스는 동일한 라벨을 가진 v2 파드들을 자동으로 감지하고 트래픽을 연결합니다.

Deployment의 'Rolling Update' 전략 (기본값)

Deployment의 기본 전략(strategy.type: RollingUpdate)이 적용된 상태에서 템플릿을 v2로 업데이트하면 다음과 같이 동작합니다. (다운타임 없음)

1. v1 파드들이 v1 RS에 의해 운영 중이며, 서비스가 트래픽을 받고 있습니다.
2. 사용자가 Deployment 템플릿을 v2로 수정합니다.
3. Deployment 컨트롤러는 v2 템플릿을 기반으로 새로운 v2 ReplicaSet을 생성합니다. (이때 replicas는 1 또는 maxSurge 설정값만큼 시작됩니다.)
4. v2 RS가 v2 파드를 1개 생성합니다. 이 파드 역시 v1과 동일한 라벨을 가지므로, 서비스가 즉시 v1과 v2 파드 모두에게 트래픽을 분산하기 시작합니다.
5. Deployment 컨트롤러는 기존 v1 ReplicaSet의 replicas 값을 1 감소시킵니다. v1 파드 1개가 삭제됩니다.
6. v1 파드 삭제가 완료되면, Deployment는 v2 RS의 replicas를 1 증가시킵니다.
7. 이 과정(v1 감소, v2 증가)을 replicas 수만큼 반복합니다.
8. 최종적으로 v1 RS의 replicas는 0이 되고, v2 RS의 replicas는 사용자가 원하는 수에 도달합니다.

배포가 종료된 후에도 v1 RS는 삭제되지 않고 replicas: 0 상태로 남아있게 되며, 이는 추후 롤백 기능을 위해 사용됩니다.

---

3. DaemonSet, Job, CronJob

DaemonSet

1. 특징 및 사용 시점

DaemonSet(데몬셋)은 클러스터 내의 모든 노드 또는 특정 노드에 파드를 하나씩 배포하는 것을 보장하는 컨트롤러입니다.

ReplicaSet의 경우, 쿠버네티스 스케줄러가 노드의 가용 리소스에 의존하여 파드를 배치합니다. (예: 리소스가 여유로운 node-1에는 파드를 많이 배치하고, 리소스가 부족한 node-3에는 배치하지 않을 수 있습니다.)

반면, DaemonSet은 노드의 리소스 상태와 관계없이 각 노드마다 파드가 하나씩 실행되도록 강제합니다. 클러스터에 10개의 노드가 있다면 10개의 파드가 각 노드에 하나씩 생성됩니다.

 

2. 주요 사용 사례

이처럼 모든 노드에 설치되어야 하는 서비스들은 다음과 같습니다.

• 성능 수집 (모니터링): Prometheus와 같은 성능 수집 에이전트를 각 노드에 설치하여, 모든 노드의 성능 정보를 모니터링 시스템으로 전달해야 합니다.
• 로그 수집: fluentd와 같은 로그 수집 에이전트를 각 노드에 배포하여, 특정 노드에 장애 발생 시 로그를 수집하고 분석할 수 있도록 합니다.
• 스토리지: ClusterFS, GlusterFS 등 스토리지 솔루션을 각 노드에 설치하여 노드 자원을 활용한 네트워크 파일 시스템을 구축할 수 있습니다.
• 쿠버네티스 네트워킹: 쿠버네티스 자체도 CNI(Container Network Interface) 플러그인이나 kube-proxy 등 프록시 역할을 하는 파드를 DaemonSet으로 각 노드에 배포하여 네트워킹을 관리합니다.

3. 상세 기능

• 셀렉터 및 템플릿: ReplicaSet과 마찬가지로 템플릿을 기반으로 파드를 생성하고, 셀렉터와 라벨을 통해 이들을 연결합니다.
• nodeSelector: 기본적으로 DaemonSet은 모든 노드에 파드를 생성하지만, nodeSelector를 지정하면 특정 라벨(예: os: centos)을 가진 노드에만 파드를 배포할 수 있습니다. (예: Ubuntu OS에서는 실행할 수 없는 파드일 경우, os: ubuntu 라벨이 붙은 노드를 배포에서 제외할 수 있습니다.)
• hostPort: DaemonSet으로 배포된 파드는 해당 노드에서 직접 접근해야 하는 경우가 많습니다. hostPort 옵션을 사용하면 노드의 특정 포트가 파드 포트로 직접 연결되어, [노드 IP]:[hostPort]로 파드에 직접 접근할 수 있습니다.

Job

1. 특징 및 사용 시점

Job(잡)은 하나 이상의 파드를 실행하고, 해당 작업이 성공적으로 완료되면 종료되는 일회성(one-off) 작업을 관리합니다.

파드를 생성하는 주체(일반 Pod, ReplicaSet, Job)에 따라 노드 장애 시 동작이 달라집니다.

• 일반 파드 (Pod): 노드 다운 시, 파드도 함께 장애가 발생하며 서비스가 중단됩니다. (재생성 X)
• ReplicaSet: 노드 다운 시, 컨트롤러가 장애를 감지하고 다른 노드에 파드를 재생성(Recreate)합니다. 서비스 유지가 목적이므로, 프로세스가 종료되어도 파드를 재시작시킵니다.
  • *참고: Recreate는 파드 이름과 IP가 변경되며 새로 생성되는 것이고, Restart는 기존 파드 내의 컨테이너만 재기동하는 차이가 있습니다.
• Job: Job의 목적은 서비스 유지가 아니라 작업의 성공적인 완료입니다. 작업 프로세스가 정상 종료되면, Job은 ReplicaSet처럼 파드를 재시작하지 않고 파드를 '종료' 상태로 둡니다.

Job의 파드는 작업 완료 후 즉시 삭제되지 않고 '종료' 상태로 남아있습니다. 이는 사용자가 파드에 접근하여 작업 결과(로그)를 확인할 수 있도록 하기 위함이며, 확인 후에는 직접 삭제해야 합니다.

 

2. 상세 기능

• template: 실행할 파드의 명세를 정의합니다. (셀렉터는 Job이 자동으로 생성합니다.)
• completions: Job이 성공적으로 완료되어야 하는 횟수입니다. (예: completions: 6은 6개의 파드가 순차적으로 실행 완료되어야 Job이 종료됨을 의미합니다.)
• parallelism: 동시에 실행할 파드의 개수입니다. (예: parallelism: 2는 2개씩 병렬로 작업을 수행합니다.)
• activeDeadlineSeconds: Job의 최대 실행 시간(초)입니다. 이 시간이 초과되면 Job은 즉시 정지되며, 실행 중이던 모든 파드는 삭제되고 아직 실행되지 못한 파드도 더 이상 실행되지 않습니다.

CronJob

1. 특징 및 사용 시점

CronJob(크론잡)은 Job을 주기적인 스케줄에 따라 생성하고 실행하는 컨트롤러입니다.

일반적으로 Job을 단독으로 사용하기보다, CronJob을 통해 특정 시간에 반복적인 작업을 수행할 목적으로 사용됩니다. (예: 주기적인 백업, 리포트 생성, 예약 메시지 발송 등)

 

2. 상세 기능

• schedule: Job을 실행할 주기를 표준 크론(Cron) 포맷으로 지정합니다.
  (예: */1 * * * *는 1분마다 잡을 생성하라는 의미입니다.)
• jobTemplate: schedule에 따라 생성될 Job의 명세(템플릿)를 정의합니다. CronJob은 이 템플릿을 이용해 지정된 시간마다 새로운 Job 오브젝트를 생성합니다.
• concurrencyPolicy: 이전 Job이 아직 실행 중일 때 다음 실행 시간이 도래한 경우의 동작을 정의합니다.
  • Allow (기본값): 동시에 여러 Job이 실행되는 것을 허용합니다.
  • Forbid: 이전 Job이 실행 중이면 새 Job을 생성하지 않고 건너뜁니다.
  • Replace: 이전 Job이 실행 중이면, 해당 Job을 취소하고 새 Job으로 대체합니다.

 

Reference : https://inf.run/yW34