Istio Sidecar CRD 적용 범위(scope) 설정 방법

Sun, 07 Jun 2026 00:00:00 +0000

ABSTRACT

Sidecar 리소스는 한 워크로드 Envoy가 받는 설정을 좁혀 config를 경량화하고, outboundTrafficPolicy와 결합해 egress 거버넌스를 만든다. 멘탈모델 하나: scope는 Mesh / Namespace / Workload 세 단계지만 어느 Pod에든 적용되는 Sidecar는 정확히 하나 — 가장 좁은 것이 통째로 이긴다(merge 아님, override). 이 문서는 그 override 의미론을 세 scope의 **완전한 YAML(주석 포함)**로 따라 만들고, REGISTRY_ONLY 차단을 실측으로 굳힌다. 개념 전반은 Sidecar scope 개념 노트에.

Sidecar 리소스는 '좁은 범위가 넓은 범위를 통째로 이기는' override 계층으로, 사이드카에 푸시할 설정을 좁혀 성능과 egress 거버넌스를 동시에 얻는다

Sun, 07 Jun 2026 00:00:00 +0000

ABSTRACT

Istio의 기본 가정은 “메시 안 모든 워크로드가 다른 모든 워크로드에 접근 가능"이다. 그래서 istiod는 각 Envoy에 메시 전체 설정을 푸시하고, 규모가 커지면 이것이 메모리·xDS push·istiod CPU를 동시에 압박한다. Sidecar 리소스는 두 개의 서로 다른 레버로 이를 푼다 — egress.hosts(이 워크로드가 알아야 할 설정의 범위를 축소 → 성능)와 outboundTrafficPolicy(레지스트리 밖 트래픽의 차단 정책 → 거버넌스). 이 문서가 세우려는 단 하나의 멘탈모델: 세 scope(Mesh / Namespace / Workload)는 merge가 아니라 가장 좁은 하나가 통째로 이기는 override 의미론이다. 운영 detail·YAML 전문은 Sidecar scope 운영 가이드 참조.

Scope on homelab89

Istio Sidecar CRD 적용 범위(scope) 설정 방법

Sidecar 리소스는 '좁은 범위가 넓은 범위를 통째로 이기는' override 계층으로, 사이드카에 푸시할 설정을 좁혀 성능과 egress 거버넌스를 동시에 얻는다