如果你正在使用容器，特別是kubernetes，那麼你應該也聽說過istio。對於初學者來說，istio是kubernetes的服務網格（service mesh）。所謂服務網格，它是乙個網路層，並且可以動態管理服務流量，然後以安全的方式進行管理。
istio可以讓你使用一組自定義kubernetes資源來管理網路流量，並且可以幫助你保護和加密服務之間以及集群內外的網路流量。它全面整合了kubernetes api，這意味著可以使用與其他kubernetes配置完全相同的方式來定義和管理istio設定。
如果要開始使用istio，首先應該問自己為什麼。istio提供了一些非常有價值的功能，如金絲雀發布等，但是如果不增加一些複雜性，就無法使用它們。你還需要投入一定的時間來學習它。也就是說，如果你的情況合適使用它，你可以（並且應該）在自己的集群中謹慎且逐步地採用istio的功能。
如果你要從頭開始構建新環境，並且經過利弊權衡決定繼續使用istio，那麼一定要從一開始就使用嚴格的相互tls對其進行設定，並積極使用其強大的功能。具體操作請參考：
接下來是你在cloud native旅程中可能遇到的兩個常見問題，以及如何使用istio來解決這些問題。
如果測試範圍並沒有完全涵蓋你所更改的應用程式，那麼你可能會很快採取行動進行新一輪測試，但也有可能應用程式無法正常執行了。
在理想狀況下，我們都想要確保每個**經過全面的測試，否則就不會將功能新增到應用程式中。但是現實總歸是骨感的，我們常常被ddl追趕，可能還未編寫或者更新測試，功能就得上傳到專案中了。
那麼，如何確保我絕大多數使用者不受**中潛伏的任何錯誤的影響，又如何進行更改和部署新功能呢？答案是通過先將新版本部署到最少數量的使用者來最大程度地減少這些小問題的輻射範圍。
如果更改能夠按照預期工作的話，你可以緩慢增加使用新版本的使用者百分比。如果各項指標出現問題，你可以輕鬆回滾你的更改，然後重試。
在沒有istio的情況下可以在kubernetes上執行金絲雀部署嗎？當然沒問題，但是如果要自動化這一過程，你需要完全將自己的精力放在web伺服器**和自定義自動化指令碼方面。這樣的操作方式價效比並不高。
istio有一些十分優雅的流量分配解決方案，我們可以使用它們在恰當的時間為合適的版本提供適當的客戶端服務，並且我們只需調整其中的1個或2個引數。
為了實現這一點，你需要設定乙個閘道器入口（ingress gateway）、乙個虛擬服務（virtual service）和乙個destination rule。這將位於一般的部署和服務之上，並為你分配流量。
從虛擬服務的權重欄位中可以看到，istio將根據指定的值在應用程式的兩個版本之間分配流量。這些值的總和必須為100％，否則，api將拒絕應用該定義。
然後，你（或者理想情況下，在「持續整合/連續交付」流水線中手動執行乙個或多個步驟）將調整權重，以將新版本推廣給更多使用者，直到所有請求由新版本滿足為止，並且以前的版本可以停止維護。
通過使用istio的故障注入功能來模擬網路中斷和實際流量效能下降，還可以將istio整合到您的整合測試策略中。
如果在生產中進行測試的想法給你留下了心理陰影，那一定是你的做法有所欠缺。例如，嘗試在你的虛擬服務規範中新增以下**片段以新增一些混亂，然後再找一篇文章來看看怎麼用istio解決這樣的混亂。
通常，業務需要針對實際使用者測試應用程式的多個版本。但是有時實在無法搞清楚是哪種營銷策略可以帶來最佳轉化率，或者哪種設計選擇可以帶來最佳的客戶留存率。
使用kubernetes，你可以將流量分為兩個版本，但是要想從練習中獲得任何有價值的見解，則再次需要一大堆自定義**來獲取相關資訊，並以非技術同事可以理解的方式對其進行處理。
istio的流量分配規則可以再次解決這一問題，它與prometheus和grafana的緊密整合可以幫助你獲取直觀的a/b測試的結果。一般而言，根據傳入資料報內容的某些部分，幾乎有無數種方法來決定哪些使用者可以獲取你的應用程式的版本。
在這一示例中，我們將使用user-agent欄位為不同的瀏覽器提供不同的版本。
從上面的**中可以看到，使用firefox的使用者將獲得應用程式的版本1，而chrome使用者將獲得版本2。如果瀏覽器的「user-agent」欄位不包含「mozilla」或「chrome」，則他們都將不會獲得任一版本。
要為其他客戶提供服務，您需要新增一條預設路由，我將作為練習留給你。（嘿嘿）
如果你不想安裝其他瀏覽器，只是想嘗試一下，則可以使用帶有頭部標誌的curl偽裝成所需的任何瀏覽器，例如：
通過更改user-agent的值，你可以從命令列測試所有不同的路由。
以上兩種情況大概能讓你體驗到istio強大功能的冰山一角。正如上文所說，如果沒有istio，你依然可以進行金絲雀部署和a/b測試，只是你必須自己實現流量分配。但這大大增加了開發部署的複雜性，實屬價效比低之選。
值得一提的是，rancher 2.3 preview2版本上開始支援istio，使用者可以直接在ui介面中啟動istio並且可以為每個命名空間注入自動sidecar。此外，rancher簡化istio的安裝和配置，內建了乙個支援kiali的儀錶盤，用於流量和遙測的視覺化，然後用jaeger進行追蹤，甚至還有自己的prometheus和grafana（與用於高階監控的例項不同）。這一切讓部署和管理istio變得簡單而快速。
k8s安裝部署Istio
istio簡介 istio 的安裝檔案中包括如下幾個子 chart。ingress ingressgateway egressgateway sidecarinjectorwebhook galley mixer pilot security citadel grafana prometheus s...
使用minikube安裝k8s
要注意的是配置國內映象加速，配置方法 編輯docker的daemon，沒有則新建檔案 vim etc docker daemon.json 內容為重啟docker 參考 注意要新建乙個非root使用者，並配置操作許可權。在執行這一步的時候 之後比較順利 文件 如果此時你在伺服器上安裝 k8s，此時外...
如何使用K8S的Ingress
ingress的好處與特點我就沒有必要再說一次了，本文主要說明的是使用方法 請先完成k8s的安裝，安裝ingress，它包括乙個defaulebackend，與nginx ingress control,並pull下需要的docker image 注意這裡請注意一點，為了方便，我們希望在部署ingr...