장애 대응 순서:

1. kubectl get pod               → 상태 코드 확인 (Pending/CrashLoop/OOMKilled/Evicted)
2. kubectl describe pod          → Events 섹션에서 구체적 원인 확인
3. kubectl logs --previous       → 크래시 직전 로그 확인
4. kubectl get events            → 클러스터 레벨 이벤트
5. kubectl exec / kubectl debug  → 컨테이너 내부 직접 확인
6. kubectl top pod/node          → 자원 사용량 확인

# 1단계: Events에서 원인 확인
kubectl describe pod <pod-name> -n <namespace>
# Events 섹션 핵심 메시지들:

# 원인 1: 리소스 부족
# Warning  FailedScheduling  0/3 nodes are available:
#   1 Insufficient cpu, 2 Insufficient memory.

# 원인 2: Node Affinity 미충족
# Warning  FailedScheduling  0/3 nodes are available:
#   3 node(s) didn't match Pod's node affinity/selector.

# 원인 3: PVC 미바인딩
# Warning  FailedScheduling  0/3 nodes are available:
#   3 pod has unbound immediate PersistentVolumeClaims.

# 원인 4: Taint/Toleration 불일치
# Warning  FailedScheduling  0/3 nodes are available:
#   3 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }.

# 노드별 할당 가능 자원 확인
kubectl describe nodes | grep -A5 "Allocated resources"
# 출력:
#   Allocated resources:
#     (Total limits may be over 100 percent, i.e., overcommitted.)
#     Resource           Requests    Limits
#     --------           --------    ------
#     cpu                1850m/2     3500m/2     ← 거의 꽉 찬 상태
#     memory             1.8Gi/4Gi   3.2Gi/4Gi

# 파드별 리소스 요청량 확인
kubectl get pods -n <namespace> -o json | \
  jq '.items[] | {name: .metadata.name, cpu: .spec.containers[0].resources.requests.cpu, mem: .spec.containers[0].resources.requests.memory}'

# 해결 1: 파드의 resources.requests 줄이기 (실제 사용량 기반)
kubectl top pod -n <namespace>   # 실제 사용량 확인 후 requests 조정

# 해결 2: 노드 추가 (클러스터 오토스케일러 또는 수동)
# 해결 3: 다른 네임스페이스의 불필요한 파드 정리

# PVC 상태 확인
kubectl get pvc -n <namespace>
# NAME           STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS
# payment-data   Pending   -        -          -              fast-ssd    ← 문제

# PVC 상세 확인
kubectl describe pvc payment-data -n <namespace>
# Events:
#   Warning  ProvisioningFailed  storageclass.storage.k8s.io "fast-ssd" not found
#   → StorageClass 이름 오류

# 사용 가능한 StorageClass 확인
kubectl get storageclass

# PVC YAML 수정 (올바른 StorageClass로)
kubectl patch pvc payment-data -n <namespace> \
  --type=json \
  -p='[{"op":"replace","path":"/spec/storageClassName","value":"standard"}]'

# 현재 크래시 중인 컨테이너 로그
kubectl logs <pod-name> -n <namespace>

# 핵심: 이전 크래시 컨테이너 로그 (실제 오류 메시지는 여기에)
kubectl logs <pod-name> -n <namespace> --previous

# 재시작 횟수 확인
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.status.containerStatuses[0].restartCount}'
# 10 이상이면 심각한 반복 크래시

# 원인 1: 설정 오류 (환경변수, ConfigMap, Secret)
kubectl logs <pod-name> --previous | grep -i "error\|fatal\|panic"
# 예: "Error: DB_HOST environment variable is required"

# 환경변수 확인
kubectl describe pod <pod-name> | grep -A20 "Environment:"

# Secret/ConfigMap 존재 확인
kubectl get secret db-credentials -n <namespace>
kubectl get configmap app-config -n <namespace>

# 원인 2: 이미지 실행 파일 없음 (CMD/ENTRYPOINT 오류)
# Exit Code: 127
kubectl describe pod <pod-name> | grep -E "Exit Code|Command|Args"

# 이미지 확인 (임시 컨테이너로)
kubectl run debug-img --image=payment:2.0.0 --restart=Never \
  --command -- /bin/sh -c "ls /app && cat /app/start.sh"

# 원인 3: 포트 충돌 또는 바인딩 실패
kubectl logs <pod-name> --previous | grep "bind\|address already in use"

# 원인 4: 리소스 한도 초과로 즉시 OOMKilled
kubectl describe pod <pod-name> | grep -E "OOMKilled|Exit Code: 137"

# 크래시 직전 컨테이너를 잡기 위한 debug 방법
# 방법 1: command 오버라이드로 sleep으로 시작 (YAML 수정 필요)
# command: ["sleep", "3600"]  # 앱 대신 sleep으로 시작해서 exec로 내부 확인

# 방법 2: kubectl debug (비침습적)
kubectl debug -n <namespace> <pod-name> \
  -it --image=busybox --copy-to=debug-pod \
  --container=app -- sh

# 방법 3: 에러 재현을 위한 임시 파드
kubectl run test-pod -n <namespace> \
  --image=payment:2.0.0 \
  --restart=Never \
  --env="DB_HOST=postgres.production.svc.cluster.local" \
  --env="DB_PASSWORD=$(kubectl get secret db-creds -o jsonpath='{.data.password}' | base64 -d)" \
  -- /bin/sh -c "/app/start.sh; echo exit_code=$?"
kubectl logs test-pod

# OOMKilled 확인
kubectl describe pod <pod-name> | grep -A3 "OOM\|137"

