Ops Insights – Istio

서비스 메시와 Istio 기초

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

01 · 서비스 메시와 Istio 기초 — 왜 EKS에 메시를 얹나

서비스 메시 = 데이터 플레인(파드마다 붙는 Envoy 사이드카) + 컨트롤 플레인(istiod). 이 분리가 챕터 전체의 뼈대입니다.
사이드카는 iptables로 트래픽을 가로채 앱 코드를 그대로 둔 채 mTLS·라우팅·재시도·관측성을 더합니다.
메시는 공짜가 아닙니다 — 프록시 오버헤드·컨트롤 플레인 부하·설정 복잡도·디버깅 난이도라는 네 비용을 집니다.
Ambient 모드(사이드카리스, ztunnel+waypoint)는 이 비용을 줄이려는 후속 설계지만, 이 챕터는 사이드카 모드 운영을 전제로 합니다.

02~05는 메시를 운영하며 겪은 사건의 기록입니다. 그 기록이 읽히려면 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지를 먼저 잡아야 합니다. 이 문서는 서비스 메시의 두 축(데이터 플레인·컨트롤 플레인), 메시가 해주는 것, 그 비용을 다룹니다.

왜 Ambient mode인가

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

01 · 왜 Istio Ambient mode인가 — 사이드카를 건너뛴 선택 (2026-03)

참조한 내용정리 · 이 문서는 아래 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

Envoy config로 해부하는 Ambient mode

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

02 · Envoy config로 해부하는 Ambient mode — HBONE은 어떤 설정으로 만들어지는가 (2026-04)

컨트롤 플레인 해부: istiod

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

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를 먹는 메커니즘, 언제 증설해야 하는지 알려주는 지표, 증설 말고 진짜 해법을 정리합니다.

3-1편 — 503과 Half-open Connection

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

03-1 · 503과 Half-open Connection — waypoint가 죽은 Pod의 커넥션을 재사용한다 (2026-06)

데이터 플레인과 Ingress Gateway

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

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

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

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

3-2편 — Partially Enrolled Pod와 Untaint Controller

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

03-2 · Partially Enrolled Pod와 Untaint Controller — istio-cni보다 먼저 뜬 Pod (2026-07)

참조한 내용정리 · 이 문서는 아래 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며, 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

설정을 코드로: GitOps

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

04 · 설정을 코드로 — Istio Manifest를 Git으로 동기화하기

Istio 설정은 두 층입니다 — 설치 층(Helm 권장, IstioOperator는 지양)과 트래픽 층(전부 CRD).
메시 CRD는 적용하는 순간 트래픽에 직결됩니다. 손 apply가 남기는 드리프트·추적불가·재현불가가 그대로 장애 위험이 됩니다.
GitOps(Argo CD/Flux)로 Git을 단일 진실로 정해 드리프트를 자동 복원하고 istioctl analyze로 적용 전에 검증합니다.
컨트롤 플레인 업그레이드는 revision 기반 카나리로 폭발 반경을 줄입니다.

그때 무슨 일이 있었나. IstioOperator/Helm 값, Gateway, VirtualService, DestinationRule — 메시 설정 일체를 그때그때 kubectl apply로 손봤습니다. 클러스터의 실제 상태와 Git 저장소는 거기서부터 어긋나기 시작했습니다. 누가 언제 무엇을 바꿨는지 기록이 남지 않았고 재현도 롤백도 불안했습니다. “Istio Manifest Sync” 과제는 이 드리프트를 없애고 Git을 단일 진실로 만드는 일이었습니다. 이 문서에서는 Istio 설정 방식, GitOps로 옮기는 이유, 메시 설정 특유의 위험을 다룹니다.

3-3편 — Ambient 안전하게 업그레이드하기

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

03-3 · Ambient mode 안전하게 업그레이드하기 — istiod → istio-cni → ztunnel, 그리고 ztunnel만은 node pool blue-green (2026-07)

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

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

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입니다.

