오토에버 클라우드 2기 43일차

Posted Jul 2, 2025 Updated Jul 14, 2025

By minnnning

11 min read

오토에버 클라우드 2기 43일차

Workload API: 컨테이너 실행과 관리

Workload API는 쿠버네티스 클러스터에 컨테이너를 기동시키기 위한 리소스들의 집합 Pod를 기본 단위로 하여, 이를 관리하고 제어하는 다양한 컨트롤러(Controller)들로 구성됨

리소스 관계도

graph TD;
    subgraph "High-Level Controllers"
        Deployment("Deployment (가장 일반적)");
        CronJob;
    end

    subgraph "Mid-Level / Direct Controllers"
        ReplicaSet;
        Job;
        DaemonSet;
        StatefulSet;
        ReplicaController["ReplicaController (구버전)"];
    end

    subgraph "Workload Unit"
        Pod;
    end

    Deployment -- "manages" --> ReplicaSet;
    ReplicaSet -- "creates / scales" --> Pod;

    CronJob -- "schedules" --> Job;
    Job -- "creates" --> Pod;

    DaemonSet -- "ensures on every node" --> Pod;
    StatefulSet -- "manages stateful apps" --> Pod;
    ReplicaController -- "creates / scales" --> Pod;

1. Pod: 쿠버네티스의 최소 배포 단위

Pod는 쿠버네티스의 가장 작은 배포 단위로, 하나 이상의 컨테이너가 모인 집합체 동일한 파드 내의 컨테이너끼리는 네트워크(IP 주소)와 스토리지를 공유하며 localhost로 통신 가능

Pod 디자인 패턴

사이드카 패턴 (Sidecar Pattern): 메인 컨테이너에 로그 수집, 설정 동기화 등 보조적인 기능을 수행하는 서브 컨테이너를 포함시키는 패턴
앰배서더 패턴 (Ambassador Pattern): 메인 컨테이너가 외부 시스템에 접속할 때, 중간에서 대리(프록시) 역할을 하는 서브 컨테이너를 포함시키는 패턴 이를 통해 개발/운영 환경 변경 없이 메인 컨테이너는 항상 localhost로 접속하도록 구성 가능
어댑터 패턴 (Adapter Pattern): 메인 컨테이너의 출력 데이터 형식을 외부 시스템(예: 모니터링 도구)의 요구사항에 맞게 변환해주는 컨테이너를 포함시키는 패턴

Pod 생성 및 관리

단일 컨테이너 Pod 생성 (sample-pod.yaml)

  
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: nginx-container
      image: nginx

