makgol's note – 운영·장애 대응

컨트롤 플레인 해부: istiod

Sat, 01 Aug 2026 00:00:00 +0900

02 · 컨트롤 플레인 해부 — istiod는 왜 CPU를 먹는가

istiod 부하는 프록시 수 × 변경 빈도 × 설정 범위의 곱입니다. 세 항이 함께 커지면 CPU가 벽을 칩니다.
증설은 감으로 정하지 않습니다. 1순위 지표는 pilot_proxy_convergence_time(수렴 시간), 그다음이 연결 프록시 수·push 폭주·CPU입니다.
CPU 증설은 응급 처치일 뿐입니다. Sidecar 리소스로 각 프록시가 보는 설정 범위를 좁혀야 진짜로 풀립니다.
그다음 레버가 디바운스·discoverySelectors 튜닝, 마지막이 수평 스케일입니다(istiod는 stateless).

그때 무슨 일이 있었나. 클러스터 규모가 커지고 배포가 잦아지면서 컨트롤 플레인 istiod의 CPU가 주기적으로 치솟았습니다. 급한 불은 CPU를 증설해서 껐지만 그건 응급 처치였습니다. 같은 맥락에서 “istio node/pod 리소스 최적화” 과제가 이어졌습니다 — 프록시 쪽 자원과 istiod가 다루는 설정 범위를 함께 손봐야 근본이 잡히기 때문입니다. 여기서는 istiod가 CPU를 먹는 메커니즘, 언제 증설해야 하는지 알려주는 지표, 증설 말고 진짜 해법을 정리합니다.

데이터 플레인과 Ingress Gateway

Sat, 01 Aug 2026 00:00:00 +0900

03 · 데이터 플레인과 Ingress Gateway — 게이트웨이를 왜 노드로 격리하나

데이터 플레인 트래픽은 남북(Ingress Gateway)과 동서(사이드카)로 나뉩니다. Ingress Gateway는 독립적으로 뜬 Envoy로, 모든 외부 트래픽이 지나는 단일 통로입니다.
관문은 성능 크리티컬한 전역 급소입니다. noisy neighbor·자원 경쟁·보안 희석을 막으려 전용 노드로 격리합니다.
격리는 taint/toleration + nodeSelector로, 가용성은 AZ 분산·안티어피니티·PDB로, 독립 스케일은 HPA·전용 LB로 확보합니다.
대가는 노드 활용률↓·운영 대상↑이지만 관문의 성능·가용성·보안 값어치가 그 비용보다 큽니다.

외부 트래픽을 받는 Ingress Gateway가 일반 워크로드 파드들과 같은 노드에서 자원을 다퉜습니다. 트래픽이 몰리는 순간 게이트웨이가 옆 파드에 CPU·네트워크를 뺏기거나 반대로 게이트웨이가 노드를 잡아먹어 이웃이 흔들렸습니다 — 전형적인 noisy neighbor입니다. 그래서 게이트웨이를 전용 노드로 분리했습니다. 이 문서는 데이터 플레인 트래픽의 두 방향과 게이트웨이의 정체, 왜·어떻게 노드로 격리하는지를 정리합니다.

장애 이야기: 간헐적 응답 이상

Sat, 01 Aug 2026 00:00:00 +0900

05 · 장애 이야기 — 메시가 낀 경로에서 간헐적 응답 이상 추적하기

메시의 5xx는 어느 홉에서 났느냐가 전부입니다. 나침반은 Envoy response flag(UH/UF/UC/UO/NR…)입니다.
추적 순서: 범위 축소 → flag 확인 → 설정 stale 여부(istioctl proxy-status) → mTLS → 라이프사이클 레이스 → 커넥션풀.
간헐적 5xx는 특히 stale 엔드포인트와 배포 시점 라이프사이클 레이스가 단골 원인입니다.
예방은 라이프사이클 훅 표준화, outlier detection, 컨트롤 플레인 수렴 관측, response_flags 대시보드 상시화.

그때 무슨 일이 있었나. EKS에 올려둔 서비스 하나가 간헐적으로 응답 이상을 냈습니다. 산발적인 5xx와 지연이었습니다. 애플리케이션 로그는 멀쩡해 보이는데 클라이언트는 이따금 실패했습니다. 요청 경로에 메시가 껴 있으니 “앱이 문제냐"로 끝낼 수 없고 앱 · 사이드카 · 컨트롤 플레인 · 네트워크를 층으로 나눠 봐야 했습니다. 이 문서는 그 추적을 순서 있는 체크리스트로 정리합니다 — 메시 장애의 나침반은 Envoy가 붙이는 response flag입니다.

