Istio Architecture

Istiod

[ Pilot - 3총사 ]
	1. Config Controller
		- Istio CR(VirtualService, DestinationRule, Gateway 등)을 "watch"해서 변경 감지하고,
			"Pilot 내부 모델"로 변환
		- "스키마 검증 + 변환"까지 여기서 다 처리
		- 예전 Galley가 하던 일
	2. Service Discovery
		- K8s의 Service, Endpoint, Pod를 watch해서 "어떤 서비스가 있고 실제 Pod IP가 뭔지           추적"
	3. xDS Server(Discovery Server)
		- 위 2개의 수집한 정보를 합쳐서 PushContext(설정 스냅샷)를 만듦
		- 이후 CDS/LDS/RDS/EDS/SDS 형태로 변환해서 "각 Envoy에 gRPC push"
		- CPU를 가장 많이 먹는 핵심

[ Citadel(CA) ]
- SPIFFE identity 기반 X.509 인증서 발급, SDS로 Envoy에 전달, 만료 전 자동 갱신

[ Sidecar Injector ]
- Pod 생성 시 Mutating Webhook으로 Envoy 사이드카 자동 주입
- namespace에 "istio-injection=enabled" 레이블이 있으면 동작

[ Config Validation(구 Galley) ]
- Validating Webhook으로 CR 생성/수정 시 스키마 검증
- 잘못된 VirtualService 같은 거 apply하면 여기서 reject

[ Gateway Controller ]
- Gateway API 리소스를 watch하고, Gateway가 생기면 Envoy Deployment를 자동 생성 

[ Pliot과 Galley 동작 구분 ]
EX. VirtualService or DestinationRule 변경, "kubectl apply -f virtualservice.yaml"
	- Galley
		1. mutating/validating webhook으로 "이 YAML 스키마가 맞는지, 필수 필드가 있는지" 검증
				- 결과 1. 틀릴 시 -> "거부"
				- 결과 2. 맞을 시 -> "K8s API server에 저장"
	- Pliot
		1. K8s API server에 저장
		2. Pilot이 K8s API server를 watch 중
			-> VirtualService 변경 감지
		3. Pilot이 변경된 리소스를 xDS 설정으로 변환
			-> virtualService -> RDS config
			-> DestinationRule -> CDS config
			-> 등등
		4. Pilot이 ADS(gRPC stream)로 해당 Envoy들에 Push
			-> Envoy가 설정을 "hot-reload"(재시작 없이 적용)

Data Plane

[ 동작 ]
- Envoy Proxy는 xDS를 받아 실제 트래픽을 처리
- 진입점 Enovy는 트래픽을 받고, Sidecar Envoy는 각 서비스 옆에 붙어서 들어오고 나가는
	모든 트래픽을 가로채서 mTLS 적용, 라우팅, 정책 검사, 메트릭 수집
- 사이드카가 iptables로 트래픽을 투명하게 가로채기 때문에 App 코드를 수정할 필요가 없음