507과 istiod disconnected 탐지

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

03-4 · 507 status code와 istiod disconnected 탐지 — 부록으로 남긴 두 사례 (2026-07)

메시가 공짜로 주는 관측성

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

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

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

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

EnvoyFilter — 표준 CRD의 탈출구

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

08 · EnvoyFilter — 표준 CRD로 안 되는 것들의 탈출구

EnvoyFilter는 istiod가 만든 Envoy 설정을 직접 패치하는 저수준 탈출구입니다 — applyTo × context × operation으로 읽습니다.
업그레이드에 취약하고 폭발 반경이 크고 리뷰가 어려워 최후의 수단입니다. 표준 CRD → 상위 API(Telemetry/WasmPlugin) → EnvoyFilter 순으로 고릅니다.
레이트 리밋은 local(인스턴스별·무의존)과 global(전역정확·RLS 비용)로 성격이 다릅니다.
쓴다면 workloadSelector로 좁게, 버전 핀·GitOps 리뷰·관측이 필수입니다.

07의 표준 CRD로 대부분은 해결됩니다. 남는 것은 정교한 레이트 리밋, 특정 Envoy HTTP 필터 삽입, 커스텀 요청 조작처럼 VirtualService·AuthorizationPolicy의 어휘로는 표현 안 되는 요구입니다. 그때 열리는 마지막 문이 EnvoyFilter — istiod가 생성한 Envoy 설정을 직접 패치하는 저수준 탈출구입니다. 강력한 만큼 위험하므로 이 문서는 무엇을 할 수 있는지만큼 왜 최후의 수단인지를 함께 다룹니다.

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

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

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을 혼자 떠안았습니다. 이 문서는 그 두 성질의 근거를 공식 문서·소스코드 수준까지 내려가 정리하고 손잡이별 트레이드오프를 표로 남깁니다.

Ambient 이행 심사

Tue, 28 Jul 2026 00:00:00 +0000

10 · Ambient 이행 심사 — 01~09를 다시 심사한다면 무엇이 무효가 되나

하위 섹션 Ambient mode 도입기는 사이드카를 아예 거치지 않은 팀의 기록이라 버리고 오는 쪽의 비용이 빠져 있습니다. 이 문서가 그 칸을 우리 01~09에 되물어 채웁니다.
가장 확실하게 무효가 되는 자산은 EnvoyFilter(08)입니다. ztunnel은 Envoy가 아니고 waypoint는 Envoy지만 EnvoyFilter가 공식 미지원·비권장입니다.
02의 가장 큰 레버였던 Sidecar 리소스는 waypoint의 destination 지향 스코프로 대체됩니다. 레버 자체는 남고 손잡이 모양만 바뀝니다.
06의 대시보드는 메트릭 이름은 살고 reporter 라벨이 달라집니다. waypoint가 없는 구간에서는 HTTP 메트릭 자체가 나오지 않습니다.
L7 정책이 걸린 워크로드에는 무중단 마이그레이션 경로가 없다고 공식 가이드가 명시합니다. 이 문장 하나가 전환 대상 선정 기준을 거의 다 정합니다.

전제는 이렇습니다. 우리 01~09(Sidecar mode 운영기)를 읽었고 하위 섹션 Ambient mode 도입기(채널코퍼레이션의 그린필드 도입 기록)도 읽었습니다. 이 문서가 다루는 것은 그 둘 사이에 빠진 칸 하나뿐입니다 — 이미 사이드카를 운영 중인 팀이 Ambient로 넘어갈 때 다시 심사해야 할 것. 결론 대신 질문을 세는 문서입니다. 각 절은 무엇이 바뀌나 → 우리가 심사할 것 → 열린 질문 순으로 갑니다.

요청 경로 해부

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

11 · 요청 경로 해부 — 요청 하나가 지나는 길과, 그 길을 만드는 배선

