DongHyeonkaandClaude Opus 5
4177fb6a48
Both pods go NotReady, the Service endpoint list empties and the front door returns 503, so adding Keycloak replicas buys nothing against database loss. The node holding the session in cache fails too, because a refresh writes LAST_SESSION_REFRESH. Recovery was automatic in about fifteen seconds with no restart, which is what readiness rather than liveness buys. The observability finding matters as much: up stayed at 1 through a total outage, so alerting on it would have caught nothing. kube-state-metrics is missing and pod readiness is therefore not recorded as a metric. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
22 lines
961 B
Plaintext
22 lines
961 B
Plaintext
=== ★ up 지표는 무엇을 말하는가 (프로세스는 살아 있다) ===
|
|
up{pod=keycloak-1} = 1 ← 1 인데 서비스는 503 이다
|
|
up{pod=keycloak-0} = 1 ← 1 인데 서비스는 503 이다
|
|
|
|
=== 복구 — PostgreSQL 재기동 ===
|
|
재기동 시각: 11:57:09
|
|
deployment.apps/postgres scaled
|
|
Waiting for deployment "postgres" rollout to finish: 0 out of 1 new replicas have been updated...
|
|
Waiting for deployment "postgres" rollout to finish: 0 of 1 updated replicas are available...
|
|
deployment "postgres" successfully rolled out
|
|
|
|
=== Keycloak 이 스스로 회복하는가 (재시작 없이) ===
|
|
+15초 keycloak-0 true keycloak-1 true | 외부 HTTP 200
|
|
→ 서비스 복귀
|
|
|
|
=== 재시작 횟수 — 파드가 죽었다 살아난 것인가, 그대로 회복한 것인가 ===
|
|
keycloak-0 0
|
|
keycloak-1 0
|
|
|
|
=== 정지 전 세션이 살아남았는가 ===
|
|
online 세션 5
|