쿠버네티스 QoS 클래스, 어떤 파드의 우선순위를 높여야 할까? 🚀

쿠버네티스 클러스터를 운영하다 보면 예기치 않게 중요한 애플리케이션 파드가 종료되는 경험을 할 수 있습니다. 이는 주로 노드의 리소스(메모리, CPU)가 부족해질 때 쿠버네티스가 스스로 안정성을 유지하기 위해 일부 파드를 '축출(Evict)'하기 때문에 발생합니다. 이때 어떤 파드를 먼저 종료시킬지 결정하는 중요한 기준이 바로 QoS(Quality of Service) 클래스입니다.

QoS 클래스는 파드의 우선순위를 결정하는 핵심적인 메커니즘입니다. 단순히 "이 파드는 중요해!"라고 설정하는 것이 아니라, 파드가 요청하고 제한하는 리소스 양에 따라 세 가지 등급으로 자동 분류됩니다. 이 등급에 따라 리소스 부족 상황에서 살아남을 파드와 먼저 사라질 파드가 결정됩니다.

이번 블로그 포스트에서는 각 QoS 클래스가 무엇인지 알아보고, 어떤 애플리케이션 파드를 가장 높은 우선순위로 설정해야 하는지 상세하게 설명하겠습니다.

https://k21academy.com/docker-kubernetes/quality-of-service-qos-in-kubernetes-ensuring-reliable-application-performance/

 

---

쿠버네티스 QoS 클래스란?

쿠버네티스는 파드가 사용하는 리소스를 관리하기 위해 requests와 limits를 설정할 수 있습니다.

• spec.containers[].resources.requests: 파드가 스케줄링될 때 최소한 보장받아야 하는 리소스 양입니다.
• spec.containers[].resources.limits: 파드가 최대로 사용할 수 있는 리소스 양입니다.

이 두 값의 설정 방식에 따라 쿠버네티스는 파드를 다음 세 가지 QoS 클래스 중 하나로 분류합니다.

1. Guaranteed (가장 높은 우선순위)
   • 조건: 파드의 모든 컨테이너가 메모리와 CPU 모두에 대해 requests와 limits를 설정해야 하며, 그 값이 완전히 동일해야 합니다.
   • 특징: 가장 높은 우선순위를 가집니다. 노드 리소스가 부족할 때 가장 마지막에 축출 후보가 됩니다. 예측 가능한 성능이 보장되어야 하는 중요한 워크로드에 적합합니다.
2. Burstable (중간 우선순위)
   • 조건: 파드의 컨테이너 중 하나 이상이 requests와 limits를 가지고 있지만, Guaranteed 조건을 충족하지 않는 경우입니다. 예를 들어, requests가 limits보다 작거나, 일부 컨테이너에만 리소스가 설정된 경우입니다.
   • 특징: 중간 우선순위를 가집니다. BestEffort 파드보다는 늦게, Guaranteed 파드보다는 먼저 축출됩니다. 평소에는 requests만큼의 리소스를 보장받다가, 필요시 limits까지 리소스를 더 사용할 수 있어 유연성이 높습니다.
3. BestEffort (가장 낮은 우선순위)
   • 조건: 파드의 어떤 컨테이너에도 requests와 limits가 전혀 설정되지 않은 경우입니다.
   • 특징: 가장 낮은 우선순위를 가집니다. 노드 리소스가 부족해지면 가장 먼저 축출 대상이 됩니다. 중요하지 않은 개발용, 테스트용 파드나 배치(batch) 작업에 사용할 수 있습니다.

결론적으로, 파드의 우선순위를 높인다는 것은 해당 파드가 Guaranteed QoS 클래스를 갖도록 설정하는 것을 의미합니다.

---

어떤 파드의 우선순위를 높여야 할까? (Guaranteed 클래스 추천 대상)

모든 파드를 Guaranteed로 만드는 것은 비효율적이며 리소스 낭비를 초래할 수 있습니다. 클러스터의 안정성과 서비스 연속성을 위해 선택과 집중이 필요합니다. 다음은 Guaranteed 클래스로 설정하여 우선순위를 높여야 하는 핵심적인 파드들입니다.

🛡️ 1. 상태 저장(Stateful) 애플리케이션

상태 저장 애플리케이션은 재시작 시 데이터 유실의 위험이 있거나 내부 상태를 유지해야 하므로 안정적인 운영이 매우 중요합니다. 갑작스러운 축출은 데이터 정합성 문제나 서비스 장애로 직결될 수 있습니다.

• 데이터베이스: MySQL, PostgreSQL, MongoDB, Redis (캐시가 아닌 주 저장소로 사용 시) 등
  • 이유: 데이터베이스 파드가 갑자기 종료되면 진행 중이던 트랜잭션이 유실되거나 데이터 파일이 손상될 수 있습니다. 복구에 많은 시간이 소요되며, 이는 전체 서비스의 장애로 이어집니다.
• 메시지 큐: Kafka, RabbitMQ, ActiveMQ 등
  • 이유: 메시지 큐는 시스템 간의 비동기 통신을 책임지는 핵심 요소입니다. 큐 파드가 종료되면 처리 중이던 메시지가 유실되어 시스템 전체의 데이터 흐름에 심각한 문제를 일으킬 수 있습니다.
