Egress Gateway 리소스 관리 모델
exportTo 중앙 관리와 목적별 Service 분리

요약 — 두 개의 결정

1. egress 관련 CR(ServiceEntry·VirtualService·DestinationRule·Gateway)은 istio-egress에 한 벌만 둔다. 소비 네임스페이스는 세 객체의 exportTo 리스트에 이름을 추가하는 것으로 연결되며, 그 리스트가 곧 "누가 egress를 쓰는가"의 감사 가능한 계약이 된다.
2. egress gateway 파드는 하나의 Deployment로 유지하되, Service는 목적 단위로 분리한다. 분리의 기준은 포트 번호가 아니라 노출 범위(소비자 집합)가 다른 목적이다 — 분리와 exportTo 축소가 결합될 때만 Envoy 리소스가 실제로 줄어든다.

배경 — 문제의 정확한 정의

1.1 이 구성에 필요한 객체들

egress 경로는 sidecar → egress gateway(pod) → Squid(:3128, CONNECT 터널) 두 홉이고, 이를 성립시키려면 CR이 최소 네 종 필요합니다 — ServiceEntry(Squid 등재와 리스너 매칭), DestinationRule(홉 1 mTLS 발신), Gateway(수신 리스너), VirtualService(두 홉의 배선). 여기에 AuthorizationPolicy(신원 심사)와 gateway용 Service/Deployment까지 더하면 한 목적지를 잇는 데 예닐곱 개의 객체가 움직입니다. 문제는 이 세트를 누가, 어디에, 몇 벌 두느냐입니다.

1.2 개별 CR 반복 생성의 문제 — 구체적으로

각 앱 네임스페이스가 자기 사본을 만드는 분산 모델(네임스페이스 40개 기준)의 실제 사고 형태입니다:

1.3 "리소스 포화"의 리소스란 정확히 무엇인가

막연히 "리소스"라 부르는 것의 실체는 istiod가 각 프록시에 xDS로 밀어넣는 Envoy 설정 객체입니다. 세 종류가 각각 다른 공식으로 증식합니다:

그리고 이 per-proxy 양에 × 그것이 보이는 프록시 수가 곱해진 것이 istiod의 유지·푸시 비용입니다. 변경(파드 롤링, 포트 추가)이 일어날 때마다 이 곱만큼의 갱신이 mesh를 흐릅니다. 쿠버네티스 쪽에도 대응물이 있습니다 — Service마다 EndpointSlice 세트가 있고, Service의 어떤 변경(포트 하나 추가)도 그 Service의 모든 슬라이스 갱신 → 모든 워처(kube-proxy·istiod)의 재계산을 유발합니다.

예시 — fat Service의 계산

egressgateway 파드 6개에 목적이 뒤섞인 포트 8개(3128, 8888, 443, 5432, 3306, 6379, 9092, 587)를 하나의 Service로 노출하고 mesh의 sidecar 400개 전부가 보는 경우:

per-proxy:  cluster  +8         (포트마다 outbound|PORT||egressgateway…)
            EDS 항목 +48        (8 포트 × 6 파드)
            listener +8
mesh 전체:  istiod가 유지·푸시하는 EDS 항목  = 48 × 400 = 19,200
변경 파급:  gateway 파드 1회 롤링  → 8개 cluster의 EDS 갱신이 400개 프록시 전부에게
            DB 포트 1개 추가       → DB와 무관한 400개 프록시 전원이 Service 갱신을 수신

모델 1 · exportTo 중앙 관리

2.1 모델 정의

egress 관련 CR 한 벌을 istio-egress에만 두고, 소비는 세 객체(SE·VS·DR)의 exportTo 리스트로 제어합니다. 앱 네임스페이스에는 아무 CR도 생기지 않습니다 — 연결은 리스트에 이름을 추가하는 PR 하나입니다.

# istio-egress에만 존재하는 한 벌 — 세 객체의 exportTo는 항상 동일 리스트
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata: {name: squid-gw, namespace: istio-egress}
spec:
  hosts: ["squid.gw-zone.example"]
  addresses: ["<SQUID_VIP_1>/32", "<SQUID_VIP_2>/32"]
  ports: [{number: 3128, name: tcp-squid, protocol: TCP}]
  location: MESH_EXTERNAL
  resolution: DNS
  exportTo: [".", "payments", "settlement"]     # "."=gateway 자신(불변 멤버)
# VirtualService·DestinationRule에도 같은 리스트 — kustomize patch로 3객체 동시 강제

2.2 왜 이것이 정석인가 — 공식 근거

이 모델은 관습이 아니라 Istio가 설계한 두 방향의 가시성 통제 중 한쪽을 그대로 쓰는 것입니다. 공식 Configuration Scoping 문서의 정의가 정확히 이 구도입니다:

• exportTo = 공급자의 통제 — "설정을 특정 워크로드 집합에만 내보내는 메커니즘"이며, Sidecar 리소스(소비자가 자기 의존성을 통제)와 정확히 반대 방향의 쌍으로 명시되어 있습니다. 우리는 egress라는 공급자측 설정을 다루므로 exportTo가 맞는 축입니다.
• gateway도 exportTo를 존중 — 공식 문서 명시. exportTo 리스트가 gateway 소비(".")와 앱 소비(나열)를 하나의 메커니즘으로 다룰 수 있는 근거입니다.
• 일급 설계의 증거 — meshConfig에 defaultServiceExportTo / defaultVirtualServiceExportTo / defaultDestinationRuleExportTo(기본값 "*")가 존재합니다. "기본 전체 공개를 뒤집을 수 있는 전역 스위치"가 코어에 있다는 것 자체가, 가시성 축소가 의도된 운영 모델이라는 뜻입니다.
• 스케일 문서의 일관된 권고 — 대규모 mesh 운영 자료들은 설정 전파 범위 축소(exportTo + Sidecar)를 프록시 메모리·푸시 시간 절감의 1순위 수단으로 권고합니다 (per-proxy 설정 70~90% 축소 사례 보고).

2.3 중앙 vs 분산 — 정직한 비교

규제 환경(PCI)의 결정 가중치는 감사 가능성과 권한 최소화에 있으므로 중앙 모델을 채택합니다. 분산의 유일한 실질 장점(팀 속도)은 "리스트 추가 PR"의 승인 SLA로 흡수합니다.

2.4 운영 규칙

• 세 객체 동일 리스트 — SE·VS·DR의 exportTo가 어긋나면 각각 차단 / 조용한 직행 / reset이라는 서로 다른 부분 장애가 됩니다(선행 문서 4.7의 매트릭스). kustomize에서 세 객체에 같은 patch를 묶어 구조적으로 강제합니다.
• "."은 불변 멤버 — egressgateway 자신이 SE의 두 번째 소비자(홉 2 클러스터)이기 때문입니다. 빠지면 "mTLS 성공 직후 끊김" 시그니처.
• 확대·롤백의 의미 변화 — 노드 ACL 제거 전에는 리스트 제외 = 원래 경로로 안전 복귀, 제거 후에는 = 그 네임스페이스 외부 통신 중단. 확대의 비가역점이 ACL 제거와 묶여 있음을 리스트 PR 템플릿에 명시합니다.

모델 2 · 목적별 Service 분리 — 포화 예방

3.1 원리 — Service는 selector일 뿐이다

쿠버네티스 Service는 파드의 소유물이 아니라 파드를 가리키는 독립 객체입니다. 같은 selector를 가진 Service를 몇 개 만들든 전부 같은 egressgateway 파드들을 가리키고, 파드는 아무것도 모릅니다. 새 목적의 수신 포트가 필요하면 Gateway CR에 server를 추가하는데, 이는 xDS로 gateway Envoy에 핫 반영됩니다(리스너 추가에 재시작 불요, Deployment의 containerPort 선언은 정보성이라 무변경). 즉 파드 재생성 없이 Service와 Gateway server만으로 목적을 증설할 수 있고, 이것이 이 모델의 전제입니다.

3.2 분리 기준 — 포트가 아니라 "노출 범위가 다른 목적"

1.3의 정직한 명제를 다시 소환하면: 분리 단독으로는 총량이 안 줄고, 분리가 목적별 exportTo를 가능하게 만들 때 줄어듭니다. 따라서 분리 단위의 판정 기준은 하나입니다 — 이 포트들의 소비자 집합이 서로 다른가? 소비자가 같은 포트들은 한 Service에 묶어도 손해가 없고, 소비자가 다른 포트를 한 Service에 묶는 순간 좁은 쪽이 넓은 쪽의 노출을 강제로 물려받습니다. 쿠버네티스 Service의 노출은 Istio 주석 networking.istio.io/exportTo로 제어합니다(Service에는 spec 필드가 없음).

3.3 구성 예시

# 같은 selector — 전부 동일한 egressgateway 파드를 가리킴
apiVersion: v1
kind: Service
metadata:
  name: egressgw-squid
  namespace: istio-egress
  annotations:
    networking.istio.io/exportTo: "payments,settlement,fraud"   # Service의 노출 제어는 주석
spec:
  selector: {istio: egressgateway}
  ports:
  - {name: tls-squid, port: 7777, targetPort: 7777}
---
apiVersion: v1
kind: Service
metadata:
  name: egressgw-db
  namespace: istio-egress
  annotations:
    networking.istio.io/exportTo: "billing,ledger,dw,ml-batch"
spec:
  selector: {istio: egressgateway}                              # 같은 파드
  ports:
  - {name: tls-db-pg, port: 7791, targetPort: 7791}
  - {name: tls-db-my, port: 7792, targetPort: 7792}