istiod는 요청 경로 위에 없습니다. 파드 안의 istio-agent가 부트스트랩·인증서·xDS를 모두 중계하고 Envoy는 istiod에 직접 연결하지 않습니다.
남북 경로에서 클라우드 LB는 L4로만 넘깁니다. 요청이 처음 L7이 되는 곳은 게이트웨이 Envoy이고 거기서 TLS가 끝나고 VirtualService 라우트가 걸립니다.
동서 경로는 iptables가 아웃바운드를 :15001, 인바운드를 :15006으로 꺾습니다. 프로토콜을 판별하지 못하면 평문 TCP로 취급되어 L7 기능이 통째로 사라집니다.
L7 파싱 지점이 곧 메트릭·재시도·라우팅이 생기는 지점입니다. 게이트웨이를 경유하는 메시 내부 호출이면 한 요청에 그런 곳이 세 곳 생깁니다.
게이트웨이와 사이드카는 같은 부품입니다 — 같은 Envoy, 같은 istio-agent, 같은 포트 규약.

01은 메시가 두 평면으로 갈린다는 것을, 02는 istiod가 왜 CPU를 먹는지를, 03은 게이트웨이를 왜 노드로 격리하는지를 다뤘습니다. 셋 다 맞는 얘기지만 따로 읽으면 **“그래서 요청 하나가 실제로 어디를 지나는가”**가 남지 않습니다. 이 문서는 그 조각들을 클라이언트에서 앱까지의 경로라는 하나의 축 위에 다시 배치합니다. 각 조각의 깊은 설명은 해당 문서로 넘기고 여기서는 경로와 접점만 봅니다.

Envoy가 제공하는 것

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

12 · Envoy가 제공하는 것 — Istio를 걷어내고 프록시 하나만 본다

Envoy는 앱에 링크되는 라이브러리가 아니라 앱 옆에서 따로 도는 프로세스입니다. 그래서 언어를 가리지 않습니다. 공식 홈페이지의 자기 정의가 “universal data plane"입니다.
코어는 L3/L4 프록시 + 꽂아 넣는 필터 체인이고 HTTP는 그 위에 놓인 L7 필터 레이어입니다. 모델은 listener → 필터 체인 → route → cluster → endpoint 하나로 끝납니다.
재시도·서킷 브레이킹·아웃라이어 감지·헬스체크·로드밸런싱은 전부 Envoy에 이미 있는 기능입니다. Istio CRD는 그 스위치를 밖으로 꺼낸 창구입니다.
관측성 세 축도 Envoy가 생산합니다. 특히 트레이싱에서 Envoy는 헤더만 넘기는 게 아니라 스팬을 직접 만들어 수집기로 보냅니다.
xDS는 Envoy 프로젝트가 정의한 API이고 istiod는 그 관리 서버 구현 중 하나입니다.

지금까지 이 챕터에서 Envoy는 늘 Istio의 부품이었습니다. 01에서는 파드에 붙는 사이드카였습니다. 02에서는 xDS를 받아가는 대상이었고 08에서는 EnvoyFilter가 패치하는 설정 덩어리였습니다. 이 문서는 그 방향을 뒤집습니다 — Istio를 걷어낸 Envoy 자체의 기능 카탈로그, 즉 조립되기 전의 부품이 원래 무엇을 할 수 있는가입니다. 조립 이야기는 13으로 넘깁니다.

Istio의 Envoy 조립

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

13 · Istio의 Envoy 조립 — proxyv2 이미지부터 CRD 번역까지

proxyv2에는 바이너리가 둘 들어 있고(Envoy · pilot-agent), 그 Envoy조차 upstream 그대로가 아닙니다 — istio/proxy가 확장을 함께 컴파일해 만든 빌드입니다.
istio_requests_total과 source_*/destination_* 라벨은 프록시 안에 컴파일된 확장이 만듭니다. 컨트롤 플레인은 관여하지 않습니다. Mixer가 사라졌다는 말의 실질이 여기 있습니다.
CRD는 xDS 리소스로 번역됩니다 — VirtualService→route, DestinationRule→cluster, Gateway→listener. 번역 결과는 추측하지 말고 istioctl proxy-config로 봅니다.
Istio 빌드는 Envoy의 특정 커밋에 pin됩니다. 사이드카 업그레이드가 곧 Envoy 업그레이드입니다. 그 버전은 릴리스 노트가 아니라 파드에 물어봐야 압니다.
이미지에 박힌 내장 확장과 CRD로 추가하는 사용자 확장(08)은 바꾸는 방법이 다릅니다. 전자는 이미지 교체로만, 후자는 설정으로.

