메모장
Last updated
Was this helpful?
Last updated
Was this helpful?
기존 istio ingress gateway의 service type 은 LoadBalancer 에서 NodePort로 변경하여 기존 ELB가 삭제되고, 대신 Kubernetes 의 Ingress resource를 통해 ALB를 생성한다. 그리고 ALB에서 TLS termination 을 하고 모든 request를 istio ingress gateway pod로 보내고 istio ingress gateway가 application service로 routing 을 하게 된다.
Kubernetes 환경의 네트워크(service mesh) 관리에서 가장 많이 사용되는 오픈 소스가 istio다.
Ingress Gateway 는 기존 K8s Ingress 와 유사하게, 단일 로드밸런서의 엔드포인트를 통해 클러스터 외부의 요청을 받아서, 내부 서비스들로 로드밸런싱을 해주는 역할을 하는 게이트웨이라고 볼 수 있습니다. 이 오브젝트를 생성하면, 클라우드환경의 경우 클라우드 공급자의 로드밸런서를 통해서, On-premise 의 경우 케이스에 따라 다르겠지만, Metallb 등을 사용해서 IP Address Pool 안에서의 IP 등으로 type: LoadBalancer 인 서비스 오브젝트가 생성되고, External IP 와 매핑됩니다.
AWS 기준으로 이렇게 생성하였을 때 Application Load Balancer 가 생성되고, 그것에 해당하는 도메인 foo.aws-alb.com 이 생성되었다고 해봅시다. 이 경우에 Route53 에서 *.hayden.com 이라는 도메인에 대한 A 레코드(with alias) foo.aws-alb.com 으로 지정하면, 우리는 *.hayden.com 으로 들어오는 트래픽을 모두 Istio Ingress Gateway로 전달 해줄 수 있습니다.
이후 Gateway 오브젝트 및 VirtualService 오브젝트를 사용하여 호스트헤더, HTTP 헤더, 경로 기반의 라우팅을 할 수 있게 됩니다. 즉 North-South 트래픽을 컨트롤 하기위해 생성하는 Istio 의 오브젝트라고 생각하면 됩니다.
다만 순수한 K8s Ingress 오브젝트와는 다르기 때문에 Ingress 로 검색 할수는 없고, Ingress Gateway는 디플로이먼트(파드) 및 서비스(로드밸런서)로 구성되게 됩니다.
위에서 보는것과 같이 내부 서비스메시의 트래픽 시작점이 istio-ingressgateway 이고 (단, 외부에서 클러스터로 호출 한 경우에 한정) 이후에는 각 마이크로서비스간 사전 정의된 방식대로 트래픽이 흘러가게 됩니다.
k로 시작하는 그걸 eks cluster에 배포하고 istio monitoring (?)