• 검색 엔진 클러스터: Elasticsearch, OpenSearch 등
  • 이유: 검색 클러스터의 데이터 노드가 예기치 않게 종료되면 샤드(shard) 재할당이 발생하며 클러스터 전체에 큰 부하를 줍니다. 이는 검색 성능 저하 및 안정성 문제를 야기합니다.

# 예시: PostgreSQL 파드를 Guaranteed 클래스로 설정
apiVersion: v1
kind: Pod
metadata:
  name: postgres-guaranteed
spec:
  containers:
  - name: postgres
    image: postgres:14
    resources:
      requests:
        memory: "1Gi"
        cpu: "1"
      limits:
        memory: "1Gi" # requests와 동일하게 설정
        cpu: "1"    # requests와 동일하게 설정
    env:
      - name: POSTGRES_PASSWORD
        value: "mysecretpassword"

✅ 2. 핵심 비즈니스 로직을 처리하는 무상태(Stateless) API 서버

서비스의 가장 중요한 기능을 담당하는 API 서버는 항상 안정적으로 실행되어야 합니다. 비록 재시작이 용이한 무상태(Stateless) 애플리케이션이라 할지라도, 핵심 기능이 자주 중단된다면 서비스 품질에 치명적입니다.

• 인증/인가 서버: 사용자의 로그인, 권한 확인 등을 처리하는 서버.
• 결제 처리 서버: 사용자의 결제 요청을 처리하는 민감한 서버.
• 주문 처리 마이크로서비스: 전자상거래의 핵심인 주문 생성 및 처리 로직을 담고 있는 서버.

이러한 파드들은 Burstable로 운영할 수도 있지만, 서비스의 중요도와 안정성 요구 수준이 매우 높다면 Guaranteed로 설정하여 어떤 상황에서도 축출되지 않도록 보호하는 것이 좋습니다.

📈 3. 클러스터 운영의 핵심 컴포넌트

애플리케이션뿐만 아니라, 클러스터 자체의 모니터링 및 로깅을 담당하는 파드들도 높은 우선순위를 가져야 합니다. 이들이 먼저 종료되면 클러스터에 문제가 발생했을 때 원인을 파악할 수 없는 '장님' 상태가 됩니다.

• 모니터링 시스템: Prometheus, Grafana, Thanos 등
  • 이유: 클러스터와 애플리케이션의 상태를 지속적으로 수집하고 시각화하는 도구입니다. 리소스 부족 상황일수록 이들의 데이터는 더욱 중요해집니다.
• 로깅 시스템: Fluentd, Logstash 등
  • 이유: 애플리케이션 로그를 수집하여 중앙 저장소로 보내는 역할을 합니다. 로그 수집 에이전트가 종료되면 장애 상황의 로그가 유실되어 원인 분석이 불가능해집니다.

---

QoS 클래스별 추천 워크로드 요약

QoS 클래스	우선순위	추천 워크로드	특징 및 전략
Guaranteed	높음	데이터베이스, 메시지 큐, 핵심 API 서버, 모니터링/로깅 에이전트 등 절대 중단되면 안 되는 워크로드	리소스를 확실하게 예약하여 성능을 보장하고 축출을 방지합니다. 선택적으로 신중하게 적용해야 합니다.
Burstable	중간	일반적인 웹 서버, 대부분의 백엔드 API 서버, CI/CD 잡 등 재시작에 영향이 적은 대부분의 무상태(Stateless) 워크로드	가장 일반적이고 유연한 선택지입니다. 최소 리소스를 보장받으면서 필요시 추가 리소스를 사용할 수 있습니다.
BestEffort	낮음	개발/테스트용 파드, 일회성 배치(batch) 작업, 중요하지 않은 분석 스크립트 등 없어져도 무방한 워크로드	클러스터의 남는 리소스만 사용합니다. 중요한 시스템에는 절대 사용하면 안 됩니다.

 

결론

쿠버네티스 QoS 클래스는 리소스 부족 상황에서 클러스터의 안정성을 지키는 중요한 방어선입니다. 가장 중요한 것은 애플리케이션의 특성과 비즈니스 중요도를 정확히 파악하고 그에 맞는 QoS 클래스를 부여하는 것입니다.

무조건 모든 파드를 Guaranteed로 설정하기보다는, 데이터베이스나 메시지 큐처럼 상태를 가지거나(Stateful) 서비스의 명백한 장애 지점이 되는(Single Point of Failure) 컴포넌트를 우선적으로 보호하는 전략이 중요합니다. 나머지 일반적인 애플리케이션은 Burstable로 설정하여 유연성을 확보하고, 중요하지 않은 일회성 작업들은 BestEffort로 남겨두어 리소스 효율성을 높이는 것이 현명한 클러스터 관리의 첫걸음입니다.

지금 바로 여러분의 클러스터에 배포된 파드들의 QoS 클래스를 확인하고, 서비스 중요도에 맞게 리소스 설정을 조정해보세요!