# Gateway CR에 목적별 server(7777/7791/7792)를 추가 — gateway Envoy에 핫 반영
# 각 목적의 SE·VS·DR exportTo 리스트는 해당 Service 주석과 동일하게 유지

3.4 효과 — 같은 예시의 재계산

수치는 예시 규모(sidecar 400 · 파드 6 · 포트 8)의 산술이며, 요점은 절대값이 아니라 변경 파급의 분모가 "전원"에서 "해당 목적의 소비자"로 바뀐다는 구조입니다.

3.5 한계와 주의

• 과분리 경계 — Service도 공짜가 아닙니다(목적마다 EndpointSlice 세트, 소비자 sidecar의 cluster). 소비자 집합이 같은 포트를 쪼개는 것은 객체 수만 늘립니다. 기준은 언제나 "노출 범위가 다른가"입니다.
• gateway 파드 자신의 설정은 별개 축 — 공식 문서가 명시하듯 gateway 프록시에는 cluster 설정 일부가 참조 여부와 무관하게 전 범위로 전송됩니다. 이 문서의 절감 대상은 앱 sidecar들이며, gateway 파드의 config 크기는 Sidecar 리소스가 아니라 gateway 전용 최적화의 영역입니다.
• 포트 이름 규약 — Service 포트 이름의 프로토콜 접두(tcp-, tls-)가 Istio의 프로토콜 판정 입력입니다. 목적별 Service는 이 명명을 목적 단위로 명확하게 만들어 주는 부수 효과가 있습니다.
• 보안 통제가 아님 — exportTo(주석 포함)는 가시성이며, 실제 차단은 AuthorizationPolicy(to.ports 목적별)·Calico·방화벽의 일입니다. 목적별 포트는 그 정책들의 좌표가 되어 줍니다.

도입 절차와 측정

1. 현재 상태 측정 (기준선): 대표 sidecar에서

   istioctl proxy-config clusters <pod> | wc -l
   istioctl proxy-config listeners <pod> | wc -l
   kubectl exec <pod> -c istio-proxy -- pilot-agent request GET config_dump | wc -c   # config 크기
   istioctl proxy-status | head    # 푸시 동기화 상태

2. istio-egress에 CR 한 벌 정리 — 기존 분산 사본이 있다면 중앙 벌 생성 → exportTo에 해당 ns 추가 → 사본 삭제 순으로 네임스페이스별 이관 (동시 존재 구간에서 같은 host 중복이 생기므로 istioctl analyze로 충돌 감시, 이관은 ns 단위로 짧게).
3. 목적별 Service·Gateway server 구성 — 기존 fat Service가 있다면 새 목적 Service를 병행 생성 → 소비자를 VS destination 전환 → fat Service 축소 (파드 무변경이므로 트래픽 전환은 라우팅 객체만의 일).
4. 사후 측정 — 1의 커맨드 재실행으로 per-proxy cluster/listener 수·config 크기 감소를 기록. istioctl proxy-config endpoints <pod> | grep egressgw로 목적 몫만 남았는지 확인.
5. CI 게이트 — exportTo 네 곳 동일성 검사 스크립트 + istioctl analyze를 리스트 변경 PR의 필수 체크로.

참고 자료

• Istio 공식 · Configuration Scoping — exportTo(공급자측)와 Sidecar(소비자측)의 대칭 정의, gateway의 exportTo 존중, 스케일 목적의 범위 축소 권고.
  istio.io/latest/docs/ops/configuration/mesh/configuration-scoping/
• Istio 공식 · Sidecar reference — "configuration scoping은 불필요한 설정을 제거해 mesh 확장성을 개선"한다는 명시.
  istio.io/latest/docs/reference/config/networking/sidecar/
• Istio 소스 · mesh 기본값 — DefaultServiceExportTo / DefaultVirtualServiceExportTo / DefaultDestinationRuleExportTo = ["*"]의 존재.
  github.com/istio/istio — pkg/config/mesh/mesh.go
• Tetrate · Service Mesh Best Practices — default*ExportTo를 "."로 좁히고 네임스페이스별 Sidecar를 관리하는 운영 권고.
  tetrate.io/blog/optimize-traffic-management…
• Google Cloud Community · 중앙 스코프 관리 — 멀티테넌트 클러스터에서 Istio 리소스 스코프를 중앙 통제하는 접근.
  medium.com/google-cloud/centrally-manage-the-scope…
• 대규모 운영 사례 — 설정 범위 축소를 1순위 최적화로 꼽는 스케일 자료들 (American Express Technology 블로그, 대형 mesh 튜닝 가이드류: per-proxy 설정 70~90% 축소 보고).
  americanexpress.io/optimizing-istio-for-large-scale…