```bash kubectl apply -f sample-pod.yaml

다중 컨테이너 Pod 생성 (sample-2pod.yaml) 하나의 Pod 안에 Nginx와 Redis 컨테이너를 함께 실행

  
apiVersion: v1
kind: Pod
metadata:
  name: sample-2pod
spec:
  containers:
    - name: nginx-container
      image: nginx
    - name: redis-container
      image: redis

컨테이너 접속 및 명령어 실행 -it 옵션으로 가상 터미널을 통해 컨테이너 내부 셸에 접속 가능

  
# sample-pod의 셸에 접속
kubectl exec -it sample-pod -- /bin/sh
  
# 컨테이너를 지정하여 접속 (다중 컨테이너 Pod의 경우)
kubectl exec -it sample-2pod -c nginx-container -- /bin/sh
  
# 외부에서 바로 명령어 실행
kubectl exec -it sample-pod -- /bin/bash -c "ls -all --classify | grep lib"

Pod Spec 상세 설정

command와 args: Dockerfile의 ENTRYPOINT와 CMD를 덮어쓸 때 사용

  
spec:
  containers:
  - name: nginx-container
    image: nginx
    command: ["/bin/sleep"]
    args: ["3600"]

hostNetwork: Pod가 노드의 네트워크를 직접 사용하도록 설정 Pod의 IP가 노드의 IP와 동일해짐 특수한 경우(네트워크 감시 등)에만 사용
dnsPolicy: Pod의 DNS 해석 정책을 설정
- ClusterFirst (기본값): 클러스터 내부 DNS(CoreDNS)를 먼저 사용. 서비스 디스커버리에 필수
- Default: Pod가 실행되는 노드의 DNS 설정을 상속
- None: DNS 설정을 사용하지 않음. dnsConfig로 수동 설정 필요

hostAliases: Pod 내부의 /etc/hosts 파일에 특정 호스트 이름과 IP를 정적으로 등록

  
spec:
  hostAliases:
  - ip: "8.8.8.8"
    hostnames:
    - "google-dns"
    - "google-public-dns"

workingDir: 컨테이너 내부의 작업 디렉토리를 지정

2. ReplicaSet: 파드 복제 및 자동 복구

ReplicaSet은 지정된 수의 동일한 Pod 복제본이 항상 실행되도록 보장하는 컨트롤러 노드 장애 등으로 Pod가 사라지면, 자동으로 새로운 Pod를 생성하여 서비스의 가용성을 유지함

ReplicaSet 생성 (sample-rs.yaml) replicas: 3으로 3개의 동일한 Pod를 유지하도록 설정

  
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sample-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx

레이블과 셀렉터: ReplicaSet은 spec.selector에 정의된 레이블을 가진 Pod들을 감시하고 관리함 spec.template.metadata.labels는 새로 생성될 Pod에 붙여줄 레이블로, 두 값은 반드시 일치해야 함
자동 복구 확인: kubectl delete pod <pod-name> 명령으로 Pod를 수동 삭제하면, ReplicaSet이 즉시 새로운 Pod를 생성하여 replicas 수를 맞추는 것을 확인할 수 있음
스케일링: kubectl scale replicaset sample-rs --replicas=5 명령어로 실행 중인 Pod의 수를 동적으로 조절 가능

3. Deployment: 배포 및 업데이트 관리의 표준

Deployment는 ReplicaSet의 상위 컨트롤러로, Pod의 개수 유지뿐만 아니라 롤링 업데이트, 롤백 등 정교한 배포 전략을 관리함 쿠버네티스에서 상태 없는(Stateless) 애플리케이션을 배포할 때 가장 권장되는 방식임

Deployment 생성 (sample-deployment.yaml) ReplicaSet과 YAML 구조가 매우 유사함

  
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-app
  template:
    metadata:
      labels:
        app: sample-app
    spec:
      containers:
      - name: nginx-container
        image: nginx

롤링 업데이트 (Rolling Update) Deployment는 업데이트 시, 새 버전의 ReplicaSet을 만들고 트래픽을 점진적으로 전환하여 무중단 업데이트를 수행함

  
# 컨테이너 이미지 버전을 1.16으로 업데이트
kubectl set image deployment/sample-deployment nginx-container=nginx:1.16
  
# 업데이트 진행 상태 확인
kubectl rollout status deployment/sample-deployment

롤백 (Rollback) 업데이트에 문제가 있을 경우, 이전 버전으로 쉽게 되돌릴 수 있음

  
# 변경 이력 확인
kubectl rollout history deployment/sample-deployment
  
# 이전 버전으로 롤백
kubectl rollout undo deployment/sample-deployment
  
# 특정 리비전(버전)으로 롤백
kubectl rollout undo deployment/sample-deployment --to-revision=1

변경 일시 중지 (Pause & Resume) 여러 변경 사항을 적용한 후 한 번에 배포하고 싶을 때, 업데이트를 일시적으로 중지할 수 있음

  
# 업데이트 일시 중지
kubectl rollout pause deployment/sample-deployment
  
# (이미지 변경 등 여러 작업 수행)
  
# 일시 중지 해제 및 변경 사항 적용
kubectl rollout resume deployment/sample-deployment

4. ReplicaSet vs Deployment

디플로이먼트(Deployment)가 상위 관리자이고, 레플리카셋(ReplicaSet)은 그 아래에서 단순 반복 작업을 하는 중간 관리자

구분	레플리카셋 (ReplicaSet)	디플로이먼트 (Deployment)
핵심 역할	Pod 개수 유지	Pod 그룹의 배포, 업데이트, 롤백 관리
업데이트 기능	❌ 없음	✅ 무중단 롤링 업데이트
롤백 기능	❌ 없음	✅ 이전 버전으로 롤백
직접 사용 여부	거의 안 함	항상 사용 (권장)
비유	단순 반복 작업을 하는 ‘작업 반장’	전체 프로젝트를 책임지는 ‘총괄 매니저’
관계	디플로이먼트의 하위 구성 요소	레플리카셋을 생성하고 관리하는 상위 컨트롤러

직접 ReplicaSet을 쓰지 않는 이유

만약 우리가 Deployment를 사용하지 않고 ReplicaSet으로만 Pod를 관리한다면, 아래와 같은 핵심 기능들을 모두 수동으로, 위험하게 처리해야 한다

애플리케이션 업데이트: ReplicaSet은 업데이트 기능이 없다 v1 앱을 v2로 바꾸려면, v2용 ReplicaSet을 새로 만들고, 기존 v1 ReplicaSet의 Pod 수를 수동으로 줄이면서 v2 ReplicaSet의 Pod 수를 늘리는 복잡한 과정을 거쳐야 한다 이 과정에서 서비스가 중단될 위험이 매우 커짐
롤백 (Rollback): v2 업데이트에 문제가 생겼을 때, 이전 v1 상태로 돌아가려면 v1 ReplicaSet의 YAML 파일을 다시 적용하는 등의 수동 작업이 필요 Deployment처럼 간단한 명령어 한 번으로 되돌릴 수 없다

오토에버 클라우드 2기

kubernetses cluster

This post is licensed under CC BY 4.0 by the author.