002-pod failure

Tag

Experiments

Pod Failure — Pod 장애 주입 및 알람 구축

목적: Pod failure chaos 주입에서의 서비스 영향을 관찰하고, Ready Pod 감소 및 재시작을 감지하는 alert를 구축해 검증한다.

1. 개요

Chaos Mesh의 PodChaos(action: pod-failure)로 podinfo Pod 중 하나에 failure 상태를 주입해 일정 기간 비정상 상태를 유지시키고, k6로 동일한 부하를 주며 서비스 영향을 관찰했다. 이 실험은 다음 두 단계로 진행했다.

단계	내용
1차 (개선 전)	Pod Failure 주입, k6/Grafana 지표만으로 관찰
2차 (개선 후)	Pod restart 및 Ready Pod 감소를 감지하는 Alertmanager 규칙(PodinfoPodRestarted, PodinfoNotEnoughReadyPods) 추가 후 재실험

이번 개선은 latency나 fail rate를 낮추는 것이 목적이 아니라, 장애 발생을 알람으로 감지(MTTD)할 수 있는 체계를 마련하는 것이 목적이다.

2. 실험 환경

•

대상 서비스: podinfo (http://podinfo.chaos-lab.local)

•

부하 도구: k6 (Rate 15 req/s, Duration 6m)

•

장애 주입: Chaos Mesh (PodChaos)

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: podinfo-pod-failure
  namespace: chaos-mesh
spec:
  action: pod-failure
  mode: one
  duration: "2m"
  selector:
    namespaces:
      - podinfo
    labelSelectors:
      app.kubernetes.io/name: podinfo
YAML
복사

•

모니터링: Prometheus + Grafana + Alertmanager(Discord 연동)

3. 1차 실험 (개선 전)

결과

지표	값
총 요청 수	5,385 건
실패율	0.46% (25건)
p50 latency	2.37ms
p90 latency	17.47ms
p95 latency	41.61ms
p99 latency	153.25ms
max latency	606ms
checks 통과율	99.77%

Grafana 대시보드

1차 — Overview / Pod Health / Traffic & Latency

대시보드를 보면 Pod 재시작 횟수가 누적으로 증가하는 구간이 관찰되고, 재시작 Rate 패널에서도 같은 구간에 스파이크가 나타난다. fail count는 25건으로, Pod 재시작 자체가 요청 실패로 크게 이어지지는 않은 것으로 보인다.

이 시점에는 Pod 재시작이나 Ready Pod 감소를 감지하는 alert가 구축되어 있지 않아, 장애 발생 여부를 알기 위해서는 Grafana 대시보드를 직접 확인해야 했다.

4. 관측성 개선 — Alertmanager 규칙 추가

Pod 재시작과 Ready Pod 감소를 자동으로 감지할 수 있도록 두 가지 alert 규칙을 추가했다.

Alert	조건	의미
PodinfoPodRestarted	최근 2분 내 podinfo 컨테이너 재시작 발생	Pod Failure, liveness 실패, 배포 등으로 인한 재시작 감지
PodinfoNotEnoughReadyPods	Ready Pod 수가 3 미만으로 감소	Pod Failure, readiness 실패, 스케줄링 문제 등으로 인한 가용 Pod 부족 감지

- alert: PodinfoPodRestarted
  expr: sum(increase(kube_pod_container_status_restarts_total{namespace="podinfo", pod=~"podinfo-.*"}[2m])) > 0
  for: 0m
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo pod restarted"
    description: "podinfo container restarted within the last 2 minutes. Check for Pod Failure, liveness failure, recent deployments, or container logs."

- alert: PodinfoNotEnoughReadyPods
  expr: sum(kube_pod_status_ready{namespace="podinfo", condition="true", pod=~"podinfo-.*"}) < 3
  for: 30s
  labels:
    severity: warning
    service: podinfo
    namespace: podinfo
  annotations:
    summary: "podinfo ready pod count is below threshold"
    description: "Ready pod count is below 3. Check for Pod Failure, readiness failure, scheduling, or application health."
YAML
복사

두 alert 모두 severity는 warning으로 설정했고, Discord로 알림을 전달하도록 연동했다.

5. 2차 실험 (개선 후 — Alert 동작 검증)

결과

지표	1차 (개선 전)	2차 (개선 후)	비교
실패율	0.46% (25건)	0.46% (25건)	동일
p50 latency	2.37ms	2.14ms	소폭 감소
p90 latency	17.47ms	10.94ms	감소
p95 latency	41.61ms	32.63ms	감소
p99 latency	153.25ms	101.42ms	감소
max latency	606ms	657ms	소폭 증가
checks 통과율	99.77%	99.77%	동일

fail count와 checks rate는 1차와 2차가 완전히 동일하다. 이는 이번 개선이 alert 체계 구축에 한정되어 있고, Pod Failure 자체에 대한 복구 로직(retry, readiness probe 조정 등)을 변경하지 않았기 때문이다. latency나 CPU 사용률의 차이는 alert 도입 효과가 아니라 실행 시점의 부하 편차로 해석한다.

Grafana 대시보드

2차 — Overview / Pod Health / Traffic & Latency

2차 실험에서도 컨테이너 재시작 횟수가 증가하는 구간이 관찰되었고, 이번에는 같은 구간에 PodinfoPodRestarted와 PodinfoNotEnoughReadyPods alert가 Discord로 정상 수신되었다. 장애 종료 후 두 alert 모두 Resolved로 전환되었다.

알람 동작 확인

Pod Failure 주입과 함께 두 alert가 모두 정상적으로 Firing 되었고, 장애 종료 후 Resolved로 전환되는 것을 확인했다.

2차 실험(k6 기록 기준 chaos 주입 시각 11:41:59 UTC)을 기준으로 실제 Discord 알림 수신 시각을 비교하면 다음과 같다.

Alert	Discord 수신 시각 (UTC)	Discord 수신 기준 MTTD
PodinfoPodRestarted	11:42:44.844	약 46초
PodinfoNotEnoughReadyPods	11:43:14.726	약 1분 16초

해당 MTTD는 Prometheus가 alert 조건을 처음 감지한 시각이 아니라, Discord 메시지 ID의 Snowflake timestamp를 기준으로 계산한 알림 수신 기준 MTTD다.

PodinfoPodRestarted는 for: 0m으로 설정되어 있어 restart metric이 감지된 뒤 약 46초 후 Discord 알림이 수신되었다. PodinfoNotEnoughReadyPods는 for: 30s가 설정되어 있어 약 1분 16초 후 알림이 수신되었다. 두 alert의 수신 시각 차이는 약 30초로, PodinfoNotEnoughReadyPods의 for: 30s 설정 영향이 반영된 것으로 해석할 수 있다.

두 alert 모두 장애 발생 후 2분 이내 Discord로 수신되었고, 장애 종료 후 resolved 상태로 전환되는 것을 확인했다.

6. 결론 및 학습 내용

결론

Pod Failure 자체는 podinfo가 다중 replica(3개)로 운영되고 Kubernetes의 기본 재시작 정책이 동작하는 환경에서는 fail rate에 큰 영향을 주지 않았다. 1차/2차 모두 fail count가 25건으로 동일했고, checks 통과율도 99.77%로 유지되었다.

이번 실험에서 의미 있었던 것은 latency 개선이 아니라, Pod 장애가 발생했을 때 이를 자동으로 감지할 수 있는 체계를 마련한 것이다. alert 구축 전에는 Pod 재시작이나 Ready Pod 감소를 누군가 그 순간 Grafana 대시보드를 보고 있어야만 알 수 있었고, 이 경우 감지 시간은 측정 가능한 값이 아니라 사람이 화면을 보고 있었는지에 따라 달라지는, 사실상 정의되지 않는 상태였다. alert 구축 후에는 장애 발생 후 46초~1분 16초 사이에 Discord로 알림이 수신되는 것을 실측으로 확인했다. 즉 이번 개선의 핵심은 감지 시간을 줄인 것이 아니라, 감지 시간이라는 지표 자체를 처음으로 측정 가능하게 만든 것이다.

학습 내용

•

Pod Failure는 dashboard 기반 관찰만으로는 운영 단계에서 한계가 있다. 1차 실험에서 재시작과 Ready Pod 감소가 latency 그래프에 거의 흔적을 남기지 않았는데, 이는 multi-replica 환경에서 readiness probe와 Service 라우팅이 트래픽을 살아있는 Pod로 자연스럽게 우회시키기 때문이다. 즉 latency나 fail rate 기반 alert만으로는 이 장애 유형을 놓칠 수 있고, 별도로 kube-state-metrics 기반 alert가 필요한 이유가 여기에 있다.

•

PodinfoPodRestarted와 PodinfoNotEnoughReadyPods를 분리한 것은 단순 가독성 문제가 아니라 운영 대응을 다르게 가져가야 하기 때문이다. 재시작만 발생하고 Ready Pod 수가 유지되면 단발성 장애로 자동 복구 중임을 의미한다. 하지만 Ready Pod 부족까지 같이 Firing될 경우 replica가 정상 Ready 상태를 유지하지 못하는 상태를 의미하므로, Deployment replica 수, readiness/liveness probe, Pod scheduling, 노드 상태, 애플리케이션 로그를 함께 점검해야 할 것이다. 두 alert를 하나로 합쳤다면 이 구분이 사라진다.

•

이번 실험은 시스템의 복구 능력(replica 분산, 재시작 정책)이 이미 충분해서 추가적인 latency 개선 여지가 거의 없었던 경우다. 이런 조건에서는 엔지니어링 자원을 latency 튜닝보다 감지 체계(alert, 대시보드)에 투입하는 것이 합리적이라고 판단했다. alert가 없던 상태에서는 감지 시간이라는 지표 자체가 존재하지 않았고, 이번 구축으로 그 지표를 처음으로 측정 가능한 값(46초~1분 16초)으로 만들었다는 점이 이번 실험의 실질적인 성과다.

부록. Alertmanager 규칙

항목	내용
알람명	PodinfoPodRestarted
조건	최근 2분 내 podinfo 컨테이너 재시작 1회 이상
메트릭	kube_pod_container_status_restarts_total
for	0m
심각도	warning

항목	내용
알람명	PodinfoNotEnoughReadyPods
조건	Ready Pod 수 < 3
메트릭	kube_pod_status_ready
for	30s
심각도	warning