Cloud에서 k8s istio 상세설명+네트워크 흐름+Service Discovery

아래 내용관련하여 제대로된 포스팅이 없어서, 총망라해서 정리하였다. 

k8s에서 MSA기반 어플리케이션 구축시 MSA 모듈간 상호 참조하는 샘플링과 Service Discovery, Network Flow에 대한 정리가 잘없더라... 그래서 정리하였다.

 

CASE 1. 외부호출-MSA모듈 통신

 

 AWS 의 경우 istio gateway영역은 아래와 같이 하기를 권장한다. 

① AWS의 경우 k8s Gateway 리소스에서 AWS ALB Controller Class를 사용함으로써 Cloud 영역에서 관리가 가능한 로드벨런서가 생성된다. 
② 해당 Ingress Gateway는 Ingress Controller로 트래픽을 전송한다.
③ Ingress Controller는 라우터로써 역할하며, 패킷의 Header와 매칭되는 Virtual Service로 라우팅 한다.
④ 외부의 Client와 세션이 맺어진다.

 

 

 

AWS처럼 embeded ingress controller 를 제공하면 좋은데 아닌경우에는 다음과 같이 설정해야 한다.

① 이 경우 CSP에서 제공하는 로드벨런서 리소스를 사용하여 모든 워크노드에 균등하게 패킷이 분기된다. 
② Cluster Wide한 Gateway 리소스가 로드벨런서로 부터 패킷을 넘겨 받는다.
③ 해당 Ingress Gateway는 Ingress Controller로 트래픽을 전송한다
④ Ingress Controller는 라우터로써 역할하며, 패킷의 Header와 매칭되는 Virtual Service로 라우팅 한다.
⑤ 외부의 Client와 세션이 맺어진다.

 

참고링크

https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/

Egress Gateways

https://rinormaloku.com/istio-practice-routing-virtualservices/

Istio in Practice - Routing with VirtualService | Rinor Maloku

 

CASE 2. MSA 모듈간 내부 통신

① Proxy DNS 기능을 사용하여 istio 내부의 service Registry에 질의를 한다. 

※ 이 질의의 결과는 kube-dns, Cloud DNS보다 선순위, 호출한 Pod의 Host DNS보다는 후순위 이므로 참고
②③ istio 데몬을 통해 Target의 ClusterIP를 전달 받는다. 
④⑤ 해당 ClusterIP로 패킷을 송신한다. 해당 ClusterIP는 Virtual Service를 가리키며 최종적으로 Target 어플리케이션에 패킷이 도착한다.
⑥ TTL 동안 추가적인 DNS질의는 하지 않고 바로 패킷을 송신한다. 

 

 

 

참고링크 

https://github.com/istio/istio/tree/master/samples/bookinfo

GitHub - istio/istio: Connect, secure, control, and observe services.

https://istio.io/latest/docs/ops/configuration/traffic-management/dns/

Understanding DNS

https://istio.io/latest/docs/reference/config/networking/service-entry/

Service Entry

https://istio.io/latest/docs/reference/config/networking/virtual-service/

Virtual Service

https://istio.io/latest/docs/reference/config/networking/virtual-service/

Virtual Service