쿠버네티스 컨트롤러 : 회사 인사팀

날아올라돼지야·2024년 9월 5일

쿠버네티스 마스터

목록 보기

23/27

쿠버네티스의 주요 컨트롤러들을 회사의 부서와 관리 체계로 비유하여 쉽게 설명드리겠습니다. 각 컨트롤러가 회사에서 어떤 역할을 맡고 있는지 이해하기 쉽도록 ReplicaSet과 같은 방식으로 설명해볼게요.

1. ReplicationController (구 버전 인원 유지 관리팀)

비유: 초기 인원 유지 관리팀
ReplicationController는 초기의 인원 유지 관리팀입니다. ReplicaSet과 마찬가지로 회사에서 정해진 수의 인원을 유지하게 합니다. 만약 팀원(파드)이 부족하면 새로 채용하고, 팀원이 많으면 그 수를 줄입니다.

역할:

파드 수 유지: 설정된 수의 파드가 항상 실행 중인지 보장합니다.
자동 복구: 파드가 실패하거나 중단되면 새로운 파드를 생성합니다.
라벨 셀렉터: 기존에 실행 중인 파드를 관리할 때 라벨을 통해 선택합니다.

YAML 예시:

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend
spec:
  replicas: 3  # 3개의 파드를 유지
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-server
        image: nginx:1.17
        ports:
        - containerPort: 80

2. ReplicaSet (최신 인원 유지 관리팀)

비유: 인원 유지 관리팀
ReplicaSet은 회사에서 특정 팀(파드)에 항상 정해진 수의 직원을 유지하게 하는 관리팀입니다. 인원이 부족해지면 새로운 직원을 채용하고, 인원이 너무 많으면 불필요한 인원을 정리합니다.

역할:

복제된 파드 수 유지: 설정된 수의 파드가 항상 유지되도록 보장합니다.
자동 복구: 파드가 실패하거나 중단되면 새로운 파드를 생성합니다.

YAML 예시:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3  # 3개의 파드 유지
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-server
        image: nginx:1.17
        ports:
        - containerPort: 80

ReplicaSet과 ReplicationController의 차이점:

ReplicationController는 ReplicaSet의 이전 버전이라고 보시면 됩니다. 기능적으로는 매우 비슷하지만, 기술적으로는 ReplicaSet이 더 발전된 버전입니다. 여전히 몇몇 환경에서는 ReplicationController를 사용하는 경우도 있으므로, 함께 알아두면 좋습니다.

라벨 셀렉터: ReplicaSet은 set-based label selector를 지원하는 반면, ReplicationController는 equality-based label selector만 지원합니다. 이 차이로 인해 ReplicaSet이 더 정교한 선택을 할 수 있습니다.

https://velog.io/@captain-yun/ReplicationController%EA%B3%BC-ReplicaSet%EC%9D%98-%EB%9D%BC%EB%B2%A8-%EC%85%80%EB%A0%89%ED%84%B0-%EB%B9%84%EA%B5%90

유연성: ReplicaSet은 보다 최신의 쿠버네티스 기능과 호환되며, 더 유연한 사용이 가능합니다.

ReplicationController는 오래된 방식이기 때문에 현재는 대부분 ReplicaSet이 그 자리를 대체하고 있지만, 기존 클러스터에서는 여전히 ReplicationController가 사용되기도 합니다.

3. Deployment (업데이트 관리팀)

Deployment는 ReplicaSet을 생성하고 관리하는 상위 리소스입니다. Deployment는 파드의 생성, 업데이트, 삭제를 더 유연하게 관리할 수 있도록 설계되었으며, 주로 롤링 업데이트(Rolling Update)와 롤백(Rollback) 기능을 제공합니다.

Deployment가 관리하는 역할:

파드의 롤링 업데이트: 애플리케이션의 새로운 버전을 배포할 때, 기존 파드를 하나씩 대체하면서 중단 없이 업데이트를 진행합니다.
롤백 기능: 문제가 발생할 경우, 이전 버전으로 쉽게 되돌릴 수 있습니다.
ReplicaSet 관리: Deployment는 새로운 ReplicaSet을 생성하고, 이전 ReplicaSet을 점진적으로 제거하는 방식으로 업데이트를 수행합니다.

YAML 예시:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-deployment
spec:
  replicas: 3  # 파드 수를 설정
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-server
        image: nginx:1.17
  strategy:
    type: RollingUpdate  # 롤링 업데이트 전략
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

Deployment와 ReplicaSet의 관계

