Kubernetes Pod Eviction: 예방 전략

Source: Dev.to

Gene Gallin이 촬영한 사진 (Unsplash)

왜 파드 퇴거 이해가 중요한가

Kubernetes와 함께 일하는 DevOps 엔지니어나 개발자라면 파드 퇴거를 이해하는 것이 신뢰성과 가용성을 유지하는 데 중요합니다. 파드 퇴거는 다음과 같은 결과를 초래할 수 있습니다:

• 심각한 다운타임
• 데이터 손실
• 부정적인 사용자 경험

근본 원인을 파악하고 완화 전략을 학습함으로써 Kubernetes 배포의 복원력을 크게 향상시킬 수 있습니다.

Pod 퇴거에 대한 간략 개요

• 퇴거를 트리거하는 조건은?
  시스템은 파드의 리소스 사용량과 해당 파드가 속한 QoS 클래스에 따라 파드를 종료하기로 결정합니다.

• QoS 클래스 (우선순위 높은 순서부터 낮은 순서까지):

  1. Guaranteed
  2. Burstable
  3. BestEffort

• 일반적인 증상:

  • 파드가 예기치 않게 종료됨
  • 지연 시간 증가
  • 파드가 사용 불가능함을 나타내는 애플리케이션 로그 오류

실제 사례: 웹 애플리케이션에 트래픽 급증이 발생하고, 파드가 할당된 리소스보다 더 많이 사용하게 되면 노드가 파드를 퇴거시켜 서비스 다운타임이 발생합니다.

사전 요구 사항

파드 퇴출 진단

1. 퇴출된 파드 식별

kubectl get pods -A | grep -v Running

이 명령은 모든 네임스페이스의 모든 파드를 나열하고 실행 중인 파드를 제외하여, 원하는 상태가 아닌 파드를 찾는 데 도움이 됩니다.

2. 근본 원인 파악

노드 자원 사용량 확인

kubectl top node

파드의 QoS 클래스 확인

kubectl get pod <pod-name> -o yaml | grep qosClass

완화 전략

리소스 요청/제한 조정

파드가 리소스 부족으로 퇴출되는 경우, 요청/제한을 늘립니다:

kubectl patch pod <pod-name> -p '{
  "spec": {
    "containers": [
      {
        "name": "<container-name>",
        "resources": {
          "requests": {
            "cpu": "200m",
            "memory": "256Mi"
          }
        }
      }
    ]
  }
}'

QoS 클래스 업그레이드

파드의 QoS 클래스가 우선순위와 일치하도록 합니다. Guaranteed 클래스의 경우, CPU와 memory에 대해 requests와 limits를 동일하게 설정합니다.

수정 사항 확인

kubectl get pod <pod-name>
kubectl top node

성공적인 결과는 파드가 Running 상태에 있고, 노드 사용량이 허용 가능한 범위 내에 있음을 보여줍니다.

예시 매니페스트

명시적 리소스 요청 및 제한을 가진 Pod

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 200m
          memory: 256Mi

수평 Pod 자동 스케일러 (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: example-hpa
spec:
  selector:
    matchLabels:
      app: example-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

일반적인 함정 및 회피 방법

• 리소스 할당 부족 – CPU/메모리를 충분히 할당하지 않으면 퇴거가 발생합니다.
  해결책: 활용도를 지속적으로 모니터링하고 요청/제한을 적절히 조정합니다.

• QoS 구성 오류 – QoS가 잘못 구성되면 예상치 못한 퇴거가 발생할 수 있습니다.
  해결책: QoS 클래스를 파드 우선순위와 맞추고, 중요한 워크로드에는 Guaranteed를 사용합니다.

• 모니터링 부족 – 가시성이 없으면 퇴거 문제를 놓치기 쉽습니다.
  해결책: 모니터링 도구(e.g., Prometheus + Grafana, Kube‑State‑Metrics)를 구현하여 파드 상태와 노드 건강을 추적합니다.

Monitoring Recommendations

• Node & Pod Metrics: kubectl top node / kubectl top pod or Prometheus node exporter.
• Alerting: Set alerts for high node pressure, low available memory, or frequent pod restarts.
• Logging: Capture eviction events via kubectl describe pod <pod-name> and centralize logs for analysis.

Kubernetes에서 Pod 퇴거 방지

1. 적절한 QoS 클래스 구성

• 각 pod의 Quality of Service (QoS) 클래스가 우선순위와 리소스 요구사항을 반영하도록 합니다.

2. 리소스 요청 및 제한 적용

• CPU와 메모리의 과다 사용을 방지하기 위해 모든 컨테이너에 리소스 요청 및 제한을 정의합니다.

3. Horizontal Pod Autoscaling (HPA) 사용

• 리소스 사용량(CPU, 메모리 또는 사용자 정의 메트릭)을 기반으로 복제본 수를 동적으로 조정하도록 HPA를 구성합니다.

4. 구성 정기 검토 및 조정

• 주기적으로 pod와 노드 구성을 감사하여 변화하는 애플리케이션 요구사항에 맞게 유지합니다.

왜 이것이 중요한가

Pod 퇴거는 상당한 도전 과제가 될 수 있습니다. 그 원인을 이해하고, 증상을 인식하며, 위의 전략을 적용하면 퇴거 빈도를 크게 줄일 수 있습니다.

• 목표: Pod가 효과적으로 운영되는 데 필요한 리소스를 확보하도록 보장합니다.
• 결과: 보다 신뢰성 높고 성능이 향상된 Kubernetes 환경과 사용자에게 더 나은 경험을 제공합니다.

Helpful Documentation

• Kubernetes Documentation – Quality of Service – QoS 기반으로 Kubernetes가 리소스 할당 및 우선순위를 관리하는 방법에 대한 심층 탐구.
• Kubernetes Horizontal Pod Autoscaling – CPU 사용량 또는 사용자 정의 메트릭을 기반으로 동적 스케일링을 구성하고 사용하는 가이드.
• Kubernetes Cluster Autoscaling – 수요에 맞춰 클러스터 자체(노드 추가/제거)를 확장하는 방법을 배웁니다.

Recommended Tools & Resources

최신 소식 받아보기 – DevOps Daily 뉴스레터 구독

• 주당 3개의 선별 기사
• 프로덕션 인시던트 사례 연구
• 독점 트러블슈팅 팁

도움이 되었나요? 팀과 공유하세요!