해당 포스팅은 인프런강의 [쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2] 를 기반으로 작성했습니다.
PV/PVC
hostPath 방식 (PV/PVC 없이 바로 사용)
- 파드에서 직접 노드의 로컬 디렉토리 사용
→ /root/k8s-local-volume/1231 같은 경로 - hostPath로 연결하면 간단하지만 단점도 많음
장점
- 빠르고 간단함 (테스트에 적합)
- 별도 PVC, PV 없이 바로 연결 가능
단점
- 노드가 죽으면 데이터도 사라짐
- 노드 종속성 있음 (NodeAffinity 필수)
- 운영 환경에서 사용하지않음 (내구성, 이식성 부족)
PVC + PV 방식 (정석적이고 안전한 방식)
- 개발자는 PVC를 생성해서 원하는 용량만 요청
- 인프라 담당자는 PV를 미리 준비하거나 자동 생성 설정
- Kubernetes가 PVC와 PV를 자동으로 연결(binding)
✅ 장점
- Pod가 죽어도 데이터 유지 가능
- 다양한 스토리지 백엔드(NFS, EBS, Ceph 등)와 연동 가능
- 운영환경에 적합
❌ 단점
- 설정이 약간 복잡
- PV와 PVC의 selector, labels, accessModes 등을 잘 맞춰야 함
Deployment
업데이트 방식 : template 변경시에 무조건 변경됨.
새로운 ReplicaSet 생성뒤에 기존 Replica를 롤백하기위한 상황을 위해 남겨진다.
Recreate : 기존 파드를 모두 삭제시키고 파드 2개를 만듬.
RollingUpdagte : 한개씩 삭제시키고 생성함.
여러 앱들을 동시에 업그레이드 될때? -> Blue/Green은 사용량이 증가해서 위험함.
Service
서비스 퍼블리싱
1. 사용자가 외부에서 Pod로 트래픽 연결
2. Nodeport 로 입력받음 http://192.168.56.30:31231/version
3. Service에있는 tagtetPort로 Container에 연결 (포트포워딩)
2. 서비스 디스커버리
내부 DNS를 이용하여 Service이름으로 API 호출 기능
HPA
이상적인 스케일링
처음 파드 부하 -> scale out -> 기동완료 -> scale in -> 파드 삭제
현실적인 스케일링
급격한 CPU부하 -> 파드 down -> Scaleout -> 셀프힐링으로 Restart (서비스 중단)
트래픽이 많을때는 대기열을 걸어놓는게 안전하다.
behavior : 잦은 스케일링 방지 목적
-> 피크칠때 를 대비해서 2분동안 60% 유지시 Scale- out