本文章同時發佈於：
文章為自己的經驗與夥伴整理的內容，設計沒有標準答案，如有可以改進的地方，請告訴我，我會盡我所能的修改，謝謝大家～
大家好，今天要介紹的是Istio Gateway、VirtualService的概念，為何不直接使用K8s Ingress元件？，為什麼要分那麼多層元件呢？
K8s Ingress無法達到Service Mesh的功能
官方說明:
For ingress traffic management, you might ask: Why not reuse Kubernetes Ingress APIs? The Ingress APIs proved to be incapable of expressing Istio’s routing needs. By trying to draw a common denominator across different HTTP proxies, the Ingress is only able to support the most basic HTTP routing and ends up pushing every other feature of modern proxies into non-portable annotations.
簡單來說，在原本的K8s Ingress元件，無法提供Service Mesh的需求，僅適用簡單的路由，而要有辦法精確的控制Service Mesh，必須要將Ingress的職責切分的更細，如以下:
外部Load Balancer --> Istio Gateway元件 --> Istio VirtualService元件 --> K8s Service元件 --> K8s Pods元件
官方提供了下圖:
Istio將L4-L6層的功能(如TCP、TSL等等)，交給Gateway元件處理，
而L7層的應用層就可以在特別客製，如果要連接不同的Service就交給VirtualService元件處理，如果要管理流量就透過DestinationRule元件處理，
結論
在K8s搭配Istio的系統中，K8s許多溝通的功能會盡量讓Istio來做，系統會越來越趨向於Istio負責各種溝通、K8s只負責容器的生命週期，所以你會發現Istio慢慢將K8s的溝通細分掌控，這樣才能達到Service Mesh的好處。