太強了,Istio竟然有這么多功能!
1 簡介
Istio,希臘語,意揚帆起航。
一個完全開源的服務網格產品,對分布式應用是透明的。Istio 管理服務之間的流量,實施訪問政策并匯總遙測數據,而不需要更改應用代碼。Istio 以透明的方式對現有分布式應用進行分層,從而簡化了部署復雜性。
也是一個平臺,可與任何日志、遙測和策略系統集成。服務于微服務架構,并提供保護、連接和監控微服務的統一方法。
在原有的數據平面的基礎上,增加了控制平面。
為什么會火
- 發布及時(2017年5月發布0.1版本)
- 巨頭廠商buff 加持
- 第二代Service Mesh
- Envoy的加入讓Istio如虎添翼
- 功能強大
優點
- 輕松構建服務網格
- 應用代碼無需更改
- 功能強大
2 核心功能
2.1 流量控制
路由、流量轉移 流量進出 網絡彈性能力 測試相關
2.1.1 核心資源(CRD)
虛擬服務(Virtual Service) 和目標規則(Destination Rule) 是 Istio 流量路由功能的關鍵拼圖。
2.1.1.1 虛擬服務( Virtual Service )
虛擬服務讓你配置如何在服務網格內將請求路由到服務,這基于 Istio 和平臺提供的基本的連通性和服務發現能力。每個虛擬服務包含一組路由規則,Istio 按順序評估它們,Istio 將每個給定的請求匹配到虛擬服務指定的實際目標地址。您的網格可以有多個虛擬服務,也可以沒有,取決于使用場景。
- 將流量路由到給定目標地址
- 請求地址與真實的工作負載解耦
- 包含一組路由規則
- 通常和目標規則( Destination Rule)成對出現
- 豐富的路由匹配規則
2.1.1.2 目標規則( Destination Rule)
定義虛擬服務路由目標地址的真實地址,即子集。設置負載均衡的方式
- 隨機
- 權重
- 最少請求數
2.1.1.3 網關(Gateway)
Egress 不一定使用。
服務入口 (Service Entry)
- 使用服務入口(Service Entry) 來添加一個入口到 Istio 內部維護的服務注冊中心,即把外部服務注冊到網格中。
添加了服務入口后,Envoy 代理可以向服務發送流量,就好像它是網格內部的服務一樣。
配置服務入口允許您管理運行在網格外的服務的流量,它包括以下幾種能力:
- 為外部目標 redirect 和轉發請求,例如來自 web 端的 API 調用,或者流向遺留老系統的服務。
- 為外部目標定義重試、超時和故障注入策略。
- 添加一個運行在虛擬機的服務來擴展您的網格。
- 從邏輯上添加來自不同集群的服務到網格,在 Kubernetes 上實現一個多集群 Istio 網格。
你不需要為網格服務要使用的每個外部服務都添加服務入口。默認情況下,Istio 配置 Envoy 代理將請求傳遞給未知服務。但是,您不能使用 Istio 的特性來控制沒有在網格中注冊的目標流量。
Sidecar
默認情況下,Istio 讓每個 Envoy 代理都可以訪問來自和它關聯的工作負載的所有端口的請求,然后轉發到對應的工作負載。您可以使用 sidecar 配置去做下面的事情:
- 微調 Envoy 代理接受的端口和協議集。
- 限制 Envoy 代理可以訪問的服務集合。
你可能希望在較龐大的應用程序中限制這樣的 sidecar 可達性,配置每個代理能訪問網格中的任意服務可能會因為高內存使用量而影響網格的性能。
您可以指定將 sidecar 配置應用于特定命名空間中的所有工作負載,或者使用 workloadSelector 選擇特定的工作負載。
2.1.2 網絡彈性和測試
除了為你的網格導流,Istio 還提供了可選的故障恢復和故障注入功能,使你可以在運行時動態配置這些功能。使用這些特性可以讓應用程序運行穩定,確保服務網格能夠容忍故障節點,并防止局部故障級聯影響到其他節點。
超時
超時是 Envoy 代理等待來自給定服務的答復的時間量,以確保服務不會因為等待答復而無限期的掛起,并在可預測的時間范圍內調用成功或失敗。HTTP 請求的默認超時時間是 15 秒,這意味著如果服務在 15 秒內沒有響應,調用將失敗。
對于某些應用程序和服務,Istio 的缺省超時可能不合適。例如,超時太長可能會由于等待失敗服務的回復而導致過度的延遲;而超時過短則可能在等待涉及多個服務返回的操作時觸發不必要地失敗。為了找到并使用最佳超時設置,Istio 允許您使用虛擬服務按服務輕松地動態調整超時,而不必修改業務代碼。
重試
重試設置指定如果初始調用失敗,Envoy 代理嘗試連接服務的最大次數。通過確保調用不會因為臨時過載的服務或網絡等問題而永久失敗,重試可以提高服務可用性和應用程序的性能。重試之間的間隔(25ms+)是可變的,并由 Istio 自動確定,從而防止被調用服務被請求淹沒。HTTP 請求的默認重試行為是在返回錯誤之前重試兩次。
與超時一樣,Istio 默認的重試行為在延遲方面可能不適合您的應用程序需求(對失敗的服務進行過多的重試會降低速度)或可用性。您可以在虛擬服務中按服務調整重試設置,而不必修改業務代碼。您還可以通過添加每次重試的超時來進一步細化重試行為,并指定每次重試都試圖成功連接到服務所等待的時間量。
熔斷器
熔斷器是 Istio 為創建具有彈性的微服務應用提供的另一個有用的機制。在熔斷器中,設置一個對服務中的單個主機調用的限制,例如并發連接的數量或對該主機調用失敗的次數。一旦限制被觸發,熔斷器就會“跳閘”并停止連接到該主機。使用熔斷模式可以快速失敗而不必讓客戶端嘗試連接到過載或有故障的主機。
熔斷適用于在負載均衡池中的“真實”網格目標地址,您可以在目標規則中配置熔斷器閾值,讓配置適用于服務中的每個主機
故障注入
在配置了網絡,包括故障恢復策略之后,可使用 Istio 的故障注入機制來為整個應用程序測試故障恢復能力。故障注入是一種將錯誤引入系統以確保系統能夠承受并從錯誤條件中恢復的測試方法。使用故障注入特別有用,能確保故障恢復策略不至于不兼容或者太嚴格,這會導致關鍵服務不可用。
與其他錯誤注入機制(如延遲數據包或在網絡層殺掉 Pod)不同,Istio 允許在應用層注入錯誤。這使您可以注入更多相關的故障,例如 HTTP 錯誤碼,以獲得更多相關的結果。
可以注入兩種故障,它們都使用虛擬服務配置:
- 延遲
延遲是時間故障。它們模擬增加的網絡延遲或一個超載的上游服務。
- 終止
終止是崩潰失敗。他們模仿上游服務的失敗。終止通常以 HTTP 錯誤碼或 TCP 連接失敗的形式出現。
流量鏡像
流量鏡像,也稱為影子流量,是一個以盡可能低的風險為生產帶來變化的強大的功能。鏡像會將實時流量的副本發送到鏡像服務。鏡像流量發生在主服務的關鍵請求路徑之外。
在此任務中,首先把流量全部路由到 v1 版本的測試服務。然后,執行規則將一部分流量鏡像到 v2 版本。
2.2 可觀察性
可觀察性≠監控
監控是指從運維角度,被動地審視系統行為和狀態,是在系統之外探查系統的運行時狀態。而可觀察性是從開發者的角度主動地探究系統的狀態,開發過程中去考慮把哪些系統指標暴露出去。而在原始時期的我們都是通過日志查看系統運行時狀態,所以這也是一種理念創新。
組成
指標(Metrics)
通過聚合的數據來監測你的應用運行情況。為了監控服務行為,Istio 為服務網格中所有出入的服務流量都生成了指標。這些指標提供了關于行為的信息,例如總流量數、錯誤率和請求響應時間。
除了監控網格中服務的行為外,監控網格本身的行為也很重要。Istio 組件可以導出自身內部行為的指標,以提供對網格控制平面的功能和健康情況的洞察能力。
Istio 指標收集由運維人員配置來驅動。運維人員決定如何以及何時收集指標,以及指標本身的詳細程度。這使得它能夠靈活地調整指標收集來滿足個性化需求。Istio中的指標分類:
代理級別的指標( Proxy-level)
Istio 指標收集從 sidecar 代理(Envoy) 開始。每個代理為通過它的所有流量(入站和出站)生成一組豐富的指標。代理還提供關于它本身管理功能的詳細統計信息,包括配置信息和健康信息。
Envoy 生成的指標提供了資源(例如監聽器和集群)粒度上的網格監控。因此,為了監控 Envoy 指標,需要了解網格服務和 Envoy 資源之間的連接。
Istio 允許運維在每個工作負載實例上選擇生成和收集哪個 Envoy 指標。默認情況下,Istio 只支持 Envoy 生成的統計數據的一小部分,以避免依賴過多的后端服務,還可以減少與指標收集相關的 CPU 開銷。然而,運維可以在需要時輕松地擴展收集到的代理指標集。這支持有針對性地調試網絡行為,同時降低了跨網格監控的總體成本。
Envoy 文檔包括了 Envoy 統計信息收集的詳細說明。Envoy 統計里的操作手冊提供了有關控制代理級別指標生成的更多信息。
代理級別指標的例子:
- # 當前集群中來自于上游服務的總的請求數
- envoy_cluster_internal_upstream_rq{response_code_class="2xx",
- cluster_name="xds-grpc"} 7163
- # 上游服務完成的請求數量
- envoy_cluster_upstream_rq_completed{cluster_name="xds-grpc"} 7164
- # 是SSL連接出錯的數量
- envoy_cluster_ssl_connection_error{cluster_name="xds-grpc"} 0
服務級別的指標( Service-level)
監控服務通信的面向服務的指標。
- 四個基本的服務監控需求:延遲、流量、錯誤和飽和情況。Istio 帶有一組默認的儀表板,用于監控基于這些指標的服務行為。
- 默認的 Istio 指標由 Istio 提供的配置集定義并默認導出到 Prometheus。運維人員可以自由地修改這些指標的形態和內容,更改它們的收集機制,以滿足各自的監控需求。
收集指標任務為定制 Istio 指標生成提供了更詳細的信息。
- 服務級別指標的使用完全是可選的。運維人員可以選擇關閉指標的生成和收集來滿足自身需要。
服務級別指標的例子
- istio_requests_total{
- connection_security_policy="mutual_tls",
- destination_app="details",
- destination_principal="cluster.local/ns/default/sa/default",
- destination_service="details.default.svc.cluster.local",
- destination_service_name="details",
- destination_service_namespace="default",
- destination_version="v1",
- destination_workload="details-v1",
- destination_workload_namespace="default",
- reporter="destination",
- request_protocol="http",
- response_code="200",
- response_flags="-",
- source_app="productpage",
- source_principal="cluster.local/ns/default/sa/default",
- source_version="v1",
- source_workload="productpage-v1",
- source_workload_namespace="default"
- } 214
控制平面指標(Control plane )
每一個 Istio 的組件(Pilot、Galley、Mixer)都提供了對自身監控指標的集合。這些指標容許監控 Istio 自己的行為(這與網格內的服務有所不同)。
訪問日志
通過應用產生的事件來監控你的應用。訪問日志提供了一種從單個工作負載實例的角度監控和理解行為的方法。Istio 可以從一組可配置的格式集生成服務流量的訪問日志,為運維人員提供日志記錄的方式、內容、時間和位置的完全控制。Istio 向訪問日志機制暴露了完整的源和目標元數據,允許對網絡通信進行詳細的審查。
- 生成位置可選
訪問日志可以在本地生成,或者導出到自定義的后端基礎設施,包括 Fluentd。
- 日志內容
應用日志 Envoy 服務日志:kubectl logs -l app=demo -C istio-proxy
- {
- "level": "info",
- "time": "2019-06-11T20:57:35.424310Z",
- "instance": "accesslog.instance.istio-control",
- "connection_security_policy": "mutual_tls",
- "destinationApp": "productpage",
- "destinationIp": "10.44.2.15",
- "destinationName": "productpage-v1-6db7564db8-pvsnd",
- "destinationNamespace": "default",
- "destinationOwner": "kubernetes://apis/apps/v1/namespaces/default/deployments/productpage-v1",
- "destinationPrincipal": "cluster.local/ns/default/sa/default",
- "destinationServiceHost": "productpage.default.svc.cluster.local",
- "destinationWorkload": "productpage-v1",
- "httpAuthority": "35.202.6.119",
- "latency": "35.076236ms",
- "method": "GET",
- "protocol": "http",
- "receivedBytes": 917,
- "referer": "",
- "reporter": "destination",
- "requestId": "e3f7cffb-5642-434d-ae75-233a05b06158",
- "requestSize": 0,
- "requestedServerName": "outbound_.9080_._.productpage.default.svc.cluster.local",
- "responseCode": 200,
- "responseFlags": "-",
- "responseSize": 4183,
- "responseTimestamp": "2019-06-11T20:57:35.459150Z",
- "sentBytes": 4328,
- "sourceApp": "istio-ingressgateway",
- "sourceIp": "10.44.0.8",
- "sourceName": "ingressgateway-7748774cbf-bvf4j",
- "sourceNamespace": "istio-control",
- "sourceOwner": "kubernetes://apis/apps/v1/namespaces/istio-control/deployments/ingressgateway",
- "sourcePrincipal": "cluster.local/ns/istio-control/sa/default",
- "sourceWorkload": "ingressgateway",
- "url": "/productpage",
- "userAgent": "curl/7.54.0",
- "xForwardedFor": "10.128.0.35"
- }
分布式追蹤
通過追蹤請求來了解服務之間的調用關系,用于問題的排查以及性能分析。分布式追蹤通過監控流經網格的單個請求,提供了一種監控和理解行為的方法。追蹤使網格的運維人員能夠理解服務的依賴關系以及在服務網格中的延遲源。
Istio 支持通過 Envoy 代理進行分布式追蹤。代理自動為其應用程序生成追蹤 span,只需要應用程序轉發適當的請求上下文即可。
Istio 支持很多追蹤系統,包括 Zipkin、Jaeger、LightStep、Datadog。運維人員控制生成追蹤的采樣率(每個請求生成跟蹤數據的速率)。這允許運維人員控制網格生成追蹤數據的數量和速率。
更多關于 Istio 分布式追蹤的信息可以在分布式追蹤 FAQ 中找到。
Istio 為一個請求生成的分布式追蹤數據:
本文轉載自微信公眾號「JavaEdge」,可以通過以下二維碼關注。轉載本文請聯系JavaEdge公眾號。