“Istio는 Envoy를 쓴다"는 문장은 어디에나 있지만 ‘쓴다’가 무엇인지는 잘 안 적혀 있습니다. 12가 Envoy 자체의 능력을 훑었다면, 이 문서는 그 위에 Istio가 무엇을 더했는지를 봅니다. 층이 둘입니다. 아래층은 컴파일 시점 — Istio는 upstream Envoy 바이너리를 받아 쓰지 않고 자기 확장을 넣어 다시 빌드합니다. 위층은 런타임 — istiod가 CRD를 Envoy 설정으로 번역해 xDS로 내려보냅니다.

왜 서비스 메시인가

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

14 · 왜 서비스 메시인가 — 대안 스펙트럼과 손익 분석

고를 것은 기능이 아니라 배치입니다 — 재시도·타임아웃·mTLS·관측이라는 공통 관심사를 앱 안에 둘 것인가, 앱 밖 프록시에 둘 것인가, 그 프록시를 파드마다 둘 것인가 노드마다 둘 것인가.
후보는 넷(라이브러리 · 게이트웨이만 · 사이드카 메시 · ambient)이고 넷을 구분하는 축도 넷입니다: 커버 범위 · 언어 의존 · 업그레이드 결합 · 운영 비용.
메시가 이기는 조건은 서비스 수 × 언어 수가 크고 정책을 일괄로 바꿔야 할 때입니다. 우리 챕터에서 그 증거는 [06]·[07]·[05]에 실물로 남아 있습니다.
청구서에는 공식 수치가 있습니다 — 벤치마크 조건에서 사이드카 하나가 약 0.20 vCPU · 60 MB, 그리고 데이터 경로에 프록시가 붙는 만큼의 지연.
메시는 재시도·서킷브레이커까지 대신해주지만 폴백은 앱 몫입니다. 이 경계는 공식 문서가 직접 명시합니다.

이 문서의 자리를 먼저 짚습니다. 01 메시 기초가 답한 질문은 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지였습니다 — 두 개의 플레인, iptables 가로채기, 네 가지 비용. 그건 메커니즘입니다. 이 문서는 그 앞에 오는 질문을 다룹니다: 같은 문제를 푸는 다른 방법과 비교했을 때 메시가 이기는 조건은 무엇이고 지는 조건은 무엇인가. 01과 겹치는 서술은 링크로 넘기고 여기서는 판단에 필요한 것만 봅니다.

CRD 카탈로그와 연계

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

15 · CRD 카탈로그와 연계 — 14개 리소스가 서로를 참조하는 축

우리 클러스터에 깔린 Istio CRD는 14개, 그룹은 networking · security · telemetry · extensions 넷입니다.
리소스는 혼자 동작하지 않습니다. 트래픽 축은 Gateway → VirtualService → DestinationRule → 엔드포인트로 이름과 라벨을 타고 이어집니다. 사슬이 끊기는 곳이 곧 장애 지점입니다.
보안 축의 함정 둘: PeerAuthentication(수신)과 DestinationRule tls(송신)가 어긋나면 503이 납니다. RequestAuthentication은 토큰 없는 요청을 거부하지 않습니다.
Sidecar·ProxyConfig·Telemetry는 트래픽 대신 프록시 자체를 조정하는 부류입니다.
버전 컬럼에 성숙도가 그대로 적혀 있습니다 — 대부분 v1인데 EnvoyFilter만 v1alpha3, WasmPlugin은 v1alpha1입니다.

