필요한 이유

- 기본 상태에서 istiod는 etcd 변경을 감지할 때마다 클러스터 전체 서비스 설정을 모든 Envoy에   push

- 각 Envoy는 실제로 통신하지 않는 서비스 설정까지 전부 메모리에 보유하게 됨

- 클러스터가 커질수록 Envoy 메모리가 선형으로 증가

- 심하면 OOMKiled나 connection drop까지 이어짐

동작 원리

[ 한 줄 ]
- Sidecar 리소스로 각 Envoy가 받을 "xDS 설정의 범위를 제한"

[ 적용 전 후 ]
적용 전 - 클러스터 전체 서비스 설정 -> 모든 Envoy에 push
적용 후 - Sidecar hosts에 명시된 서비스 설정만 -> 해당 Envoy에 push

[ 적용 ]
- istiod(xDS Server)가 PushContext를 만들 때 Sidecar 리소스를 참조해서, 각 Envoy에 필요한   설정만 골라서 보내는 구조

설정 방법

기본 정책(네임스페이스 전체 적용) - Groom Project

apiVersion: networking.istio.io/v1beata1
kind: Sidecar
metadata:
	name: default
	namespace: prod # prod NS 전체에 적용
spec:
	egress:
	- hosts:
		- "./*"                                      # 같은 ns
    - "courm-kafka/*"                            # Kafka
    - "monitoring/*"                             # OTel
    - "istio-system/*"                           # Gateway

xDS 관점에서 줄어드는 것

[ 사라지는 것 ]
- Sidecar hosts에서 제외된 서비스는 해당 Envoy의 CDS/EDS에서 사라짐

[ EX. prod 5개, monitoring 5개, infra 3개 서비스 존재 ]
- 적용 전. order-service Envoy
		- CDS/EDS: prod(5) + monitoring(5) + infra(3) = 13개 서비스 설정 보유
- 적용 후. order-service Envoy
		- CDS/EDS: prod(5) + istio-system = 5개 서비스 설정만 보유

xDS 리소스가 없으면 생기는 일

[ 설명 ]
- service discovery를 "제외"한다는 건 단순히 목록에서 숨김이 아닌, "대상의 xDS 리소스 자체   가 Envoy에 거의 안 내려간다는 의미"
- 이로써, Envoy는 아래와 같은 정보를 갖지 못함.
		1. 그 서비스로 보낼 "cluster/CDS 정보"
		2. 실제 pod endpoint 목록인 "EDS 정보"
		3. 그 호스트에 매칭되는 "route/RDS 정보"
	=> 이와 같은 정보가 빠져 결과적으로 "그 서비스에 대한 메시 내부 통신 기능이 빠짐"