쿠버네티스 클러스터에서 노드(Node)는 애플리케이션을 실행하는 핵심 인프라입니다.
노드 장애가 발생하면 워크로드가 중단될 위험이 있으며, 이를 자동으로 감지하고 복구하는 전략이 필요합니다.
이 글에서는 노드 장애 시 자동 복구 및 리소스 재배치 전략을 수립하는 방법을 다룹니다.
📌 글에서 다루는 상황들
1. 노드 장애 감지 및 자동 복구 설정 (Node Problem Detector & Cluster Autoscaler 활용)
2. Pod Disruption Budget(PDB)를 활용한 안정적인 롤링 업데이트 및 장애 복구
3. kubectl 및 로그 분석을 활용한 노드 장애 디버깅 및 리소스 재배치 트러블슈팅
각 문제를 실무에서 바로 활용할 수 있도록 Manifest 템플릿과 예상 결과 값을 제공합니다.
1️⃣ 노드 장애 감지 및 자동 복구 설정 (Node Problem Detector & Cluster Autoscaler 활용)
❓ 문제 상황
운영팀에서 클러스터 내 특정 노드에서 지속적인 장애가 발생하고 있으며, 해당 노드에서 실행되던 Pod들이 응답하지 않는 문제가 보고되었습니다.
이를 해결하기 위해 Node Problem Detector를 활용하여 노드의 상태를 감지하고, Cluster Autoscaler를 설정하여 장애 노드를 자동으로 대체해야 합니다.
• 장애 원인: 디스크 오류, 메모리 부족, 네트워크 장애 등
• 해결 목표: 노드 장애 감지 및 새로운 노드로 리소스 자동 재배치
✅ 어떻게 해결할 수 있을까요?
🛠️ 해결 방법
1. Node Problem Detector를 배포하여 노드 상태를 지속적으로 모니터링합니다.
2. Cluster Autoscaler를 설정하여 장애 노드가 감지되면 새로운 노드를 자동으로 추가합니다.
✅ 정답 Manifest (Node Problem Detector 및 Cluster Autoscaler 설정)
🔹 Node Problem Detector 배포
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: node-problem-detector
namespace: kube-system
spec:
selector:
matchLabels:
app: node-problem-detector
template:
metadata:
labels:
app: node-problem-detector
spec:
containers:
- name: node-problem-detector
image: k8s.gcr.io/node-problem-detector:v0.8.1
securityContext:
privileged: true
🔹 Cluster Autoscaler 설정
apiVersion: apps/v1
kind: Deployment
metadata:
name: cluster-autoscaler
namespace: kube-system
spec:
selector:
matchLabels:
app: cluster-autoscaler
template:
metadata:
labels:
app: cluster-autoscaler
spec:
containers:
- name: cluster-autoscaler
image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.23.0
command:
- ./cluster-autoscaler
- --v=4
- --cloud-provider=aws
- --nodes=1:10:node-group-1✅ 이제 노드 장애가 발생하면 자동으로 새로운 노드가 추가되고, 리소스가 재배치됨
📌 적용 후 예상 결과 값
1. 노드 상태 확인
kubectl get nodes
💡 예상 출력 값 (노드 장애 발생 전)
NAME STATUS ROLES AGE VERSION
node-1 Ready worker 50d v1.25.3
node-2 Ready worker 50d v1.25.3
💡 예상 출력 값 (노드 장애 감지 후)
NAME STATUS ROLES AGE VERSION
node-1 NotReady worker 50d v1.25.3
node-3 Ready worker 1m v1.25.3✅ 장애가 발생한 노드가 NotReady 상태가 되고, 새로운 노드가 추가됨
2️⃣ Pod Disruption Budget(PDB)를 활용한 안정적인 롤링 업데이트 및 장애 복구
❓ 문제 상황
운영팀에서 노드 장애가 발생할 경우, 해당 노드에서 실행 중이던 애플리케이션이 일시적으로 중단될 위험이 있습니다.
이를 방지하기 위해 Pod Disruption Budget(PDB)를 설정하여 동시에 영향을 받는 Pod 수를 제한해야 합니다.
• 장애 원인: 노드 장애 발생 시 애플리케이션 다운타임 발생
• 해결 목표: 동시에 영향을 받는 Pod 수를 제한하여 서비스 연속성 보장
✅ 어떻게 해결할 수 있을까요?
🛠️ 해결 방법
1. Pod Disruption Budget(PDB)를 설정하여 특정 수 이상의 Pod이 동시에 중단되지 않도록 설정합니다.
2. Pod의 최소 가용성을 보장하여 다운타임을 최소화합니다.
✅ 정답 Manifest (Pod Disruption Budget 설정)
🔹 PDB 설정 (최소 1개의 Pod 유지)
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-app-pdb
namespace: default
spec:
minAvailable: 1
selector:
matchLabels:
app: web-app✅ 이제 노드 장애가 발생해도 최소 1개의 Pod은 항상 유지됨
📌 적용 후 예상 결과 값
1. PDB 적용 상태 확인
kubectl get pdb -n default
💡 예상 출력 값
NAME MIN AVAILABLE MAX UNAVAILABLE ALLOWED DISRUPTIONS AGE
web-app-pdb 1 N/A 1 5m✅ 서비스의 최소 가용성을 유지하면서 안정적으로 롤링 업데이트 가능
3️⃣ kubectl 및 로그 분석을 활용한 노드 장애 디버깅 및 리소스 재배치 트러블슈팅
❓ 문제 상황
운영팀에서 노드 장애가 발생한 후, 해당 노드에서 실행 중이던 Pod들이 새로운 노드로 정상적으로 이동했는지 확인해야 합니다.
kubectl 및 시스템 로그를 활용하여 노드 장애 원인을 분석하고, 리소스 재배치 상태를 점검해야 합니다.
✅ 어떻게 해결할 수 있을까요?
🛠️ 해결 방법
1. kubectl describe node 명령어를 사용하여 노드의 상태를 점검합니다.
2. kubectl get pods -o wide를 사용하여 Pod의 위치 변경 여부를 확인합니다.
✅ 노드 장애 분석 및 리소스 재배치 확인 명령어
🔹 노드 상태 점검
kubectl describe node node-1
💡 예상 출력 값 (비정상적인 경우)
Conditions:
Type Status LastHeartbeatTime
---- ------ -----------------
MemoryPressure True 1m
DiskPressure True 1m✅ 메모리 또는 디스크 사용량 문제로 인해 노드가 비정상적인 상태일 가능성이 있음
🔹 Pod의 새로운 노드 배치 확인
kubectl get pods -o wide
💡 예상 출력 값
NAME READY STATUS NODE
web-app-xyz 1/1 Running node-3✅ 노드 장애 발생 후, 새로운 노드로 Pod이 재배치되었음을 확인 가능