monitoring 1033 에러 해결
Sprint 80: monitoring 1033 에러 해결
Decisions
D1: blog Deployment preStop hook으로 zero-downtime 배포 확보
- Context: blog.algo-su.com에서 Cloudflare Error 1033 재발. Sprint 69에서 cloudflared
--metrics플래그 누락으로 동일 에러를 해결했으나, 이번에는 cloudflared pod 자체는 정상(Running, 재시작 0회,--metrics 0.0.0.0:2000적용됨). 근본 원인은 ArgoCD 롤링 업데이트 시 replicas=1 환경에서 구 pod readiness probe 실패 → Service endpoints 공백 → cloudflared가 upstream 502 → Cloudflare 1033 전파. - Choice: blog Deployment spec에
preStop: exec: command: ["sh", "-c", "sleep 5"]lifecycle hook 추가. 구 pod이 SIGTERM 수신 후에도 5초간 트래픽을 계속 서빙하여 새 pod이 Ready 상태에 도달할 때까지 endpoints 공백을 제거. - Alternatives: (a) replicas=2로 증설 — OCI ARM 리소스 한계(메모리 24GB, 6서비스+monitoring 가동 중)로 상시 2 replica 유지 비용 부담, 기각. (b)
maxSurge=1, maxUnavailable=0전략만 적용 — 이미 기본값이나 readiness 실패 시 endpoints 공백을 방지하지 못함, 기각. (c) Recreate 전략 — 의도적 다운타임 허용이므로 기각. - Code Paths:
infra/k3s/blog.yaml(또는 aether-gitops 해당 매니페스트)
Patterns
P1: replicas=1 서비스의 zero-downtime 롤링 업데이트 패턴
- Where: blog Deployment
spec.template.spec.containers[].lifecycle.preStop - When to Reuse: replicas=1인 Deployment에서 롤링 업데이트 시 트래픽 단절을 방지해야 할 때. 핵심 메커니즘: (1)
maxSurge=1, maxUnavailable=0으로 새 pod을 먼저 기동, (2) 구 pod에preStop: sleep N(N = 새 pod readiness 소요 시간 + 여유)을 적용하여 SIGTERM 후에도 일정 시간 트래픽 서빙 유지.terminationGracePeriodSeconds가 preStop sleep 시간 이상이어야 한다.
Gotchas
G1: replicas=1 + maxUnavailable=0이어도 readiness 실패로 endpoints 공백 발생 가능
- Symptom: blog 이미지 배포(commit 7fe12ea) 후 blog.algo-su.com에서 Cloudflare Error 1033 재발. cloudflared pod는 정상 가동 중.
- Root Cause: 롤링 업데이트 시 kubelet이 구 pod(blog-65869f5699)에 SIGTERM을 전송하면 즉시 readiness probe가
connection reset by peer로 실패. kube-proxy가 구 pod을 endpoints에서 제거하지만 새 pod(blog-64998d8b9f)은 아직 Ready가 아닌 상태. 결과적으로 blog Service의 endpoints가 0개가 되어 cloudflared가 upstream 502를 수신하고 Cloudflare가 Error 1033을 반환. - Fix:
preStop: exec: command: ["sh", "-c", "sleep 5"]로 구 pod이 SIGTERM 후 5초간 프로세스 종료를 지연. 이 5초 동안 구 pod은 여전히 트래픽을 서빙하고 readiness probe도 통과하므로 새 pod이 Ready가 될 때까지 endpoints 공백이 발생하지 않음.
D2: monitoring 터널 cloudflared connector 복구
- Context: monitoring.algo-su.com에서 Cloudflare Error 1033 발생. 터널
05b4b0d6에 Public Hostname이 등록되어 있으나 해당 터널의 cloudflared connector(pod)가 클러스터에 부재. 기존 cloudflared Deployment는 터널47de6ba1(blog용)만 연결. - Choice:
cloudflared-monitoringDeployment를 신규 생성하여 터널05b4b0d6의 connector 복구. 기존 blog 터널과 별도 운영. - Alternatives: (a) 두 도메인을 단일 터널로 통합 — Cloudflare 대시보드에서 터널 재구성 필요 + DNS CNAME 변경, 운영 중 서비스 중단 위험으로 기각.
- Code Paths:
infra/k3s/cloudflared-monitoring.yaml
Metrics
- Commits: 2건 (46e4525, 6b2063e)
- Files changed: 3개 (+98/-0)
- 서비스 영향: blog.algo-su.com — 롤링 업데이트 시 Error 1033 방지, monitoring.algo-su.com — Grafana 접근 복구