# 실제 메모리 사용량 측정 (최소 24시간 관찰 권장)
kubectl top pod <pod-name> -n <namespace> --containers

# 과거 메모리 사용 추이 (Prometheus 쿼리)
# container_memory_working_set_bytes{pod="payment-xxx", namespace="production"}

# 메모리 limits 확인
kubectl get pod <pod-name> -n <namespace> \
  -o jsonpath='{.spec.containers[0].resources.limits.memory}'

# 측정값 기반으로 limits 상향 조정
# 실제 최대 사용량의 130% 정도를 limits로 설정
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment
spec:
  template:
    spec:
      containers:
        - name: payment
          resources:
            requests:
              memory: "256Mi"    # 평균 사용량
              cpu: "100m"
            limits:
              memory: "512Mi"    # 최대 사용량 × 1.3
              cpu: "500m"

# 메모리 누수 패턴 감지 (시간에 따라 계속 증가하는지)
# 정상: 사용량이 일정 수준 유지 또는 GC 후 감소
# 누수: 사용량이 계속 우상향, GC 후에도 감소하지 않음

# Java 애플리케이션 메모리 덤프 (OOM 전에)
kubectl exec -n production <pod-name> -- \
  jmap -dump:format=b,file=/tmp/heap.hprof $(pgrep java)
kubectl cp <pod-name>:/tmp/heap.hprof ./heap.hprof -n production

# Node.js 힙 스냅샷
kubectl exec -n production <pod-name> -- \
  kill -SIGUSR2 $(pgrep node)
# inspector에서 heapsnapshot 파일 확인

# Python 메모리 프로파일링
kubectl exec -n production <pod-name> -- \
  python -c "
import tracemalloc
tracemalloc.start()
# ... 앱 실행 ...
snapshot = tracemalloc.take_snapshot()
for stat in snapshot.statistics('lineno')[:10]:
    print(stat)
"

# Evicted 파드 전체 확인
kubectl get pods -A | grep Evicted
kubectl get pods -A --field-selector=status.phase=Failed | grep Evicted

# Eviction 이유 확인
kubectl describe pod <evicted-pod-name> | grep -A5 "Message"
# Message: The node was low on resource: ephemeral-storage.
#          Threshold quantity: 10%, available: 1152Ki.
# 또는:
# Message: The node had condition: [MemoryPressure].
# 또는:
# Message: The node had condition: [DiskPressure].

# 노드 컨디션 확인
kubectl describe nodes | grep -A5 "Conditions:"
# MemoryPressure    True  → 메모리 압박
# DiskPressure      True  → 디스크 압박
# PIDPressure       True  → 프로세스 수 압박

# Evicted 파드는 Running이 아니므로 수동 정리 필요
# (새 파드는 자동 생성되지만 Evicted 파드 객체는 남음)

# Evicted 파드 일괄 삭제
kubectl get pods -A --field-selector=status.phase=Failed \
  -o json | \
  jq -r '.items[] | select(.status.reason=="Evicted") | "\(.metadata.namespace) \(.metadata.name)"' | \
  while read ns pod; do kubectl delete pod "$pod" -n "$ns"; done

# 한 줄 명령 버전
kubectl get pods --all-namespaces -o json | \
  jq '.items[] | select(.status.phase=="Failed" and .status.reason=="Evicted") | .metadata | "\(.namespace) \(.name)"' -r | \
  xargs -L1 bash -c 'kubectl delete pod $2 -n $1' _

# 실행 중인 파드 옆에 디버그 컨테이너 붙이기 (파드 재시작 없음)
kubectl debug -n production <pod-name> \
  -it --image=nicolaka/netshoot \
  --target=payment              # 같은 PID 네임스페이스 공유

# 디버그 컨테이너에서:
# - 같은 네트워크 네임스페이스 (네트워크 연결 테스트 가능)
# - 같은 PID 네임스페이스 (ps aux로 앱 프로세스 확인)
# - 파드 재시작 없이 진단 가능

# 네트워크 연결 테스트
kubectl debug -n production <pod-name> \
  -it --image=nicolaka/netshoot -- \
  curl -v http://postgres.production.svc.cluster.local:5432

# DNS 해석 확인
kubectl debug -n production <pod-name> \
  -it --image=nicolaka/netshoot -- \
  nslookup postgres.production.svc.cluster.local

# 특정 네임스페이스 이벤트 실시간 확인
kubectl get events -n production --watch

# 경고 이벤트만 필터링
kubectl get events -n production \
  --field-selector type=Warning \
  --sort-by='.lastTimestamp'

# 특정 파드 관련 이벤트
kubectl get events -n production \
  --field-selector involvedObject.name=<pod-name>

# 자주 발생하는 경고 이벤트 집계
kubectl get events -A --sort-by='.count' | \
  grep Warning | tail -20

# 노드에 스케줄된 파드 현황
kubectl get pods -A --field-selector=spec.nodeName=worker-1

# 노드 자원 할당 현황 상세
kubectl describe node worker-1 | grep -A20 "Allocated resources"

# 노드 조건 전체 확인
kubectl get node worker-1 -o json | \
  jq '.status.conditions[] | {type: .type, status: .status, message: .message}'

# 문제 노드 격리 (새 파드 스케줄 방지 + 기존 파드 evict)
kubectl drain worker-1 \
  --ignore-daemonsets \
  --delete-emptydir-data \
  --grace-period=30
# 노드 수리 후 복구:
kubectl uncordon worker-1

# 일시적으로 새 파드만 스케줄 방지 (기존 파드 유지)
kubectl cordon worker-1