PV, PVC

✅ PV / PVC 한줄 요약

PV(PersistentVolume): 관리자가 제공한 실제 저장 공간
PVC(PersistentVolumeClaim): 사용자가 요청한 저장 공간 요구사항

🔄 관계 흐름

[관리자][개발자]
↓ ↓
PersistentVolume ← PersistentVolumeClaim
(공급자) (소비자)

관리자는 PV를 미리 생성하거나 스토리지 클래스를 등록
개발자는 PVC로 스토리지를 요청함
Kubernetes가 둘을 자동으로 바인딩시킴

Deployment

[strategy]

[template]
spec, containers, metadata, labels 하나라도 변경되면 업데이트 됨

Recreate vs RollingUpdate

Recreate

기존의 모든 Pod을 먼저 종료한 후, 새 버전의 Pod을 한꺼번에 다시 생성하는 방식.

RollingUpdate

예시) maxUnavailable : 25% , maxSurge : 25%

• maxUnavailable : 배포 중에 동시에 "비어 있어도 되는 Pod 수"를 제어
• maxSurge : 새 Pod를 최대 몇 개까지 동시에 만들지 정하기

총 4개의 기존 Pod (파란색) 이 실행 중.
새 버전을 배포하려고 할 때:
새 버전 Pod 1개를 추가 생성 (green) → maxSurge: 1
이 시점에서 Pod 수는 5개
새 Pod가 Ready 되면, 기존 Pod 중 하나를 종료함 → maxUnavailable: 1
다음 2번째 Pod 교체를 위해 다시 새 버전 Pod 1개 생성
‼️ 여기서 바로 이 교체 타이밍 사이의 순간을 캡처한 것이 지금 이미지.

✅ 새로 뜬 녹색 Pod A는 이미 Ready 상태
✅ 기존 Pod 중 하나는 꺼질 예정 (아직 종료 전)
✅ 다음 새 녹색 Pod B가 이미 생성 준비 중

Service

Servicer(selector)가 Pod(labels)를 연결
Service의 type이 NodePort
NodePort에서 외부에서 보낸 트래픽을 쿠버네티스 내부에 Pod로 전달

Service의 nodeport로 외부 포트에서 container의 port로 연결
Service의 port는
서비스 디스커버리로 DNS:port로 내부적으로 targetPort로 포워딩되어서 pod로 전달

Pod의 ip는 항상 변경

Pod 내부의 Container의 port가 변경이 되면
(자연스럽게) Service의 targetPort도 변경이 되어야 함
그런데 Container의 port가 바뀌더라도 Service를 신경쓰지 않아도 되는 방법이 있음.
"containers의 ports"를 사용하면 됨.
Service에서 targetPort의 이름이 Pod에서 매핑된 포트를 찾아서
그 port로 API를 날림

서비스 레지스트리와 로드 밸런싱

서비스 레지스트리란, 실행 중인 Pod들의 IP 목록을 실시간으로 관리하고,
이를 Service 오브젝트가 로드밸런싱에 사용할 수 있도록 알려주는 내부 저장소 또는 메커니즘

1.Recreate 전략으로 Pod 종료 → 새 Pod 생성
왼쪽의 회색 Pod들은 종료됨 (X)
새 버전의 Pod들이 파란색으로 생성됨
2.종료된 Pod IP → 서비스 레지스트리에서 제거
Service는 더 이상 종료된 Pod의 IP로 트래픽을 보내지 않음
3.새로 생성된 Pod IP → 서비스 레지스트리에 등록
새 Pod가 Ready 상태가 되면 자동으로 Service에 연결됨
4.Service → 트래픽을 등록된 Pod로 분산
현재 실행 중인 Pod IP만 가지고 로드밸런

로드 밸런싱은 여러 서버(또는 Pod) 중에서 트래픽을 고르게 분산시켜주는 기술