13이 다룬 것은 4대 리소스가 Envoy 설정으로 번역되는 경로뿐입니다. 클러스터에 실제로 깔린 CRD는 14개입니다. 사고가 나는 곳은 리소스 하나의 필드보다 리소스와 리소스 사이인 경우가 많습니다 — VirtualService가 부르는 subset 이름이 DestinationRule에 없거나, PeerAuthentication과 DestinationRule의 TLS 모드가 어긋나거나, RequestAuthentication만 걸어 두고 인가를 빠뜨리거나. 이 문서는 14개를 사전처럼 나열하는 대신 참조 관계의 축으로 묶습니다.

1.20 → 1.24 — ambient가 실험에서 나온 구간

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

10 · 1.20 → 1.24 — ambient가 실험에서 나오고, 설치 경로가 바뀐다

이 구간에서 벌어진 일은 ambient가 alpha → Beta(1.22.0) → GA(1.24.0)로 올라간 것, 그리고 설치·관리 경로가 강제로 바뀐 것(in-cluster operator 폐기 1.23.0 → 제거 1.24.0, #52090)입니다. 앞의 것은 선택이지만 뒤의 것은 선택이 아닙니다 — sidecar를 유지하는 클러스터도 1.24 이상으로 가려면 그대로 맞습니다.
ambient GA는 sidecar의 폐기 신호가 아닙니다. 1.20~1.24 어느 upgrade-notes·change-notes에도 sidecar injection을 deprecated로 표시한 문구가 없고 최신 스냅샷 문서도 sidecar를 “thoroughly battle-tested"라며 두 개의 main data plane mode 중 하나로 나란히 둡니다. 우리 방침(ambient 금지)은 유효하고 이 구간 사실만으로는 재검토 트리거도 발생하지 않았습니다(§2.4).
제거된 것은 in-cluster 컨트롤러와 istio-operator 차트이고 IstioOperator API 타입은 1.30.0에도 살아 있습니다(operator/pkg/apis/types.go, install.istio.io/v1alpha1). istioctl install -f istio.yaml도 그대로 동작합니다 — “IstioOperator가 죽었다"는 요약은 틀렸습니다.
1.24.0에서 CRD가 Helm 템플릿으로 이동하고 base.enableCRDTemplates가 기본 true가 됩니다(#43204). CRD를 kubectl apply나 이전 helm install로 넣었다면 1.24 전에 1회 kubectl label/annotate로 Helm 소유권 이관을 해야 하고 ArgoCD가 만든 실제 Helm 릴리스명을 모르면 이 명령을 실행하면 안 됩니다.
sidecar 트래픽 동작을 바꾸는 플래그 7개가 1.24.0에 한꺼번에 들어오고 전부 기본 true입니다(§5.6) — ENABLE_INBOUND_RETRY_POLICY·EXCLUDE_UNSAFE_503_FROM_DEFAULT_RETRY·PILOT_UNIFIED_SIDECAR_SCOPE·ENABLE_ENHANCED_DESTINATIONRULE_MERGE·PREFER_DESTINATIONRULE_TLS_FOR_EXTERNAL_SERVICES·ENABLE_DEFERRED_STATS_CREATION·BYPASS_OVERLOAD_MANAGER_FOR_STATIC_LISTENERS. 이 7개가 compatibilityVersion=1.23 프로파일의 내용입니다.
1.21.0의 TLS 기본값 두 개가 egress를 끊을 수 있습니다. ENABLE_AUTO_SNI와 VERIFY_CERTIFICATE_AT_CLIENT가 함께 true가 되면서 caCertificates 없는 DestinationRule TLS 오리지네이션이 OS CA로 검증을 시작합니다. 사설 CA 대상은 그 순간 실패합니다.
istio.io 문서의 플래그명이 실제 env var와 다른 곳이 두 군데입니다. 1.21 upgrade-notes는 VERIFY_CERT_AT_CLIENT라 쓰지만 등록명은 VERIFY_CERTIFICATE_AT_CLIENT(pilot/pkg/features/pilot.go:239)고 1.22 upgrade-notes는 ENHANCED_RESOURCE_SCOPING이라 쓰지만 실제는 ENABLE_ENHANCED_RESOURCE_SCOPING(experimental.go:182)입니다. 문서를 복사해 env를 걸면 아무 일도 일어나지 않습니다.
1.23.0에 공개 upgrade-notes 페이지에 실리지 않은 메트릭 파괴 변경이 있습니다. ENABLE_DELIMITED_STATS_TAG_REGEX(기본 true, #52271)가 Envoy cluster 메트릭의 cluster_name·http_conn_manager_prefix 라벨 파싱을 바꿉니다. 근거는 릴리스노트 원본 releasenotes/notes/51761.yaml의 upgradeNote뿐입니다 — 대시보드가 경고 없이 깨지는 종류입니다.
1.22.0의 v1 승격은 “추가"이지 “이동"이 아닙니다. CRD가 v1·v1alpha3·v1beta1 셋을 모두 served로 제공하고 storage 버전은 1.22.0에 v1alpha3에서 v1beta1로 올라가 1.26.0까지 남습니다(1.27.0에서 v1로 이동). v1alpha3로 쓴 옛 매니페스트는 1.30.0 기준으로도 그대로 apply됩니다.
1.24 계열은 k8s ≤1.31까지입니다. 하한 가정(chart tip 1.24.1)이 k8s 1.33 위에서는 지원 대상 밖이라는 뜻이고 1.24는 2025-06-24에 EOL이라 compat profile로 버티는 선택지 자체가 이미 없습니다.

1.24를 하한으로 가정하고 1.30.3까지 올리는 계획에서 1.20~1.24는 “이미 지나온 구간"으로 취급되기 쉽습니다. 그런데 이 구간에는 지나왔는지 아닌지를 클러스터를 봐야 알 수 있는 항목이 셋 있습니다 — in-cluster operator를 쓰고 있는지, CRD의 Helm 소유권 이관을 했는지, 1.21의 TLS 기본값 전환에 egress가 걸렸는지. “1.24가 이미 떠 있다"는 사실만으로는 확인되지 않고 안 했으면 다음 홉에서 터집니다. 이 문서는 5개 마이너를 나열하는 대신 그 종류의 항목에만 지면을 줍니다.

1.25 → 1.30 — sidecar 운영자가 맞는 청구서

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

11 · 1.25 → 1.30 — ambient를 안 써도 피할 수 없는 변경들

이 구간의 최대 사건은 native sidecar 기본화(1.27.0)입니다. ambient가 아닙니다. istio-proxy가 일반 컨테이너를 떠나 init 컨테이너(restartPolicy: Always)가 되면서 파드 스펙·기동 순서·종료 순서·Job 완료 판정이 한꺼번에 달라집니다.
1.27 change-notes의 “default to true“는 틀렸습니다. 코드가 등록하는 기본값은 문자열 "auto"입니다(1.27.0 pilot/pkg/features/pilot.go:307, 직전 1.26.0은 experimental.go:179의 bool false). true면 무조건 활성이지만 "auto"는 노드 kubelet 버전 조건부라 판단이 완전히 달라집니다.
전환 시점은 노드 kubelet 버전이 정합니다. DetectNativeSidecar가 모든 Node를 훑어 kubelet 마이너가 하나라도 33 미만이면 끕니다(pkg/kube/inject/webhook.go:1235-1286, minVersion := 33). 1.30 + k8s 1.32 조합에서는 안 켜집니다. 목표인 k8s 1.35에서는 켜지고 green(k8s 1.31)에서는 끝까지 안 켜집니다.
green(k8s 1.31)에는 1.30을 설치할 수 없습니다 — 1.30의 k8s 하한이 1.32입니다. green에서 닿는 상한이 1.29(EOL ~2026-08)이니 목표 1.30.3은 k8s 1.35 신규 클러스터에서만 성립합니다(§1·§8).
holdApplicationUntilProxyStarts는 native가 켜지면 경고 한 줄 없이 무효가 됩니다. 템플릿이 $holdProxy := and (…hold…) (not $nativeSidecar)로 계산해 postStart: pilot-agent wait 훅을 렌더에서 빼고 그 자리에 preStop drain 훅을 놓습니다(1.30.3 injection-template.yaml:71-77,215-235). 값을 지우는 것은 조치가 아닙니다 — 남겨둬도 아무 일도 일어나지 않습니다.
사용자 init 컨테이너가 메시 안으로 들어옵니다. reorderPod는 classic에서 istio-init을 initContainers 마지막에(“iptables setup last so we do not blackhole init containers”), native에서 맨 앞에(“istio first, so init containers are part of the mesh”) 둡니다(webhook.go:805-825). init의 egress가 iptables·mTLS·AuthorizationPolicy 대상이 됩니다. 릴리스노트에 이 항목이 없습니다.
1.29 차트 통합의 이름 변경은 우리에게 해당 없을 가능성이 큽니다. upgrade-notes는 ClusterRole istiod → istiod-clusterrole 매핑표를 싣지만 로컬 클론의 istiod 차트는 1.22.0부터 이미 신 이름이고 base 차트 템플릿은 1.28.0↔1.30.3이 동일합니다. 체크리스트를 “rename 대응"에서 “구 이름 orphan 탐색"으로 바꿔야 합니다.
알람이 소리 없이 죽는 곳이 셋, 라우팅이 예고 없이 바뀌는 곳이 둘입니다 — 앞의 셋은 1.29의 서킷브레이커 remaining 메트릭 기본 비활성·stats 압축 기본 활성·디버그 엔드포인트 인증(15014→1.30의 15010), 뒤의 둘은 1.30의 동일 hostname 서비스 선택 로직 변경(PILOT_SIDECAR_PICK_BEST_SERVICE_NAMESPACE, 기본 true)과 retryBudget 기본 percent 0.2%→20% 수정(#59504, 100배 차이)입니다. 다섯 다 에러가 없습니다.
sidecar deprecate 신호는 이 구간에 없습니다. 1.30까지 어떤 공지·문서도 sidecar mode를 deprecated로 표시하지 않았고 native sidecar 기본화와 sidecar용 nftables 지원(1.27)은 sidecar 경로에 들인 투자입니다. 재검토 트리거는 §5에 다섯 개로 적어 뒀습니다. 판정은 native sidecar 검증·플래그/메트릭 grep·Gateway API CRD 확인·CVE 패치가 지금, stats 압축·디버그 엔드포인트 정리·seccompProfile이 다음 분기, nftables·TrafficExtension·agentgateway·ambient가 보류입니다.

왜 이 문서인가. 목표로 잡은 1.30.3이 이 구간의 끝입니다. 그러니 남의 릴리스노트를 요약하지 않고 우리 업그레이드가 반드시 통과할 변경만 적습니다. 헤드라인은 전부 ambient(멀티클러스터 beta, DNS 캡처 기본화, 마이그레이션 가이드 신설)이고 우리는 ambient를 안 쓰는데 그래도 못 넘어갈 것이 세 종류 남습니다 — ① 파드 스펙 자체를 바꾸는 것(native sidecar), ② 리소스 이름·차트 구조를 바꾸는 것(1.29 통합), ③ 플래그·메트릭 기본값을 바꿔 알람을 무효화하는 것. CI는 셋 중 어느 것도 못 잡습니다. ①의 렌더 결과는 유효한 yaml이고 ②에서 Helm은 에러를 안 냅니다. ③은 쿼리가 0을 리턴할 뿐입니다.

nginx에서 Istio로

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

07 · nginx에서 Istio로 — rewrite·헤더·인가는 어디로 갔나

한눈에