istio常見的10個異常是什么

這篇文章主要講解了“istio常見的10個異常是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“istio常見的10個異常是什么”吧！

1. Service 端口命名約束

istio 支持多平臺，不過 Istio 和 k8s 的兼容性是最優的，不管是設計理念，核心團隊還是社區， 都有一脈相承的意思。但 istio 和 k8s 的適配并非完全沒有沖突, 一個典型問題就是 istio 需要 k8s service 按照協議進行端口命名(port naming)。

端口命名不滿足約束而導致的流量異常，是使用 mesh 過程中最常見的問題，其現象是協議相關的流控規則不生效，這通常可以通過檢查該 port LDS 中 filter 的類型來定位。

原因

k8s 的網絡對應用層是無感知的，k8s 的主要流量轉發邏輯發生在 node 上，由 iptables/ipvs 來實現，這些規則并不關心應用層里是什么協議。

istio 的核心能力是對 7層流量進行管控，但前提條件是 istio 必須知道每個受管控的服務是什么協議，istio 會根據端口協議的不同，下發不同的流控功能（envoy filter），而 k8s 資源定義里并不包括七層協議信息，所以 istio 需要用戶顯式提供。

istio 的解決方案：Protocol sniffing

協議嗅探概要：

• 檢測 TLS CLIENT_HELLO 提取 SNI、ALPN、NPN 等信息

• 基于常見協議的已知典型結構，嘗試檢測應用層 plaintext 內容 a. 基于HTTP2 spec: Connection Preface，,判斷是否為 HTTP/2 b. 基于 HTTP header 結構，判斷是否是 HTTP/1.x

• 過程中會設置超時控制和檢測包大小限制， 默認按照協議 TCP 處理

最佳實踐

Protocol sniffing 減少了新手使用 istio 所需的配置，但是可能會帶來不確定的行為。不確定的行為在生產環境中是應該盡量避免的。

一些嗅探失效的例子：

• 客戶端和服務端使用著某類非標準的七層協議，客戶端和服務端都可以正確解析，但是不能確保 istio 自動嗅探邏輯認可這類非標準協議。比如對于 http 協議，標準的換行分隔是用 CRLF （0x0d 0x0a）, 但是大部分 http 類庫會使用并認可 LF （0x0a）作為分隔。

• 某些自定義私有協議，數據流的起始格式和 http 報文格式類似，但是后續數據流是自定義格式：未開啟嗅探時：數據流按照 L4 TCP 進行路由，符合用戶期望 如果開啟嗅探：數據流最開始會被認定為 L7 http 協議，但是后續數據不符合 http 格式，流量將被中斷

建議生產環境不使用協議嗅探, 接入 mesh 的 service 應該按照約定使用協議前綴進行命名。

2. 流控規則下發順序問題

異常描述

在批量更新流量規則的過程中，偶爾會出現流量異常（503），envoy 日志中 RESPONSE_FLAGS 包含「NR」標志(No route configured)，持續時間不長，會自動恢復。

原因分析

當用戶使用 kubectl apply -f multiple-virtualservice-destinationrule.yaml時，這些對象的傳播和生效先后順序是不保證的，所謂最終一致性，比如 VirtualService 中引用了某一個 DestinationRule 定義的子版本，但是這個 DestinationRule 資源的傳播和生效可能在時間上落后于 該 VirtualService 資源。

最佳實踐：make before break

將更新過程從批量單步拆分為多步驟，確保整個過程中不會引用不存在的 subset：

當新增 DestinationRule subset 時，應該先 apply DestinationRule subset，等待 subset 生效后，再 apply 引用了該 subset 的 VirtualService。

當刪除 DestinationRule subset 時，應該先 刪除 VirtualService 中對 該 subset 的引用，等待 VirtualService 的修改生效后，在執行刪除 DestinationRule subset。

3. 請求中斷分析

請求異常，到底是 istio 流控規則導致，還是業務應用的返回，流量斷點出現在哪個具體的 pod？

這是使用 mesh 最常見的困境，在微服務中引入 envoy 作為代理后，當流量訪問和預期行為不符時，用戶很難快速確定問題是出在哪個環節。客戶端收到的異常響應，諸如 403、404、503 或者連接中斷等，可能是鏈路中任一 sidecar 執行流量管控的結果， 但也有可能是來自某個服務的合理邏輯響應。

envoy 流量模型

Envoy 接受請求流量叫做 Downstream，Envoy 發出請求流量叫做Upstream。在處理Downstream 和 Upstream 過程中， 分別會涉及2個流量端點，即請求的發起端和接收端：

在這個過程中， envoy 會根據用戶規則，計算出符合條件的轉發目的主機集合，這個集合叫做 UPSTREAM_CLUSTER, 并根據負載均衡規則，從這個集合中選擇一個 host 作為流量轉發的接收端點，這個 host 就是 UPSTREAM_HOST。

以上就是 envoy 請求處理的 流量五元組信息， 這是 envoy 日志里最重要的部分，通過這個五元組我們可以準確的觀測流量「從哪里來」和「到哪里去」。