Deployment는 ReplicaSet을 관리하는 컨트롤러입니다. 즉, Deployment는 직접 파드를 관리하지 않고, ReplicaSet을 통해 간접적으로 파드를 관리합니다. Deployment는 다음과 같은 방식으로 동작합니다:

Deployment가 ReplicaSet을 생성:
- Deployment를 생성하면, ReplicaSet이 자동으로 만들어집니다. 이 ReplicaSet은 Deployment의 파드 템플릿에 기반하여 파드를 실행합니다.
롤링 업데이트 시 새로운 ReplicaSet 생성:
- 새로운 버전의 애플리케이션을 배포할 때, Deployment는 새로운 ReplicaSet을 생성합니다.
- 새로운 버전의 파드를 가진 ReplicaSet을 점진적으로 생성하고, 이전 ReplicaSet을 점차 줄여가며 롤링 업데이트를 수행합니다.
여러 ReplicaSet을 관리:
- Deployment는 여러 ReplicaSet을 동시에 관리할 수 있습니다. 업데이트 중에도 이전 ReplicaSet이 유지되기 때문에, 문제가 발생하면 즉시 이전 상태로 롤백이 가능합니다.
- Deployment는 현재 활성화된 ReplicaSet과 이전 버전의 ReplicaSet을 모두 추적합니다.
롤백 기능:
- 만약 새로 배포한 버전에서 문제가 발생하면, Deployment는 이전 버전의 ReplicaSet으로 롤백할 수 있습니다. 이를 통해 신속하게 애플리케이션을 복구할 수 있습니다.

동작 예시: 롤링 업데이트

1. 처음에 Deployment를 생성:

Deployment는 nginx:1.17 이미지로 ReplicaSet을 만들고, 3개의 파드를 실행합니다.

2. 새로운 버전 배포:

이제 이미지를 nginx:1.18로 업데이트한다고 가정하면, Deployment는 새 ReplicaSet을 생성하여 nginx:1.18 버전의 파드를 하나씩 추가합니다.
기존 nginx:1.17 파드는 점진적으로 삭제됩니다.

3. 롤백 상황:

만약 nginx:1.18 버전에서 문제가 발생하면, Deployment는 즉시 이전 버전(nginx:1.17)을 실행하는 ReplicaSet을 활성화하여 문제를 해결할 수 있습니다.

즉, ReplicaSet은 파드의 개수를 유지하는 역할을 맡고 있으며, Deployment는 ReplicaSet을 관리하면서 배포, 업데이트, 롤백 같은 고급 기능을 수행합니다. 또한 Deployment는 새로운 ReplicaSet을 생성하면서 애플리케이션을 업데이트하고, 필요에 따라 롤백하여 안정적으로 애플리케이션을 운영할 수 있게 합니다.

이렇게 Deployment와 ReplicaSet은 밀접한 관계를 가지며, ReplicaSet이 파드를 직접 관리하는 반면, Deployment는 그 위에서 배포와 버전 관리 등 더 넓은 범위의 작업을 수행합니다.

Deployment → ReplicaSet → Pod 의 관계

Deployment는 가장 상위 레벨에서 애플리케이션의 배포와 업데이트를 관리하는 "조부모" 역할을 합니다.
ReplicaSet은 Deployment가 생성하고 관리하는 "부모" 역할을 하며, 파드(Pod)의 개수를 조정하고 유지하는 책임을 집니다.
Pod는 애플리케이션이 실제로 동작하는 가장 하위 레벨의 "자식"으로, 애플리케이션 컨테이너가 실행되는 기본 단위입니다.

이 관계를 단계별로 보면:

Deployment (조부모): 애플리케이션의 버전 업데이트, 롤백, 롤링 업데이트 등을 관리하며, 그 결과로 ReplicaSet을 생성하고 관리합니다.
ReplicaSet (부모): Deployment가 지시한 대로 파드의 개수를 유지하며, 파드의 생성과 삭제를 책임집니다.
Pod (자식): 실제 애플리케이션이 실행되는 곳으로, 각 컨테이너는 파드 안에서 실행됩니다.

4. StatefulSet (특수 인력 관리팀)

비유: 데이터베이스 및 고유 식별 관리팀
StatefulSet은 특정한 순서와 고유한 식별자가 중요한 부서를 관리합니다. 마치 데이터베이스와 같이 특별한 번호가 붙은 서버들이 필요할 때, 이 팀은 각 서버가 순서대로 배치되며 고유한 아이디를 가지고 관리되도록 합니다.

역할:

고유한 파드 관리: 파드마다 고유한 ID가 부여되며, 특정 순서로 생성되고 제거됩니다.
데이터 영속성: 파드가 재시작되더라도 그 파드의 데이터와 고유한 정보가 유지됩니다.