메시가 공짜로 주는 관측성

Sun, 12 Jul 2026 00:00:00 +0900

06 · 메시가 공짜로 주는 관측성 — 무엇을 볼 수 있게 되나

사이드카가 이미 모든 요청을 가로채므로 앱을 고치지 않아도 메트릭·액세스 로그·트레이싱(골든 시그널)이 공짜로 나옵니다.
힘은 표준 라벨 차원에 있습니다 — response_flags로 실패 원인, connection_security_policy로 mTLS 커버리지까지 서비스와 무관하게 슬라이스합니다.
트레이싱만 예외입니다. 스팬 생성은 메시가 하지만 trace 컨텍스트 헤더 전파는 앱 몫입니다.
카디널리티는 공짜가 아닙니다 — Telemetry API로 태그를 정리·집약해 관리합니다.

메시를 도입하기 전에는 지표가 서비스마다 제각각이었습니다. 요청 수를 내보내는 팀이 있고 안 내보내는 팀이 있었고 내보내도 라벨 이름이 서비스마다 달랐습니다. Istio를 넣자 모든 서비스가 같은 스키마의 골든 시그널을 앱 코드 수정 없이 뿜기 시작했습니다 — 사이드카가 이미 모든 요청을 보고 있으니 공짜입니다. 이 문서는 메시가 주는 관측성의 세 축(메트릭·액세스 로그·트레이싱)과 그 공짜의 한계·비용을 정리합니다.

istiod 스케일링과 xDS 커넥션 재분배

Sat, 01 Aug 2026 00:00:00 +0900

09 · istiod 스케일링 — 커넥션은 왜 새 파드로 옮겨가지 않는가

istiod 메모리는 커넥션 수가 아니라 커넥션 수 × 클러스터 config 크기로 정해집니다. 커넥션 하나의 단가가 클러스터 규모를 따라 움직입니다.
xDS는 장수 gRPC 스트림입니다. 스케일아웃해도 이미 맺어진 커넥션은 새 파드로 옮겨가지 않고 Istio에 능동적 재분배 기능은 없습니다.
공식이 쥐고 있는 재분배 수단은 keepaliveMaxServerConnectionAge 강제 종료 하나입니다. Google Cloud 공식 문서 역시 이 불균형을 인정한 뒤 레플리카 다중화 + 사전 스케일링만 권합니다.
주기를 절반으로 줄이면 재연결 레이트는 2배가 됩니다(지터는 ±10%라 창을 넓혀줄 뿐입니다). 상쇄하려면 재연결 1건의 단가 — 곧 커넥션당 config 크기 — 를 깎아야 합니다.
pilot_xds(연결 수) 기반 오토스케일링은 공식 권장이 아닙니다. 공식 차트 HPA의 기본 지표는 CPU 80% 하나뿐입니다.
실측(§7): 커넥션 분포가 가장 험한 순간과 CPU가 가장 험한 순간은 다릅니다. CoV는 파드가 죽을 때, CPU·push 지연은 커넥션 총량이 늘 때 튑니다. 재분배 지표만으로 CPU 부하를 추정하면 엉뚱한 손잡이를 잡습니다.
GOMAXPROCS는 limits.cpu가 정합니다(§8). 차트가 Downward API로 주입하고 kubelet이 math.Ceil로 올림하니 소수점 CPU limit은 quota와 GOMAXPROCS가 항상 어긋납니다. 정수 코어로 걸 것.
주범은 버스트지 슬라이스 좌초가 아닙니다(§7). 좌초는 표본의 6.5%에서만 나타나는 2차 요인이었습니다. GOMAXPROCS=1이어도 OS 스레드는 17개라 좌초 표면적은 그대로 떠안으면서 병렬성만 잃는 쪽이 더 큰 문제입니다.

그때 무슨 일이 있었나. 대규모 이벤트 중 istiod가 20분 사이에 8대 재시작됐습니다. 커넥션 수(pilot_xds) 기반 KEDA 스케일링이 이미 걸려 있었고 24대 → 38대 스케일아웃도 정상 동작한 상태였습니다. 원인은 두 겹이었습니다 — 커넥션 한 개의 무게가 클러스터 규모를 따라 변했고(0.66 → 1.95 MB/conn), 스케일아웃해도 커넥션이 재분배되지 않아 기존 파드가 246~294 conn을 혼자 떠안았습니다. 이 문서는 그 두 성질의 근거를 공식 문서·소스코드 수준까지 내려가 정리하고 손잡이별 트레이드오프를 표로 남깁니다.