Skip to Content
← 전체 글로 돌아가기

Istio

Istio 데이터플레인과 컨트롤플레인을 운영하며 마주친 문제들 — 스케일링 지표를 어느 지점에서 세는지부터 istiod 자체의 스케일링까지.

총 2편

카테고리 전체 보기 →
istiod 스케일링, 커넥션 수만 세면 될 줄 알았다지난 글에서는 트래픽을 받는 서비스 쪽 스케일링 지표를 다뤘습니다. reporter 관점 하나 차이로, 오토스케일링이 장애를 트래픽 감소로 읽어버리던 이야기였죠.Istio오토스케일링KEDA메트릭왜 트래픽은 받았지만 스케일링은 못 했을까?트래픽이 몰리는 날에는 보통 미리 Pod들을 준비해둡니다. 몰려올 부하를 충분히 버티기 위한 단계, pre-warming입니다.Istio오토스케일링메트릭트러블슈팅

Istio·트러블슈팅·메트릭·오토스케일링 겹침

마지막 setWeight: 100을 왜 지워야 하는가2부의 사고에서는 rollbackWindow로 step을 건너뛴 뒤, 컨트롤러가 역탐색으로 마지막 weight 100을 선택했습니다.Kubernetes · 태그 2개rollbackWindow는 왜 그 안전장치를 깨는가2026-08-21, prod에서 이전 버전으로 롤백하던 중 파드 2대에 트래픽 100%가 몰렸습니다.Kubernetes · 태그 2개정상 Canary는 왜 안전한가: step과 AnalysisRun새 버전의 파드가 Ready라고 해서 서비스도 정상이라고 볼 수 있을까요?Kubernetes · 태그 2개좀 더 똑똑하게 consolidation하기 — Balanced 모드Karpenter consolidation은 무엇을 하는가에서 이어집니다.Karpenter · 태그 2개