- osaka config.yaml의 죽은 etcd host(10.100.2.214) → mbp 정상 주소(100.115.154.78)로 수정 - osaka가 로컬 waf-etcd 대신 Patroni 공유 통합 etcd를 실사용 중임을 문서화 - mbp etcd 부트스트랩 플래그의 stale 4번째 멤버(etcd-hp2) 기록 - mbp raft 파티션 자연복구 사례 및 osaka APISIX 버전 지연(3.15.0, 최신 3.17.0) 기록
3.3 KiB
date, topic, areas, tags
| date | topic | areas | tags | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 2026-07-21 | osaka APISIX etcd 설정 오류 발견 및 정정, mbp etcd 멤버 raft 파티션 자연 복구 |
|
|
osaka APISIX 버전 확인 과정에서 실제 실행 중인 설정을 점검하다가 두 가지 문제를 발견하고 정정했다.
발견 1: osaka는 로컬 waf-etcd 컨테이너를 쓰지 않는다
/opt/waf-saas/docker-compose.yml에는 로컬 waf-etcd(quay.io/coreos/etcd:v3.5.11) 컨테이너가 정의돼 있지만 실제로는 기동돼 있지 않았다. 살아있는 config.yaml은 Patroni DCS와 공유하는 [../infra/data/postgresql-ha|외부 통합 etcd 클러스터]를 prefix /apisix/osaka로 사용 중이었다.
발견 2: config.yaml의 3번째 etcd host가 죽은 주소였다
config.yaml의 etcd host 목록:
192.168.9.100 (nas, 정상)
10.100.2.214 (죽은 주소 — 응답 없음)
10.253.101.233 (jp1, 정상)
10.100.2.214는 mbp의 etcd-mbp 컨테이너 자체의 --initial-cluster 부트스트랩 플래그에 남아있던 옛 4번째 멤버 etcd-hp2의 주소였다 (hp2 기반 etcd 멤버는 이미 클러스터에서 제거된 상태, member/list엔 3개만 존재). osaka config가 원본 부트스트랩 문자열을 그대로 베껴서 생긴 drift로 추정. 실제 3번째 멤버(etcd-mbp)의 올바른 주소는 100.115.154.78(Tailscale)인데 config엔 아예 없었다.
조치: config.yaml의 10.100.2.214 → 100.115.154.78로 수정, docker compose restart waf-apisix로 적용. 재시작 후 로그에 no route to host 재발 없음, 라우트 11개 정상 로드, ironclad.it.com 200 응답 확인.
발견 3 (조사 중 지나가며 확인): mbp etcd 멤버가 일시적으로 raft 파티션 상태였다
조사 시점에 etcd-mbp(100.115.154.78)가 다른 2개 멤버와 raft 스트림이 끊겨 격리된 상태였다 (failed to publish local member to cluster through raft ... request timed out 반복, 로컬 127.0.0.1:2379/health조차 무응답). SSH(22번 포트)는 Tailscale로 정상 접속됐으나 raft 스트림만 끊겨 있었음 — 원인은 특정하지 못했으나 재접속 시도 중 자연 복구됨 (established TCP streaming connection with remote peer 로그, 이후 3노드 전부 정상). 클러스터는 nas+jp1 2/3 쿼럼으로 계속 정상 서비스 중이었어서 이 기간 동안 실제 장애는 없었음.
교훈
- APISIX 인스턴스가 여러 개(서울 K3s, 오사카, 서울 relay) 있고 etcd 백엔드도 로컬/K3s내부/외부통합으로 제각각이라, "이 인스턴스가 실제로 어떤 etcd를 쓰는지"는
docker ps/config.yaml실물을 봐야 확실함 — 문서에 적힌 구성과 실제가 다를 수 있음 - 설정값에 여러 호스트 IP가 나열돼 있으면 그중 죽은 게 있는지 개별 헬스체크로 확인할 것. compose 파일에 정의된 서비스가 곧 실제로 쓰이는 서비스라고 가정하지 말 것
- 3노드 중 1노드가 조용히 파티션되어도 쿼럼(2/3)만 유지되면 겉으로는 정상 동작해서 알아채기 어려움 — 정기적으로
member/list+ 각 멤버 개별 헬스체크 권장