Sidecar on homelab89

Egress route 스코핑 — `metadata.namespace`는 적용 범위가 아니다

Tue, 09 Jun 2026 00:00:00 +0000

ABSTRACT

Istio traffic 리소스의 metadata.namespace는 “어디에 저장했는가"(소유 경계)이지 “어느 proxy에 적용되는가"(적용 범위)가 아니다. 적용 범위는 gateways · exportTo · sourceNamespace/sourceLabels · Sidecar.egress.hosts 네 레버의 직교 조합으로 따로 결정된다. 이 분리를 모르면 egress 설정이 다른 namespace sidecar로 새거나(전역 누수), gateway가 필요한 route를 못 본다. egress gateway를 여러 개(passthrough용 / mTLS용) 두는 순간 스코핑은 선택이 아니라 전제가 된다.

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 운영 가이드 참조.

Sidecar 트래픽 캡처 — iptables/nftables와 15001·15006

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

이 문서가 다루는 것

mesh의 모든 기능(mTLS·route·authz·telemetry)은 “app의 모든 패킷이 Envoy를 지나간다"는 단 하나의 전제 위에 서 있다. 그 전제를 app 코드 수정 없이 강제하는 장치가 커널 netfilter(iptables/nftables) redirection이다. 이 문서는 그 redirection을 — 왜 필요한지(배경)부터, 누가 어떻게 rule을 거는지(pilot-agent istio-iptables → IptablesConfigurator.Run → iptables-restore --noflush), REDIRECT mode의 핵심 체인과 proxy UID/GID 1337 무한 루프 방지 불변식, 실제 *nat 블록·--dry-run·native nftables 경로·검증 명령까지 — 한 줄기로 따라간다. 결론: app은 평소처럼 service:port로 connect하지만 모든 트래픽이 app 모르게 투명하게 Envoy를 통과한다.