Istio是運作在kubernetes之上的一種服務網格(Service Mesh，第三代微服務架構)，極大的擴充了kubernetes的功能，可以輕松實作比kubernetes更細顆粒度的流量管理。
當我們直接在kubernetes部署應用時，有時要實作一些特殊需求是比較困難的，比如金絲雀釋出（也稱為灰階釋出）。
金絲雀釋出是這樣工作的，我們已經有了一個舊版本的應用這裡稱之為v1，然後要釋出一個新版本的應用這裡稱之為v2。但是現在并不想讓所有的用戶端都通路v2，隻是想在小範圍内對部分用戶端開放進行測試。
是以我們可以設定90%的流量轉發到v1,10%的流量轉發到v2。如果這10%的使用者回報v2還不錯，那麼我們我們可以擴大通路v2的流量，縮小通路v1的流量。
以此類推，直到把所有的流量逐漸轉移到v2上面。
如果沒有istio的話實作的方式是這個樣子的，建立兩個deployment，一個是v1一個v2。他們建立的pod具備相同的标簽供service關聯。首先v1設定3個副本，v2設定一個副本，這樣75%的流量都轉發到v1上了，25%的流量轉發到v2上。
然後我們可以縮小v1的副本數，增加v2的副本數來修改流量的走向，如下圖。
但是這種流量的管控顯得過于粗糙，且維護起來也過于麻煩。
但是我們在istio裡是非常友善實作的。下面是取自一個VirtualService（簡稱為vs）裡的部分代碼，我們通過修改weight即可修改流量的走向。
- destination:
host: svc1
subset: v1
weight: 65
- destination:
host: svc1
subset: v2
weight: 35 這裡指定往pod1的流量占65%，往pod2的流量占35%，然後通過下圖看流量走向。
然後我們再次修改weight。
- destination:
host: svc1
subset: v1
weight: 35
- destination:
host: svc1
subset: v2
weight: 65 這裡設定往pod1走35%的流量，往pod2走65%的流量，然後看下圖。
我們隻要改變這裡的weight就可以輕松按照百分比改變轉發到pod的流量。除了上述金絲雀釋出之外，我們要實作藍綠部署、A/B測試、會話保持、流量鏡像等功能都可以輕松實作，是以istio的強大之處在于它的流量管理。
如果我們想讓不同的用戶端（Android、windows、firefox、chrome等）通路到不同的pod上，istio亦可以輕松實作。