• UPSTREAM_CLUSTER

• DOWNSTREAM_REMOTE_ADDRESS

• DOWNSTREAM_LOCAL_ADDRESS

• UPSTREAM_LOCAL_ADDRESS

• UPSTREAM_HOST

日志分析示例

通過日志重點觀測 2 個信息：

• 斷點是在哪里 ？

• 原因是什么？

示例一：一次正常的 client-server 請求

可以看到 2 端日志包含相同的 request ID，因此可以將流量分析串聯起來。

示例二：no healthy upstream, 比如目標 deployment 健康副本數為 0

日志中 flag「UH」表示 upstream cluster 中沒有健康的 host。

示例三：No route configured , 比如 DestinationRule 缺乏對應的 subset

日志中 flag「NR」表示找不到路由。

示例四，Upstream connection failure，比如服務未正常監聽端口。

日志中 flag「UF」表示 Upstream 連接失敗，據此可以判斷出流量斷點位置。

4. sidecar 和 user container 啟動順序

異常描述

Sidecar 模式在kubernetes 世界很流行，但對目前的 k8s （V1.17）來說，并沒有 sidecar 的概念，sidecar 容器的角色是用戶主觀賦予的。

對 Istio 用戶來說，一個常見的困擾是：sidecar 和用戶容器的啟動順序：

sidecar（envoy） 和用戶容器的啟動順序是不確定的，如果用戶容器先啟動了，envoy 還未完成啟動，這時候用戶容器往外發送請求，請求仍然會被攔截，發往未啟動的 envoy，請求異常。

在 Pod 終止階段，也會有類似的異常，根源仍然是 sidecar 和普通容器的生命周期的不確定性。

解決方案

目前常規的規避方案主要是有這樣幾種：

• 業務容器延遲幾秒啟動, 或者失敗重試

• 啟動腳本中主動探測 envoy 是否ready，如 127.0.0.1:15020/ healthz/ready

無論哪種方案都顯得很蹩腳，為了徹底解決上述痛點，從 kubernets 1.18版本開始，k8s 內置的 Sidecar 功能將確保 sidecar 在正常業務流程開始之前就啟動并運行，即通過更改pod的啟動生命周期，在init容器完成后啟動sidecar容器，在sidecar容器就緒后啟動業務容器，從啟動流程上保證順序性。而 Pod 終止階段，只有當所有普通容器都已到達終止狀態, 才會向sidecar 容器發送 SIGTERM 信號。

5. Ingress Gateway 和 Service 端口聯動

Ingress Gateway 規則不生效的一個常見原因是：Gateway 的監聽端口在對應的 k8s Service 上沒有開啟，首先我們需要理解 Istio Ingress Gateway 和 k8s Service 的關系：

上圖中，雖然 gateway 定義期望管控端口 b 和 c，但是它對應的 service （通過騰訊云CLB）只開啟了端口 a 和 b，因此最終從 LB 端口 b 進來的流量才能被 istio gateway 管控。

• Istio Gateway 和 k8s Service 沒有直接的關聯，二者都是通過 selector 去綁定 pod，實現間接關聯

• Istio CRD Gateway 只實現了將用戶流控規則下發到網格邊緣節點，流量仍需要通過 LB 控制才能進入網格

• 騰訊云 tke mesh 實現了 Gateway-Service 定義中的 Port 動態聯動，讓用戶聚焦在網格內的配置。

6. VirtualService 作用域

VirtualService 包含了大部分 outbound 端的流量規則，它既可以應用到網格內部數據面代理中， 也可以應用到網格邊緣的代理中。

VirtualService 的屬性gateways用于指定 VirtualService 的生效范圍：

• 如果 VirtualService.gateways為空，則 istio 為其賦默認值 mesh, 代表生效范圍為網格內部

• 如果希望 VirtualService 應用到具體邊緣網關上，則需要顯示為其賦值：gateway-name1,gateway-name2...

• 如果希望 VirtualService 同時應用到網格內部和邊緣網關上，則需要顯示地把mesh值加入VirtualService.gateways， 如 mesh,gateway-name1,gateway-name2...一個常見的問題是以上的第三種情況，VirtualService 最開始作用于網關內部，后續要將其規則擴展到邊緣網關上，用戶往往只會添加具體 gateway name，而遺漏 mesh:

Istio 自動給VirtualService.gateways設置默認值， 本意是為了簡化用戶的配置，但是往往會導致用戶應用不當，一個 feature 一不小心會被用成了 bug。

7. VirtualService 不支持 host fragment

異常案例

對某一 host 新增、修改 VirtualService，發現規則始終無法生效，排查發現存在其他 VirtualService 也對該 host 應用了其他規則，規則內容可能不沖突，但還是可能出現其中一些規則無法生效的情況。

背景

• VirtualService 里的規則，按照 host 進行聚合

• 隨著業務的增長，VirtualService 的內容會快速增長，一個 host 的流控規則，可能會由不同的團隊分布維護。如安全規則和業務規則分開，不同業務按照子 path 分開

目前 istio 對 cross-resource VirtualService 的支持情況：

