Files
keycloak-pattern/docs/evidence/a4-node-loss
DongHyeonkaandClaude Opus 5 d0666c5ba0 docs: A-4 — a dead pod reports healthier than a live one
Kubernetes keeps calling the node Ready for forty seconds while users already see failures, and the pod on the powered-off machine stays ready=true because its kubelet can no longer contradict itself. Eviction waits another five minutes, then the StatefulSet refuses to recreate its pod and the replacement Deployment pod cannot schedule because the local-path volume is pinned to the dead node.

Killing the server node instead shows the opposite shape: containerd keeps the workload running while the API server, Traefik and the observability stack disappear, so the outage is the missing path rather than the missing application. Traefik at one replica is the ingress single point of failure.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-04 12:25:30 +09:00
..

A-4 — 노드 전원 차단 증거

2026-09-04 12:0712:24 KST 해설: docs/experiment-a4-node-loss.md

파일 무엇을 보여주는가
01-baseline.txt 차단 전 — 양쪽 Ready, PVC 가 kc-lab-2 에 못박혀 있음(재배치 불가의 원인), 외부 200
02-worker-node-killed.txt virsh destroy kc-lab-240초간 노드가 Ready 로 남아 있고 외부는 이미 000. 이후 503
03-state-during-loss.txt 죽은 파드가 ready=true, 산 파드가 ready=false. up 은 정확히 0. unreachable taint
04-eviction-timing.txt tolerationSeconds=3005분 뒤 축출, 새 postgres 는 Pending
05-recovery.txt FailedScheduling: didn't match PersistentVolume's node affinity, StatefulSet DESIRED=2 CURRENT=1. 노드 복귀 후 60초
06-control-plane-inventory.txt kc-lab-1 에 있는 것 목록 — Traefik replicas=1
07-control-plane-loss.txt virsh destroy kc-lab-1 — 외부 000, kubectl 불통. 그런데 crictl ps 로 보면 keycloak-0 은 Running
08-control-plane-recovery.txt 60초 만에 복귀
a4-up-dropped-per-node.png Grafana — up 이 노드별로 0 으로 떨어지는 구간. 12:1812:23 은 0 이 아니라 데이터 없음(관측자가 같이 죽음)

핵심 네 줄

  1. 쿠버네티스는 40초 동안 노드가 살아 있다고 말한다. 사용자는 이미 장애를 겪는 중이다.
  2. 죽은 파드의 상태는 화석이다. ready=true 인 파드가 꺼진 기계 위에 있다.
  3. StatefulSet 은 대체 파드를 만들지 않고, PVC 는 재배치를 막는다. 사람이 개입해야 한다.
  4. 컨트롤 플레인 상실 ≠ 워크로드 상실. 컨테이너는 계속 돌고, 들어갈 문만 사라진다.