kubernetes QoS Class

파드에 Requests/Limits 설정에 따라 자동으로 QoS Class 값이 설정되게 되어 있습니다. 

 

QoS Class란 kubernetes가 컨테이너에 oom score를 설정할때 사용됩니다. oom score는 OOM Killer에 의해 프로세스를 정지시킬 때 우선순위 값으로 -1,000(최고 순위) ~ 1,000(최저순위) 범위에서 설정합니다.

 

따라서, kubernetes의 리소스가 부족할 때 즉, 노드에 리소스가 부족할때 QoS에 따라 어떤 파드의 컨테이너를 kill 할지 결정합니다.

 

 

□ BestEffort

pod의 어떤 container내에도 Request와 Limit이 미설정 되어있는 경우입니다. 이럴경우 limit을 설정하지 않았기 때문에 노드에 유후 자원이 존재한다면 제한 없이 모든 자원을 사용할 수 있습니다. 또한, request를 설정하지 않았기때문에 보장받을 수 있는 자원이 존재하지 않습니다.

즉, 노드에 존재하는 모든 자원을 사용할 수 있지만, 노드에 자원이 없다면 전혀 사용할 수 없습니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: h-devops
  labels:
    app: h-devops
spec:
  selector:
    matchLabels:
      app: h-devops
  template:
    metadata:
      labels:
        app: h-devops
      containers:
      - name: h-devops
        image: h-devops:1111

□ Burstable

아래 yaml 파일처럼 resources 항목에서 requests보다 limits가 큰 경우입니다. 아니면 limits 과 requests가 일지 하지 않는 경우

requests의 지정된 만큼 리소스를 보장받을 수 있지만, 상황에 따라서는 limit까지 사용 가능한 pod들이 해당 속성에 속합니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: h-devops
  labels:
    app: h-devops
spec:
  selector:
    matchLabels:
      app: h-devops
  template:
    metadata:
      labels:
        app: h-devops
      containers:
      - name: h-devops
        image: h-devops:1111
        resources:
          requests:
            cpu: 400m
            memory: 7000Mi
          limits:
            cpu: 500m
            memory: 1000Mi

 

□ Guaranteed

아래 yaml 파일처럼 resources 항목에서 limits과 requests의 값이 완전 동일한 경우 해당 속성으로 분류됩니다.

따라서 자원의 오버커밋이 허용되지 않기때문에 자원 사용을 안정적으로 보장받을 수 있습니다. 또한 kubernetes 스케줄러가 가용 자원이 확실한 곳에 배치 시켜줍니다.

위에서 우선순위가 제일높은게 -1,000 이라고 설명했는데 해당 속성은 oom score 값이 -998 즉 가장 높다고 할 수 있습니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: h-devops
  labels:
    app: h-devops
spec:
  selector:
    matchLabels:
      app: h-devops
  template:
    metadata:
      labels:
        app: h-devops
      containers:
      - name: h-devops
        image: h-devops:1111
        resources:
          requests:
            cpu: 500m
            memory: 1000Mi
          limits:
            cpu: 500m
            memory: 1000Mi

 

□ QoS 우선순위

일반적으로 노드에 메모리 자원이 부족해지면 우선순위가 가장 낮은 pod나 프로세스가 먼저 종료됩니다.

그리고 pod의 우선순위에는 QoS 클래스 및 메모리 사용량에 따라 정렬되어 판단하게 됩니다.

 

우선순위 순서는 아래와 같습니다.

Guaranteed > Burstable > BestEffort 순입니다. (하지만 Burstable, BestEffort 간에는 메모리의 사용량에 따라 우선순위가 바뀔 수 있습니다.)

 

개인적인 생각이지만 어플리케이션 마다 QoS 클래스를 다르게 골고루 분배하는것이 좋겠지만, BestEffort 클래스는 requests, limits 값이 아예 없기때문에 거의 사용하지 않는것이 좋다고 생각합니다. 트래픽을 많이 받지 않는다고 해당 클래스를 사용하게 되더라도 혹시 모를 상황에 트래픽을 많이 받게 된다면 노드에 자원을 무한대로 쓸수있게 되고 그것은 곧 장애로 이어지게 될 것 같습니다.

 

그렇다고 kubernetes 스케줄러가 가용자원이 확실한 곳에 배치해주고 안정적으로 보장받을 수 있는 Guaranteed 클래스를 모두 사용하면 그만큼 자원을 많이 사용하게 되므로 어플리케이션에 상황에 맞게 적절하게 분배하면 좋을 것 같습니다.

 

하지만 유명하신 aws solutions architect 분이 Guaranteed를 추천한다고하여.. 회사에선 해당 QoS(Guaranteed)를 조금 많이 쓰고있..습니다.