[쿠버네티스 어나더 클래스 - Sprint1] #7. Application 기능으로 이해하기#3 - PV/PVC, Deployment, Service, HPA

[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.

 

 

PV, PVC 기본 개념

컨테이너 내부에서만 데이터를 저장하면 파드(Pod)가 재시작되거나 삭제될 때 내부 파일도 함께 사라집니다. 데이터의 영구적 보존을 위해 스토리지 오브젝트인 PV와 PVC가 필요합니다.

• PV (PersistentVolume): 클러스터 내의 실제 물리/논리 스토리지 자원
• PVC (PersistentVolumeClaim): 사용자가 PV를 할당받기 위해 전달하는 요청서
• 용량 매칭 규칙: PVC의 resource.request.storage 값과 PV의 capacity.storage 값은 동일하게 설정해야 정상 바인딩됩니다.
• nodeAffinity 설정 이유: PV에서 특정 노드를 지정하는 설정입니다. 파드가 데이터가 존재하지 않는 다른 노드에 생성되는 현상을 방지합니다.

 

📌 hostPath : PV, PVC를 거치지 않고 Pod에서 노드의 파일 시스템에 직접 연결하는 Pod 의 volumes.hostPath 속성도 존재합니다. 하지만 HostPath 볼륨에는 많은 보안 위험이 있어, 쿠버네티스 공식 문서에서는, 가능하면 사용하지 않을 것을 권장합니다.

 

 

 

 

 

 

🖥️ 동작 확인

✅ 파일 생성 API 호출

 

 

✅ 경로별 생성 파일 확인

• Pod 내 비마운트 경로: /usr/src/myapp/tmp (파드 삭제 시 소멸)
• Pod 내 VolumeMount 경로: /usr/src/myapp/files/dev
• PV Volume 저장 경로: /root/k8s-local-volume/1231 (실제 노드 경로)

 

 

✅ Pod 삭제 후 PV Volume 확인

 

 

 

 

 

Deployment 기본 개념 (배포 및 업데이트 전략)

 

Deployment는 Pod의 생성 및 업데이트를 관리합니다. Deploy의 spec.template 하위 설정이 하나라도 변경되면 자동으로 업데이트 프로세스가 수행됩니다.

• Deployment Update 시 ReplicaSet 관리

1. 새로운 이름의 replicaset 을 만듦
2. 새(api-tester-1231-2xxxx) replicas : 2로 설정, 기존(api-tester-1231-1xxxx) replicas : 0 으로 설정
3. 그럼 이전 pod 들은 삭제가 되는데, 기존 replicaset 은 그대로 있음 → 새버전의 문제가 생겨 롤백을 해야할 경우 사용

Recreate / RollingUpdate 두가지 방식에 따라 업데이트가 진행되는 과정이 다릅니다

배포 방식	동작 방식	장점	단점
Recreate	기존 파드를 모두 일시 삭제한 후, 새 파드들을 동시에 생성	자원 중복 사용 없음	새 파드 기동 완료까지 서비스 중단(Downtime) 발생
RollingUpdate	새 파드를 1개 생성하여 기동 완료되면 기존 파드 1개를 순차 삭제 반복	무중단 배포 가능	배포 중 순간 자원 사용량 증가(최대 150%), 두 버전 혼재 호출 발생

• 두 버전 혼재 이슈 대안: RollingUpdate 중 신·구 버전 API가 동시 호출되는 현상이 문제가 된다면 Blue/Green 배포 방식을 채택합니다.
• RollingUpdate 제어 속성:
  • maxUnavailable: 업데이트 과정 중 최대 몇 개의 파드가 서비스 불능 상태가 되는 것을 허용할지 결정
  • maxSurge: 설정된 replicas 수 대비 최대 몇 개의 파드를 추가로 더 만들 수 있는지 결정

 

 

 

 

 

 

Service 기본 개념

Service는 spec.selector 조건과 Pod의 metadata.labels를 매칭하여 트래픽을 파드로 전달합니다. type: NodePort 사용 시 외부 트래픽을 쿠버네티스 내부 Pod로 포워딩할 수 있습니다.

• 주요 핵심 역할 3가지:
  • 서비스 퍼블리싱: 외부 트래픽을 내부 Pod로 라우팅
  • 서비스 디스커버리: IP가 가변적인 Pod 대신 고정된 Service 이름(내부 DNS)으로 API 호출
  • 서비스 레지스트리: 동적으로 변하는 Pod IP를 추적·관리하고 로드밸런싱 수행

 

 

 

 

 

포트 추상화 기법 (Port Name 매칭)

애플리케이션 포트가 변경될 때마다 Service의 targetPort를 매번 수정하는 번거로움을 줄이기 위해 포트 이름(Name) 매칭 방식을 사용합니다.

 

# Pod (Deployment) 측 설정
containers:
  - ports:
      - name: http           # 포트 이름을 'http'로 명시
        containerPort: 8080  # App 포트가 변경되면 이 숫만 변경

# Service 측 설정
ports:
  - port: 80
    targetPort: http         # 숫자가 아닌 포트 이름 'http'를 타겟팅

 

 

 

 

 

HPA 기본 개념

HPA는 부하량에 따라 파드 개수를 유연하게 늘리거나 줄입니다.

• 기준값의 중요성: Pod에 설정된 resource.requests 값은 HPA가 100% 임계치를 계산하는 절대적인 기준점이 됩니다.
• 스케일아웃 계산 예시 (목표 평균 CPU Utilization: 60%):
• Limits의 영향: resource.limits 설정 역시 애플리케이션의 최대 임계 한계치를 결정짓는 데 큰 영향을 미칩니다.
• behavior 속성: 잦은 스케일인/아웃(Thrashing) 현상을 방지하기 위해 대기 시간(stabilizationWindowSeconds)이나 변동 비율을 제어합니다.