YAML 예시:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db-statefulset
spec:
  serviceName: "db"
  replicas: 3
  selector:
    matchLabels:
      app: database
  template:
    metadata:
      labels:
        app: database
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-persistent-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

5. DaemonSet (전사적 배포팀)

비유: 회사의 모든 부서에 필수 서비스를 배포하는 팀
DaemonSet은 회사의 모든 부서에 필수적인 소프트웨어를 설치하는 역할을 합니다. 예를 들어, 보안 소프트웨어나 모니터링 도구가 모든 서버(노드)에 설치되도록 보장합니다.

역할:

각 노드에 파드 배포: 각 서버마다 동일한 파드가 하나씩 배포됩니다.
시스템 관리: 로깅, 모니터링, 보안과 같은 시스템 전반에 걸쳐 실행되는 서비스가 필요할 때 유용합니다.

YAML 예시:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-daemon
spec:
  selector:
    matchLabels:
      name: log-agent
  template:
    metadata:
      labels:
        name: log-agent
    spec:
      containers:
      - name: log-agent
        image: fluentd:latest

6. Job (단기 프로젝트 팀)

비유: 단기 프로젝트 팀
Job은 회사에서 단기적으로 일회성 작업을 처리하기 위해 운영되는 프로젝트 팀과 같습니다. 특정 작업을 완료한 후 종료되며, 다시 시작할 필요가 없습니다.

역할:

한 번 실행 후 완료: 파드를 생성하여 작업을 완료하면 해당 파드는 종료됩니다.
재시작 가능: 만약 작업 중 문제가 발생하면, 다시 시작하여 작업을 완료할 수 있습니다.

YAML 예시:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-job
spec:
  template:
    spec:
      containers:
      - name: backup
        image: backup-tool:latest
        command: ["backup", "/data"]
      restartPolicy: OnFailure

7. CronJob (정기적인 작업팀)

비유: 회사의 정기적인 업무를 관리하는 팀
CronJob은 매일 일정한 시간에 해야 하는 정기적인 업무를 관리합니다. 예를 들어, 매일 밤에 백업 작업을 하거나, 주기적으로 보고서를 생성하는 업무를 처리합니다.

역할:

주기적으로 작업 수행: 설정된 시간마다 작업을 실행합니다.
정기적인 관리: 정해진 일정에 따라 작업을 자동으로 반복 실행합니다.

YAML 예시:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-backup
spec:
  schedule: "0 2 * * *"  # 매일 새벽 2시에 실행
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: backup-tool:latest
            command: ["backup", "/data"]
          restartPolicy: OnFailure

종합적으로 정리

쿠버네티스의 다양한 컨트롤러는 마치 회사에서 다양한 부서와 관리 팀이 제각기 역할을 하듯이 각기 다른 목적을 위해 존재합니다.

ReplicationController: 구 버전 인원 유지 관리팀
ReplicaSet: 최신 인원 유지 관리팀
Deployment: 시스템 업데이트 관리팀 (무중단 서비스 업데이트)
StatefulSet: 특수 인력 관리팀 (고유한 ID가 필요한 파드 관리)
DaemonSet: 필수 소프트웨어 배포팀 (모든 서버에 필수 서비스 설치)
Job: 단기 프로젝트 팀 (한 번 실행 후 종료)
CronJob: 정기적인 작업팀 (일정한 주기로 작업 반복)

이렇게 각 컨트롤러가 특정 목적에 맞춰 서버와 파드를 관리함으로써, 회사와 같은 복잡한 시스템이 원활하게 돌아가게 됩니다.

날아올라돼지야

무슨 생각하며 사니

다음 포스트

쿠버네티스 컨트롤러 : 회사 인사팀

쿠버네티스 마스터

1. ReplicationController (구 버전 인원 유지 관리팀)

2. ReplicaSet (최신 인원 유지 관리팀)

ReplicaSet과 ReplicationController의 차이점:

3. Deployment (업데이트 관리팀)

Deployment와 ReplicaSet의 관계

동작 예시: 롤링 업데이트

1. 처음에 Deployment를 생성:

2. 새로운 버전 배포:

3. 롤백 상황:

Deployment → ReplicaSet → Pod 의 관계

4. StatefulSet (특수 인력 관리팀)

5. DaemonSet (전사적 배포팀)

6. Job (단기 프로젝트 팀)

7. CronJob (정기적인 작업팀)

종합적으로 정리

롤링 업데이트 실습1

0개의 댓글