Pod 안전하게 생성/배포 및 QoS 정책 설정

📍 Epilogue

---

• 간단한 JAR 애플리케이션을 가지고 쿠버네티스 파드 배포를 시도하였다 !
• 그런데 파드 상태가.. 엄청난 메모리 부족..
  • OOM Killed.. CrashLoopBackOff 상태 반복..
• 파드 스펙 늘리고 다시 배포하니 정상 상태 !
• 그래서 여기서 의문점 ❗️
  • 컨테이너 자원 스펙을 정할 때 어떤 기준/전략 또는 옵션이 있을까?
  • 또는 Stable한 배포 전략이 있을까?

 

▪︎ Plan

---

1. 파드에 적절한 자원 할당을 통해 안정된 서비스 품질(QoS) 구성하기
2. Probe 기능을 통해 안정적인 Pod Life-Cycle 보장하기

 

▪︎ 서비스 품질 (QoS)

---

• 파드에 특정한 서비스 품질(QoS) 클래스를 할당해 줄 수 있다.
  • Guaranteed
  • Burstable
  • BestEffort
• 파드의 QoS 클래스를 통해 쿠버네티스는 파드 스케줄링과 축출을 결정한다.

 

▪︎ Guaranteed QoS 클래스

---

• Guaranteed QoS 클래스 할당을 위한 조건
  • 파드 내 모든 컨테이너는 [메모리 상한 & 요청량] & [CPU 상한 & 요청량]을 가지고 있어야 한다.
  • 파드 내 모든 컨테이너는 [메모리 (상한 = 요청량)] & [CPU (상한 = 요청량)] 이어야 한다.

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
    resources:
      limits:
        cpu: 500m
        memory: 512Mi
      requests:
        cpu: 500m
        memory: 512Mi

 

• 위 작성한 매니페스트로 pod 생성 !

 

• QoS Class가 Guaranteed로 할당된 것을 확인 !

 

💡 만약 컨테이너의 스펙에 메모리 또는 CPU의 상한성(limits)만 지정하였을 경우
     → 해당 지정한 메모리나 CPU의 상한성(limits)과 동일하게 요청량(requests)을 자동으로 할당해준다.

 

 

▪︎ Burstable QoS 클래스

---

• Burstable QoS 클래스 할당을 위한 조건
  • 파드가 Guaranteed QoS 클래스 조건을 만족하지 않는 경우
  • 파드 내 최소 하나의 컨테이너가 [메모리 상한 & 요청량] 또는 [CPU 상한 & 요청량]을 가지고 있는 경우

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action
    resources:
      limits:
        cpu: 500m
      requests:
        cpu: 300m

 

• 위 작성한 매니페스트 파일로 pod 생성 후 Qos Class가 Burstable로 할당된 것을 확인 !

 

 

▪︎ BestEffort QoS 클래스

---

• BestEffort QoS 클래스 할당을 위한 조건
  • 파드 내 컨테이너에 [메모리 상한 & 요청량] 또는 [CPU 상한 & 요청량]이 없는 경우

apiVersion: v1
kind: Pod
metadata:
  name: cn-app-pod
  labels:
    name: cn-app-pod
spec:
  containers:
  - name: cn-app
    image: uh2959/cn-action

 

• 위 작성한 매니페스트 파일로 pod 생성 후 Qos Class가 BestEffort로 할당된 것을 확인 !

 

 

 

▪︎ Probe

---

• 만약 파드가 완벽하게 배포가 되지 않은 상태에서 트래픽 요청이 들어간 상황인 경우 ?
  • 파드가 현재 요청을 받을 수 있는 상태인지 확인이 필요하다 !
  • 파드의 상태를 파악하기 위해 프로브(Probe)를 사용한다.
• 프로브란 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다.
  • 진단 : 컨테이너 안에서 코드 수행 / 네트워크 요청 전송
• 프로브는 총 세 가지 종류가 존재한다.
  • livenessProbe
  • readinessProbe
  • startupProbe

 

 

▪︎ livenessProbe

---

• 활성 프로브
• 컨테이너가 동작 중인지 여부 확인
• 만약 Failure시, kubelet은 컨테이너를 죽이고 해당 컨테이너는 재시작
• livenessProbe 미설정 시, 기본 상태는 Success

 

▪︎ readinessProbe

---

• 준비성 프로브
• 컨테이너가 요청을 처리할 준비가 되었는지 여부 확인
• 만약 Failure, Endpoint Controller은 파드에 연결된 모든 서비스들의 엔드포인트에서 파드 IP 주소 제거
• ⇒ 트래픽 전달하지 않음
• readinessProbe 초기 지연 이전 기본 상태는 Failure
• readinessProbe 미설정 시, 기본 상태는 Success

 

▪︎ startupProbe

---

• 스타트업 프로브
• 컨테이너 내의 애플리케이션이 시작되었는지 여부 확인
• startupProbe가 success 될 때 까지 다른 나머지 프로브는 활성 X
• 만약 Failure시, kubelet은 컨테이너를 죽이고 해당 컨테이너는 재시작
• startupProbe 미설정 시, 기본 상태는 Success

 

 

 

 

Ref.

---

파드에 대한 서비스 품질(QoS) 구성

파드 라이프사이클

K8S 환경에서 pod을 안전하게 배포하는 방법