Istio 流量劫持
運用服務網格的好處，就是不用修改本身應用的任何代碼，就可以實現重試、重試、注冊、發現、故障注入等等的能力，而且對開發語言、框架都是沒有任何限定統一的技術棧的，那么為什么服務網格那么厲害可以做到那么透明呢，不用修改應用的任何代碼讓應用獲得服務的治理能力呢，我們一起了解一下吧！
Istio的數據平面是由多個應用容器（App）加邊車容器（Envoy）的Pods組成的，可以參考我之前的文章 - Istio 項目介紹， Istio Envoy 的工作原理就是通過 Kubernetes Pods的共享NameSpace特性，把邊車容器與應用容器"綁定"在一起，并且通過 iptables 修改應用容器的進出流量都需要經過Envoy，在Envoy上進行流量的管控從而實現服務的治理能力。 這也是在代碼開發中，經常使用的"邊車模式"。
上訴我們已經知道了通過iptables修改流量的走向，讓Envoy去接管流量從而實現服務的治理能力，那么iptables是如何修改進去Pods中的呢，可以參考我之前的文章 - Istio 注入原理，通過對原來的資源定義清單進行修改后實施，從而附加上 Envoy 容器以及 Init 容器，Iptables的策略就是由 init容器進行定義的。
首先我們安裝一下 nsenter 這個工具，用于接下來的實驗探索。
yum install -y util-linux PID=$(docker inspect --format "{{ .State.Pid}}"
1
2
3
通過 nsenter 可以發現
1.進入的流量會命中#1紅框的PREROUTING鏈。
2.接著在Target中會選擇#2紅框 ISTIO_INBOUND鏈。
3.如果是 tcp destination port 22 15090 15021的流量會直接放行處理，
否則其他流量全部交給下一個鏈 #3紅框ISTIO_IN_REDIRECT。
4.ISTIO_IN_REDIRECT 鏈中就把流量交給了 15006 端口 （Envoy容器流量入端口）
REQUEST -> （IPTABLES PREROUTING -> ISTIO_INBOUND -> ISTIO_IN_REDIRECT -> REDIRECT PORT 15006） -> ISTIO-PROXY
通過 nsenter 可以發現
1.出去的流量會命中#1紅框的OUTPUT鏈。
2.接著在Target中會選擇#2紅框 ISTIO_OUTPUT鏈。
如果是 Owner GID 1337 的流量會直接放行處理，GID1337 表示的是Envoy自身流量，以防止流量循環。
其他流量全部交給下一個鏈 #3紅框ISTIO_REDIRECT。
3.ISTIO_REDIRECT 鏈中就把流量交給了 15001 端口 （Envoy容器流量出端口）
REQUEST -> （IPTABLES OUTPUT -> ISTIO_OUTPUT -> ISTIO_REDIRECT -> REDIRECT PORT 15001） -> ISTIO-PROXY
經過iptables處理后的流量，最后都會經過envoy進行處理（return的除外），那么在envoy進行流量的處理，那么就可以對應用透明無感知的情況下進行一些高級的治理能力處理，而envoy處理的規則，是由pilot進行下發的，具體可以定義那些服務治理規則的？歡迎繼續關注，我們下期在見！
refer: https://istio.io/latest/docs/ops/deployment/requirements/
Istio
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
