溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要講解了“Istio熔斷器怎么使用”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Istio熔斷器怎么使用”吧！
Istio因靈活的可觀察性和安全的服務間通信受到了贊許。然而，其他更重要的功能才真正使得Istio成為了服務網格里的瑞士軍刀，當遇到運行時長、延遲和錯誤率等SLO問題時，服務間的流量管理能力是至關重要的。
在今年早些時候發布 Istio operator 時，我們的目標（除了管理Istio的安裝和升級）是為這些出色的流量路由特性提供支持，同時使所有的功能都更加易用。最后，我們創建了一個簡單且自動化的服務網格Backyards，它在Istio operator之上提供了管理UI、CLI 和GraphQL API的能力。Backyards集成到了Banzai Cloud的容器管理平臺 Pipeline中，也可以作為一個單一的產品獨立工作。當然，將Backyards與Pipeline一起使用會為用戶提供特別的好處（比如在多云和混合云環境中管理應用程序），Backyards也可以被用于任何Kubernetes的安裝環境。
在微服務架構中，服務可能會用不同的語言實現并部署在多個節點或集群上，具有不同的響應時間或故障率。如果服務成功（并且及時地）響應了請求，那么它的性能就算是令人滿意的。但現實情況并非如此，下游客戶端應該在上游服務過于緩慢時受到保護。反之，上游服務也必須被保護，以免被積壓的請求拖垮。在多客戶端下情況會更加復雜，并可能導致整個基礎設施出現一系列的連鎖故障。這一問題的解決方案是采用經過時間檢驗的熔斷器模式。
一個熔斷器可以有三種狀態：關閉、打開和半開，默認情況下處于關閉狀態。在關閉狀態下，無論請求成功或失敗，到達預先設定的故障數量閾值前，都不會觸發熔斷。而當達到閾值時，熔斷器就會打開。當調用處于打開狀態的服務時，熔斷器將斷開請求，這意味著它會直接返回一個錯誤，而不去執行調用。通過在客戶端斷開下游請求的方式，可以在生產環境中防止級聯故障的發生。在經過事先配置的超時時長后，熔斷器進入半開狀態，這種狀態下故障服務有時間從其中斷的行為中恢復。如果請求在這種狀態下繼續失敗，則熔斷器將再次打開并繼續阻斷請求。否則熔斷器將關閉，服務將被允許再次處理請求。
Istio的 熔斷 可以在 流量策略 中配置。Istio的 自定義資源Destination Rule里，TrafficPolicy字段下有兩個和熔斷相關的配置： ConnectionPoolSettings 和 OutlierDetection。
ConnectionPoolSettings可以為服務配置連接的數量。OutlierDetection用來控制從負載均衡池中剔除不健康的實例。
例如，ConnectionPoolSettings控制請求的最大數量，掛起請求，重試或者超時；OutlierDetection 設置服務被從連接池剔除時發生錯誤的請求數，可以設置最小逐出時間和最大逐出百分比。有關完整的字段列表，請參考文檔.
Istio在底層使用了Envoy的熔斷特性。
讓我們來看看Destination Rule中有關熔斷的配置：
apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: notifications spec: host: notifications trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutiveErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100
使用ConnectionPoolSettings字段中的這些設置，在給定的時間內只能和notifications 服務建立一個連接：每個連接最多只能有一個掛起的請求。如果達到閾值，熔斷器將開始阻斷請求。
OutlierDetection部分的設置用來檢查每秒調用服務是否有錯誤發生。如果有，則將服務從負載均衡池中逐出至少三分鐘（100%最大彈出百分比表示，如果需要，所有的服務實例都可以同時被逐出）。
在手動創建
Destination Rule資源時有一件事需要特別注意，那就是是否為該服務啟用了mTLS。如果是的話，還需要在Destination Rule中設置如下字段，否則當調用movies服務時，調用方可能會收到503錯誤：
trafficPolicy: tls: mode: ISTIO_MUTUAL
還可以為特定namespace 或特定服務啟用全局的mTLS。你應該了解這些設置以便確定是否把
trafficPolicy.tls.mode設置為ISTIO_MUTUAL。更重要的是，當你試圖配置一個完全不同的功能（例如熔斷）時，很容易忘記設置此字段。提示：在創建
Destination Rule前總是考慮mTLS！
為了觸發熔斷，讓我們同時從兩個連接來調用 notifications服務。maxConnections字段被設置為1。這時應該會看到503與200的響應同時到達。
當一個服務從客戶端接收到的負載大于它所能處理的負載（如熔斷器中配置的那樣），它會在調用之前返回503錯誤。這是防止錯誤級聯的一種方法。
在生產環境中必須要監控你的服務，以便得到通知并能夠在系統發生錯誤時進行檢查。因此，如果你已經為你的服務配置了一個熔斷器，你就會想知道它什么時候跳閘；熔斷器攔截了百分之多少的請求；何時觸發，來自哪個下游客戶端？如果能夠回答這些問題，你就可以確定熔斷器是否工作正常，并根據需要微調配置，或者優化服務來處理額外的并發請求。
提示：如果你繼續閱讀，可以在Backyards UI中看到和配置所有的這些設置。
讓我們看看怎樣在Istio里確定熔斷器跳閘：
熔斷器跳閘時的響應碼是503，因此你無法僅根據該響應與其他的503錯誤區分開來。在Envoy中，有一個計數器叫upstream_rq_pending_overflow，它記錄了熔斷且失敗的請求總數。如果為你的服務深入研究Envoy的統計數據就可以獲得這些信息，但這并不容易。
除了響應代碼，Envoy還返回響應標志 ，并且存在一個專用響應標志來表示熔斷器跳閘：UO。如果這個標志只能通過Envoy的日志獲得，這將不會特別有用。幸運的是，它在Istio中實現了，因此響應標志在Istio指標中是可用的并且能被Prometheus獲取到。
熔斷器的跳閘可以像這樣查詢到：
sum(istio_requests_total{response_code="503", response_flags="UO"}) by (source_workload, destination_workload, response_code)使用Backyards時，你不需要手動編輯Destination Rules來設置熔斷。可以通過一個方便的UI界面或者（如果你愿意的話）是Backyards CLI 命令行工具來達到相同的結果。
不必擔心由于忘記把trafficPolicy.tls.mode 設置為 ISTIO_MUTUAL而配錯了Destination Rules。Backyards會為你解決這個問題；它會找到啟用了mTLS的服務并相應地設置上述字段。
上面只是Backyards驗證特性的一個例子，這能避免你設置錯誤。后面還有更多的特性。
在此之上，你可以看到服務和請求的可視化界面和活動儀表板，因此可以輕松地確定有多少請求被熔斷器觸發，以及它來自哪個調用者和何時觸發。
首先，我們需要一個Kubernetes集群。
我通過Pipeline platform的免費開發版本在GKE上創建了一個Kubernetes集群。如果你也想這樣做，可以在我們支持的五個云提供商或使用Pipeline在本地創建集群。否則，你需要提供自己的Kubernetes集群。
在一個新集群安裝Istio，Backyards和demo應用的最簡單的辦法是使用Backyards CLI。
你只需要執行下面的命令（集群必須設置了KUBECONFIG）：
$ backyards install -a --run-demo
該命令首先使用我們開源的Istio operator安裝Istio，然后安裝Backyards和demo應用程序。安裝完成后，Backyards UI將自動打開并向demo應用發送一些流量。通過這個簡單的命令，你可以看到Backyards在幾分鐘內啟動了一個全新的Istio集群！試試吧！
你也可以按順序執行所有這些步驟。Backyards需要一個Istio集群——如果沒有，可以通過
$ backyards istio install安裝。一旦安裝了Istio，就可以使用$ backyards install安裝Backyards。最后，使用$ backyards demoapp install部署demo應用程序。提示：Backyards是Pipeline平臺的核心組件——可以嘗試開發者版本（Service Mesh 標簽頁）。
你不需要手動創建或編輯Destination Rule，可以很容易的在UI界面中改變熔斷的配置。讓我們先創建一個demo。
正如你將看到的，Backyards（與Kiali相比）不僅是為可觀察性構建的web UI，而且是具有豐富功能的服務網格管理工具，支持單集群和多集群，并且具有強大的CLI和GraphQL API。
你不需要通過Destination Rule（例如通過kubectl）來查看熔斷器的配置，當你點擊notification 服務圖標并切換SHOW CONFIGS滑塊時，可以在Backyards UI的右側看到它們。
根據剛才的設置，當兩個連接同時產生流量時，熔斷器將發出跳閘請求。在Backyards UI中，你將看到圖形的邊緣出現了紅色。如果單擊該服務，你將了解有關錯誤的更多信息，并將看到兩個專門用來顯示熔斷器跳閘的實時Grafana儀表板。
第一個儀表板展示了熔斷器觸發的總請求的百分比。當沒有熔斷器錯誤，而你的服務工作正常，這張圖將顯示0%。否則，你將能夠立即看到有多少請求被熔斷器觸發。
第二個儀表板提供了由源熔斷器引起的跳閘故障。如果沒有發生跳閘，則此圖中不會出現尖峰。否則，你將看到哪個服務導致了跳閘，何時跳閘，以及跳閘次數。可以通過此圖來追蹤惡意的客戶端。
這些是實時的Grafana儀表盤，用于顯示熔斷相關的信息。在默認情況下Backyards集成了Grafana和Prometheus——還有更多的儀表板可以幫助你深入查看服務的指標。
可以通過 Remove 按鈕很容易的移除熔斷配置。
這個視頻總結了所有這些UI操作（譯者注：視頻來自YouTube）
從經驗來看，可以從UI界面做的事一定也可以通過 Backyards CLI 命令行工具完成。
讓我們再做一次創建熔斷的測試，這次通過CLI命令行。
可以以交互模式進行：
$ backyards r cb set backyards-demo/notifications ? Maximum number of HTTP1/TCP connections 1 ? TCP connection timeout 3s ? Maximum number of pending HTTP requests 1 ? Maximum number of requests 1024 ? Maximum number of requests per connection 1 ? Maximum number of retries 1024 ? Number of errors before a host is ejected 1 ? Time interval between ejection sweep analysis 1s ? Minimum ejection duration 3m ? Maximum ejection percentage 100 INFO[0043] circuit breaker rules successfully applied to 'backyards-demo/notifications' Connections Timeout Pending Requests Requests RPC Retries Errors Interval Ejection time percentage 1 3s 1 1024 1 1024 1 1s 3m 100
或者用非交互模式，指定要設置的值：
$ backyards r cb set backyards-demo/notifications --non-interactive --max-connections=1 --max-pending-requests=1 --max-requests-per-connection=1 --consecutiveErrors=1 --interval=1s --baseEjectionTime=3m --maxEjectionPercent=100 Connections Timeout Pending Requests Requests RPC Retries Errors Interval Ejection time percentage 1 3s 1 1024 1 1024 5 1s 3m 100
命令執行后，熔斷配置會立刻獲取到并顯示出來。
你可以用下面的命令通過namespace來列出熔斷的設置：
$ backyards r cb get backyards-demo/notifications Connections Timeout Pending Requests Requests RPC Retries Errors Interval Ejection time percentage 1 3s 1 1024 1 1024 5 1s 3m 100
默認情況結果以表格的方式顯示，也支持JSON或者YMAL格式：
$ backyards r cb get backyards-demo/notifications -o json
{
"maxConnections": 1,
"connectTimeout": "3s",
"http1MaxPendingRequests": 1,
"http2MaxRequests": 1024,
"maxRequestsPerConnection": 1,
"maxRetries": 1024,
"consecutiveErrors": 5,
"interval": "1s",
"baseEjectionTime": "3m",
"maxEjectionPercent": 100
}
$ backyards r cb get backyards-demo/notifications -o yaml
maxConnections: 1
connectTimeout: 3s
http1MaxPendingRequests: 1
http2MaxRequests: 1024
maxRequestsPerConnection: 1
maxRetries: 1024
consecutiveErrors: 5
interval: 1s
baseEjectionTime: 3m
maxEjectionPercent: 100要從CLI中查看和前面Grafana UI界面類似的儀表板，可以通過從多個連接調用服務來觸發跳閘，執行命令：
$ backyards r cb graph backyards-demo/notifications
可以看到類似下面的結果：
移除熔斷執行下面的命令：
$ backyards r cb delete backyards-demo/notifications INFO[0000] current settings Connections Timeout Pending Requests Requests RPC Retries Errors Interval Ejection time percentage 1 3s 1 1024 1 1024 5 1s 3m 100 ? Do you want to DELETE the circuit breaker rules? Yes INFO[0008] circuit breaker rules set to backyards-demo/notifications successfully deleted
使用下面的命令驗證是否成功：
$ backyards r cb get backyards-demo/notifications INFO[0001] no circuit breaker rules set for backyards-demo/notifications
Backyards由多個組件組成，比如Istio、Banzai Cloud的Istio operator，多集群Canary release operator，以及多個后端基礎設施。所有的這些都在Backyards’ GraphQL API的后面。
Backyards UI和CLI都使用Backyards的GraphQL API，它將在9月底與GA版本一起發布。用戶將很快能夠使用我們的工具來管理Istio和構建他們自己的客戶端。
從你的集群移除demo應用、Backyards和Istio，執行下面的命令，它將按順序卸載這些組件：
$ backyards uninstall -a
感謝各位的閱讀，以上就是“Istio熔斷器怎么使用”的內容了，經過本文的學習后，相信大家對Istio熔斷器怎么使用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
