「危險是我的中間名，」國際神秘人物奧斯汀鮑爾斯曾經說過。 但超級特工和情報部門所推崇的東西根本不適合電腦服務，因為在電腦服務中，無聊比危險好得多。
Istio 與 OpenShift 和 Kubernetes 一起，使部署微服務變得真正無聊且可預測 - 這很棒。 我們將在 Istio 系列的第四篇也是最後一篇文章中討論這一點以及更多內容。
當無聊是正確的時候
在我們的例子中，無聊只發生在最後階段，此時剩下的就是坐下來觀看整個過程。 但為此，您需要先配置所有內容，這裡有很多有趣的事情等著您。
部署新版本的軟體時，值得考慮最小化風險的所有選項。 並行運行是一種非常強大且經過驗證的測試方法，Istio 允許您使用「秘密服務」（微服務的隱藏版本）來執行此操作，而不會幹擾生產系統。 甚至還有一個專門的術語來形容這一點——“暗啟動”，它又是由一個同樣間諜名稱“流量鏡像”的功能激活的。
請注意，上一段的第一句使用術語「部署」而不是「發布」。 您確實應該能夠根據需要經常部署（當然，也可以使用）您的微服務。 該服務必須能夠接收和處理流量、產生結果以及寫入日誌和監控。 但同時，這項服務本身不一定需要發佈到生產環境中。 部署和發佈軟體並不總是同一件事。 您可以隨時部署，但只有在準備好時才發布。
整理無聊很有趣
看看下面的 Istio 路由規則，它將所有 HTTP 請求路由到微服務建議 v1（所有範例均取自 ），同時將它們鏡像到推薦 v2 微服務：
注意標籤 mirror: 螢幕底部 - 正是它設定流量鏡像。 是的，就是這麼簡單！
此規則的結果將是您的生產系統 (v1) 將繼續處理傳入請求，但請求本身將非同步鏡像到 v2，也就是說，它們的完整副本將轉到那裡。 這樣，您就可以在真實條件下（基於真實數據和流量）測試 v2，而不會以任何方式乾擾生產系統的運作。 這會讓組織測試變得無聊嗎？ 當然是。 但它是以一種有趣的方式完成的。
讓我們加入戲劇
請注意，在 v2 代碼中，有必要提供傳入請求可能導致資料變更的情況。 請求本身很容易、透明地被鏡像，但是測試中處理方法的選擇取決於你——這有點令人擔憂。
讓我們重複一個重要的觀點
可以透過流量鏡像（暗啟動/請求鏡像）進行秘密啟動，而不會以任何方式影響程式碼。
深思熟慮
如果鏡像請求的地方將其中一些請求發送到 v1，而不是 v2，該怎麼辦？ 例如，所有請求的百分之一或僅來自特定使用者群組的請求。 然後，已經了解了 v2 的工作原理，並逐漸將所有請求轉移到新版本。 反之亦然，如果 v1 出現問題，則將所有內容傳回給 v2。 我認為這稱為金絲雀部署。 ，如果它源自俄羅斯，它可能會包含對 ），現在我們將更詳細地討論這一點。
Istio 中的金絲雀部署：簡化調試
小心翼翼、循序漸進
Canary Deployment 部署模型的本質非常簡單：當您啟動軟體的新版本（在我們的例子中是微服務）時，您首先向一小群使用者授予對其的存取權限。 如果一切順利，您可以慢慢增加該群組，直到新版本開始運行，或者 - 如果沒有 - 最終將所有使用者遷移到該群組。 透過深思熟慮、逐步引入新版本並以受控方式將使用者切換到新版本，您可以降低風險並最大化回饋。
當然，Istio 透過提供幾個不錯的智慧請求路由選項來簡化 Canary 部署。 是的，所有這一切都可以在不以任何方式接觸原始程式碼的情況下完成。
過濾瀏覽器
最簡單的路由標準之一是基於瀏覽器的重定向。 假設您只希望來自 Safari 瀏覽器的請求轉到 v2。 其操作方法如下：
讓我們套用這個路由規則，然後使用指令 curl 我們將在循環中模擬對微服務的真實請求。 正如您在螢幕截圖中看到的，它們都轉到 v1：
v2 的流量在哪裡？ 由於在我們的範例中，所有請求僅來自我們自己的命令列，因此它根本不存在。 但請注意上面畫面中的底線：這是對我們執行來自 Safari 瀏覽器的請求這一事實的反應，而 Safari 瀏覽器又產生了以下內容：
無限動力
我們已經寫過，正規表示式為路由請求提供了非常強大的功能。 看看下面的範例（我們認為您會理解它的作用）：
現在您可能已經了解正規表示式可以做什麼。
聰明行事
智慧路由，特別是使用正規表示式處理資料包標頭，使您可以按照您想要的方式引導流量。 這極大地簡化了新程式碼的實作——很簡單，不需要更改程式碼本身，如果需要，一切都可以快速返回原樣。
感興趣的？
您是否渴望在電腦上嘗試 Istio、Kubernetes 和 OpenShift？ 團隊 準備了一個優秀的 並公開了所有隨附文件。 所以繼續吧，不要否認自己任何事。
Istio Egress：透過紀念品商店出口
透過將 Istio 與 Red Hat OpenShift 和 Kubernetes 結合使用，您可以讓微服務的使用變得更加輕鬆。 Istio 的服務網格隱藏在 Kubernetes Pod 內，您的程式碼（大部分）獨立運作。 性能、易於更改、追蹤等——由於使用了 sidecar 容器，所有這些都易於使用。 但是，如果您的微服務需要與 OpenShift-Kubernetes 系統外部的其他服務通訊怎麼辦？
這就是 Istio Egress 發揮作用的地方。 簡而言之，它只是允許您存取不屬於 Kubernetes Pod 系統的資源（即「服務」）。 如果您不執行其他配置，則在 Istio Egress 環境中，流量僅在 Pod 叢集內以及基於內部 IP 表的叢集之間進行路由。 只要您不需要從外部存取服務，這種化蛹就很有效。
出口可讓您根據出口規則或 IP 位址範圍繞過上述 IP 表。
假設我們有一個 Java 程序，它向 httpbin.org/headers 發出 GET 請求。
（httpbin.org 只是一個用來測試傳出服務請求的便利資源。）
如果你在命令列輸入 curl http://httpbin.org/headers，我們將看到以下內容：
或者你可以在瀏覽器中開啟相同的位址：
如您所見，位於此處的服務僅返回傳遞給它的標頭。
我們正在正面替代進口
現在，讓我們在我們的系統外部取得該服務的 Java 程式碼，並在我們自己的位置（回想一下，安裝了 Istio 的地方）運行它。 （您可以透過聯絡自己來完成此操作 .) 建立了適當的映像並在 OpenShift 平台上啟動它後，我們將使用以下命令呼叫此服務 curl egresshttpbin-istioegress.$(minishift ip).nip.io，之後我們將在螢幕上看到：
哎呀，發生什麼事了？ 一切都正常了。 未找到是什麼意思？ 我們只是為他做的 curl.
將 IP 表格擴展到整個 Internet
Istio 應該為此受到指責（或感謝）。 畢竟，Istio 只是負責偵測和路由（以及我們之前討論過的許多其他事情）的 sidecar 容器。 因此，IP 表只知道叢集系統內部的內容。 而且 httpbin.org 位於外部，因此無法存取。 這就是 Istio Egress 發揮作用的地方 - 無需對原始程式碼進行絲毫更改。
以下的出口規則強制 Istio 搜尋（如有必要，則在整個互聯網中）搜尋所需的服務，在本例中為 httpbin.org。 正如您從這個檔案（egress_httpbin.yml）中看到的，這裡的功能非常簡單：
剩下的就是應用這個規則：
istioctl create -f egress_httpbin.yml -n istioegress
您可以使用以下命令查看出口規則 istioctl get egressrules:
最後，我們再次運行命令 捲曲 – 我們看到一切正常：
我們開放地思考
正如您所看到的，Istio 允許您組織與外部世界的互動。 換句話說，您仍然可以建立 OpenShift 服務並透過 Kubernetes 管理它們，將所有內容保留在可根據需要擴充和縮小的 Pod 中。 同時，您可以安全地存取環境外部的服務。 是的，我們再次重申，所有這一切都可以在不以任何方式接觸您的程式碼的情況下完成。
這是 Istio 系列的最後一篇文章。 請繼續關注 - 前面有很多有趣的事情！
來源： www.habr.com