[쿠버네티스] PV/PVC, Deployment, Service, HPA - (TS러버)

[쿠버네티스] PV/PVC, Deployment, Service, HPA - (TS러버)

rhkdtjd_12 14일 전

해당 블로그는 [쿠버네티스 어나더 클래스] 강의에 일부 내용입니다. 복습을 위한 자료 입니다.

1. PV & PVC

쿠버네티스는 애플리케이션의 스토리지 요청과 바인딩을 분리하여 유연하고 안전한 방식으로 디스크를 관리할 수 있도록 PersistentVolume(PV)과 PersistentVolumeClaim(PVC)을 제공합니다.

이 구조는 "스토리지 요청(PVC)"과 "스토리지 제공(PV)"의 역할 분리를 가능하게 합니다.

PV / PVC 기본 개념

  • PVC (PersistentVolumeClaim): 사용자의 스토리지 요청. "내가 5Gi 저장소가 필요해요."

  • PV (PersistentVolume): 실제로 디스크를 제공하는 리소스

PVC는 label-selector 등을 통해 PV와 자동 바인딩됩니다.

Local, hostPath 기반의 로컬 저장소 사용

  • local / hostPath 방식은 특정 노드의 로컬 디스크를 직접 사용하는 방식입니다.

  • 실제 저장은 노드의 /data 같은 디렉토리에 이루어지며, Pod에서 마운트된 디렉토리를 통해 접근합니다.

volumes:
  - name: local-volume
    hostPath:
      path: /data/my-app
      type: Directory

주의사항 (로컬 디스크 방식)

  • 특정 노드에 종속됨 → 노드 장애 = 데이터 손실 위험

  • hostPath는 보안 취약점 발생 우려가 있어 최소 권한 설정 필요

  • 운영 환경에는 부적합, 테스트나 임시 데이터에만 권장

 

✅ 운영환경에서는 NAS / EFS / Longhorn / Rook 등 스토리지 솔루션 사용

  • NAS, NFS, EFS: 중앙화된 스토리지. 노드 장애에도 데이터 유지

  • Longhorn, Rook: 쿠버네티스에서 자동 복구 및 분산 저장 지원

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-longhorn-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 5Gi

위와 같이 PVC만 작성하면 Longhorn이 알아서 StorageClass → PV → 실제 디스크까지 자동으로 구성해줍니다.

 

2. Deployment

Deployment는 애플리케이션의 선언형 배포, 무중단 업데이트, 자동 롤백 등을 가능하게 해주는 핵심 리소스입니다.

Pod 템플릿 감지 → 자동 업데이트

  • Deployment는 내부에 template.spec이 포함되어 있으며, 이미지 버전 등 사소한 변경도 감지하여 업데이트 실행

  • 변경 감지 시 새로운 ReplicaSet을 생성하고 기존 Pod를 교체합니다.

containers:
  - name: app
    image: my-app:v2  # ← 변경 감지

 

업데이트 전략 (strategy)

Recreate : 기존 Pod 모두 종료 후 새로 배포

RollingUpdate : (기본값) 점진적 교체, 서비스 무중단 유지

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

  • maxUnavailable: 동시에 중단 가능한 최대 Pod 수

  • maxSurge: 업데이트 중 추가 생성 가능한 Pod 수

3. Service

Service는 Pod의 위치(IP) 와 네트워크 경로(URL) 를 분리시켜주는 쿠버네티스의 로드밸런싱 리소스입니다.

주요 역할

  1. Publishing : Cluster 외부에서 트래픽 연결 (NodePort, LoadBalancer)

  2. Discovery : 내부 DNS를 통해 고정 주소로 호출 가능

  3. Load Balancing : label-selector로 연결된 Pod들 간 트래픽 분산

포트 유연성 - targetPort 이름 지정 방식

containers:
  - name: app
    ports:
      - name: http
        containerPort: 8080
---
spec:
  ports:
    - port: 80
      targetPort: http  # ← 포트 이름으로 지정

나중에 containerPort가 바뀌더라도 Service는 동일하게 동작!

 

4. HPA

HPA는 CPU/메모리 부하 또는 외부 지표에 따라 Pod 수를 자동으로 증감시켜주는 오토스케일링 리소스입니다.

 

기본 설정 방식

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60

  • CPU가 평균 60% 초과 시 Pod 수 증가

  • Pod 수 = 현재 수 × (실제 / 목표)

고급 스케일링 전략

  1. 예측 기반 수동 조정: 크론 스케줄러로 미리 replica 수를 늘려두기

  2. Queue 기반 아키텍처: Kafka, Redis 등의 큐를 활용한 비동기 처리

  3. 외부 지표 기반:

    • Prometheus / Redis / Kafka Lag

    • KEDA, Custom Metrics API 등 연동 가능

HPA는 후행성(reactive)이므로 갑작스런 트래픽엔 늦을 수 있음 → 선제적 대응 전략 병행 필요

정리

  • PV/PVC: 선언형 저장소 관리, 역할 분리 구조

  • Deployment: 선언형 배포 및 자동 롤백

  • Service: 고정된 통신 경로와 로드밸런싱

  • HPA: 자동 스케일링, 고급 지표 연동 가능

위 기능들은 클라우드 네이티브 환경에서 안정적이고 유연한 인프라 운영을 가능하게 하는 핵심 구성요소입니다.

 

댓글을 작성해보세요.

채널톡 아이콘