• 在網格邊緣（gateway），同一個 host 的流控規則，支持分布到多個 VirtualService 對象中，istio 自動聚合，但依賴定義順序以及用戶自行避免沖突。

• 在網格內部（for sidecar），同一個 host 的流控規則，不支持分布到多個 VirtualService 對象中，如果同一個 host 存在多個 VirtualService，只有第一個 VirtualService 生效，且沒有沖突檢測。

VirtualService 不能很好支持 host 規則分片，使得團隊的維護職責不能很好的解耦，配置人員需要知悉目標 host 的所有流控規則，才有信心去修改 VirtualService。

Istio 解決方案：Virtual Service chaining（plan in 1.6）

Istio 計劃在 1.6 中支持 Virtual Service 代理鏈：

• Virtual Service 支持分片定義 + 代理鏈

• 支持團隊對同一 host 的 Virtual Service 進行靈活分片，比如按照 SecOps/Netops/Business 特性分離，各團隊維護各種獨立的 Virtual Service

8. 全鏈路跟蹤并非完全透明接入

異常案例

微服務接入后 service mesh 后，鏈路跟蹤數據沒有形成串聯。

原因

service mesh 遙測系統中，對調用鏈跟蹤的實現，并非完全的零入侵，需要用戶業務作出少量的修改才能支持，具體地，在用戶發出（http/grpc） RPC 時， 需要主動將上游請求中存在的 B3 trace headers寫入下游 RPC 請求頭中，這些 headers 包括：

有部分用戶難以理解：既然 inbound 流量和 outbound 流量已經完全被攔截到 envoy，envoy 可以實現完全的流量管控和修改，為什么還需要應用顯示第傳遞 headers？

對于 envoy 來說，inbound 請求和 outbound 請求完全是獨立的，envoy 無法感知請求之間的關聯。實際上這些請求到底有無上下級關聯，完全由應用自己決定。舉一個特殊的業務場景，如果 Pod X 接收到 請求 A，觸發的業務邏輯是：每隔 10 秒 發送一個請求到 Pod Y，如 B1，B2，B3，那么這些扇出的請求 Bx（x=1,2,3...），和請求 A 是什么關系？業務可能有不同的決策：認為 A 是 Bx 的父請求，或者認為 Bx 是獨立的頂層請求。

9. mTLS 導致連接中斷

在開啟 istio mTLS 的用戶場景中，訪問出現 connection termination 是一個高頻的異常：

這個異常的原因和 DestinationRule 中的 mTLS 配置有關，是 istio 中一個不健壯的接口設計。

• 當通過 MeshPolicy 開啟全局 mTLS， 如果網格中沒有定義其他的 DestinationRule，mTLS 正常運行

• 如果后續網格中新增了 DestinationRule，而 DestinationRule 中可以覆蓋子版本的 mTLS 值(默認是不開啟！), 用戶在使用 DestinationRule 時，往往很少去關注 mTLS 屬性（留空）。最終導致增 DestinationRule 后 mTLS 變成了不開啟，導致connection termination

• 為了修復以上問題，用戶不得不在所有 DestinationRule 中增加 mTLS 屬性并設置為開啟

這種 istio mtls 用戶接口極度不友好，雖然 mtls 默認做到了全局透明， 業務感知不到 mtls 的存在， 但是一旦業務定義了 DestinationRule，就必須要知道當前 mtls 是否開啟，并作出調整。試想 mtls 配置交由安全團隊負責，而業務團隊負責各自的 DestinationRule，團隊間的耦合會非常嚴重。

10. 用戶服務監聽地址限制

異常描述

如果用戶容器中業務進程監聽的地址是具體ip (pod ip)，而不是0.0.0.0, 該用戶容器無法正常接入 istio，流量路由失敗。這是又一個挑戰 Istio 最大透明化（Maximize Transparency）設計目標 的場景。

原因分析

Istio-proxy 中的一段 iptables:

其中，ISTIO_IN_REDIRECT 是 virtualInbound, 端口 15006；ISTIO_REDIRECT 是 virtualOutbound，端口 15001。

關鍵點是規則二：如果 destination 不是127.0.0.1/32, 轉給15006 (virtualInbound, envoy監聽)，這里導致了對 pod ip 的流量始終會回到 envoy。

對該規則的解釋：

# Redirect app calls back to itself via Envoy when using the service VIP or endpoint # address, e.g. appN => Envoy (client) => Envoy (server) => appN.

該規則是希望在這里起作用: 假設當前Pod a屬于service A, Pod 中用戶容器通過服務名訪問服務A, envoy中負載均衡邏輯將這次訪問轉發到了當前的pod ip, istio 希望這種場景服務端仍然有流量管控能力. 如圖示:

改造建議

建議應用在接入 istio 之前， 調整服務監聽地址，使用 0.0.0.0 而不是具體 IP。如果業務方認為改造難度大，可以參考之前分享的一個解決方案：服務監聽pod ip 在istio中路由異常分析

感謝各位的閱讀，以上就是“istio常見的10個異常是什么”的內容了，經過本文的學習后，相信大家對istio常見的10個異常是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！