[1-7] Application 기능으로 이해하기 - PV/PVC, Deployment, Service, HPA

📙PVC, PV

PVC, PV 연결법
(resource, accessModes) (capacity, accessModes) 이 둘의 값이 같아야 selector랑 labels 연결됨

 

1. local 사용

local : 노드의 path

nodeAffinity : 어느 노드에 파드를 생성할 것인지 정함

 

• 테스트 환경에서 별도의 스토리지를 구축하기가 번거롭기에 k8s 노드 중 한곳을 임시 스토리지로 정하고 path를 생성
• path를 통해 k8s가 연결
• 파드가 다른 노드에 생성되는 것을 막기위해 nodeAffinity 속성 필요
• 파드가 죽을때 내부 저장된 파일이 같이 삭제 -> 따라서 저장할 공간 필요

 

2. hostpath 사용

• 파드에 hostpath와 nodeSelector를 통해 노드 지정 가능
• 테스트 환경에서 임시 저장용으로 가능, BUT 운영 환경에허는 저장 용도로 절대 안됨!!!(노드 디스크 공간 부족)

• 원래 저장 용도가 아니라 노드에 있는 정보를 앱에 조회하는 용도
• 여기에 필요한 파일 또는 디렉토리 범위만 정하고 read-only로 마운팅

EX) 로그를 볼 수 있었던 이유
그라파나에서 로키를 통해 모든 앱의 로그
실제 파드들의 로그는 노드의 /var/log/pods로 저장이 되어 있음
로키의 promtail이라는 파드가 hostpath로 /var/log/pods 경로를 조회
따라서 모든 파드의 로그들을 로키를 통해 볼 수 있었음

 

PVC, PV가 꼭 필요한가요?
파드를 만드는 주체는 개발자
볼륨 솔루션에는 여러 가지가 있고 각각의 기능에 따라서 사용해야 되는 속성도 달라지가 때문에
개발까지 이 부분까지 신경 쓰는 건 좀 아니다..
그래서 인프라 담당자가 PV 관리
파드에서 필요한 자원을 요청하는 용도로 개발자가 PVC 관리

 

 

---

 

 

📘Deployment, ReplicaSet

template : 하위 항목이 하나라도 변경이 되면 업데이트가 진행

strategy : 파드 새로 배포할때 사용, 방식으로 두가지 존재

 

ReplicaSet

• replicas : 이 숫자에 따라 생성되는 파드 개수가 달라짐
• 업데이트 되면서 이전 파드들은 삭제가 되지만 레플리카셋은 롤백을 위해 삭제되지 않음

 

Recreate 방식

• 기존 파드들을 전부 삭제 시키는 동시에 새 파드 생성
• 기동 시간만큼 서비스가 중단됨

 

RollingUpdate 방식

• 새 버전의 파드를 하나 만들기 시작하고 완료되지마자 기존 파드 하나 삭제
• 서비스 중단이 없음, BUT 업데이트 중 자원 사용량 150% 증가
• 또한 두 버전이 동시에 호출

maxUnavailable : 업데이트 동안 서비스 불가 파드 비율(얼마만큼 기존의 파드를 중단시켜도 되는지)

maxSurge : 새로운 파드를 최대 몇개까지 동시에 만들지를 정하는 것(100%는 replicas 수)

 

Blue/Green 방식

• 업데이트 동안 두 버전이 동시에 호출되지 않음
• 자원 사용량 200% 증가
• 별도 배포 솔루션에서 제공

 

 

---

 

 

📕Service

• 서비스의 selector와 파드의 labels로 연결

 

type

• Default : ClusterIP -> k8s 내부의 파드에서만 접근하는 용도로 서비스를 만들 때 사용
• type을 NodePort로 설정하면 노드에 포트가 만들어지고 외부 트래픽을 파드로 전달할 수 있게 됨

 

ports

• targetPort는 컨테이너 포트를 가리킴
• nodePort에 넣은 값으로 외부 포트가 만들어짐
• port는 필수 속성

 

서비스의 주요 기능 4가지

1. 서비스 퍼블리싱 : 외부에서 파드로 트래픽 연결

2. 서비스 디스커버리 : k8s가 내부 DNS를 이용해서 서비스의 이름을 API로 호출을 할 수 있게 해주는 기능 

***파드의 경우 삭제시 IP가 변경되기 때분에 항상 서비스를 통해서 호출해야함***

 

앱의 포트가 변경되었을 때
서비스의 targetPort도 변경되어야 한다...
이럴 때, 파드에 ports의 name(포트의 성격), ports의 containerPort(앱이 노출되고 있는 포트)를 부여
-> 흔히 하는 오해 : 파드에 이 속성들을 줘야 앱이 트래픽을 받는 것은 아님(정보성인 속성)
서비스의 targetPort에 포트번호 대신 파드의 name 값을 넣으면 매핑된 포트를 찾아서 API를 날림
***따라서 파드의 포트 변경시 서비스 수정 불필요***

 

3. 서비스 레지스트리 : 파드가 삭제되고 생성되는 과정에서 IP를 제거하고 등록해주는 기능

4. 로드 밸런싱 : 여러 파드로 들어오는 트래픽을 분배해주는 기능

 

 

 

---

 

 

 

📗HPA

scaleTargetRef

• deployment를 지정하는 내용

 

minReplicas, maxReplicas

• 범위 내에서 파드 개수 변경

 

metrics

• averageUtilization으로 몇퍼센트로 스케일링이 되는지 설정

 

behavior

• 통해 잦은 스케일링 방지
• 복잡한 로직이 있으면 CPU가 순간적으로 크게 올라가기 쉬움
• 이때마다 스케일 아웃 되면 CPU가 비효율적으로 사용됨
• ex) 2분 이상 부하 유지시 스케일아웃, 부하 감소해도 10분동안 유지, 파드 5개가 삭제되어야 해도 1분에 1개씩 제거

 

Pod의 resource

• limits 속성으로 한계를 정하고, 이는 HPA의 평균 임계치를 결정하는데 큰 영향을 줌

Memory는?
사용량이 늘어나면서 앱 내부에서 가비지 컬렉션이 일어나고 memory 수치를 낮춤
memory 공간은 사용 상황에 따라 변하는 값이지 부하에 따른 증감대상이 아님
**그래서 HPA에서 쓸 일 없음**

 

• 그래서 기본 기능으로 CPU밖에 쓸 게 없는데 CPU만 가지고 모든 앱의 부하 상태를 판단하기 어려움
• 내부에 쌓여있는 Queue나 Request량, DB연결 개수, Thread 수 같이 판단 기준이 다름
• 다양한 부하를 얻을 수 있는 솔루션 필요..

 

CPU 스케일링

• 예상하지 못한 트래픽에는 대처하기 힘들다..
• ***자동화 스케일링은 보조적인 역할일 뿐 부하 걱정은 항상 해야함***
• 서비스 피크 시간 분석을 통해 미리 자원을 늘려놓거나 대기열 아키텍처를 구성해야함

 

 

---

 

 

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로