Istio的流量管理(概念)

Istio的流量管理(概念)

目錄

• Istio的流量管理(概念)
  • 概述
  • Virtual services
    • 為什么使用virtual service
    • Virtual services舉例
      • hosts字段
    • 路由規則
      • match
      • destination
      • 路由規則優先級
      • 路由規則的更多介紹
  • Destination Rule
    • 負載均衡選項
    • Destination rule例子
  • Gateway
  • Service entries
  • Sidecars
  • 網絡彈性和測試
    • 超時
    • 重試
    • 斷路器
    • 故障注入
  • 與應用的配合
  • 總結

涵蓋istio官方文章的Traffic Management章節

概述

istio的流量路由規則可以簡單地控制不同服務間的流量以及API調用。Istio在服務層面提供了斷路器，超時，重試等功能，通過這些功能可以實現A/B測試，金絲雀發布，基於百分比的流量分割等，此外還提供了開箱即用的故障恢復功能，用於增加應用的健壯性，以應對服務故障或網絡故障。

istio的流量管理模型依賴Envoy代理，該代理作為sidecar與服務容器部署在同一個pod內，服務發送或接收的流量都會經過Envoy，這樣就可以在不改變服務的情況下實現網格中的流量管理。

為了直接管理網格中的流量，istio需要了解所有的endpoints，以及哪些service對應哪些endpoints，為了將這些信息推送到它的服務注冊表(service reistry)中，istio需要連接到一個服務發現系統，例如，當istio安裝到一個kubernetes集群時，istio會自動探測集群的services和endpoints。

service reistry：istio內部的服務注冊表，包含了service的集合以及service對應的endpoint信息。istio使用服務注冊表生成Envoy的配置信息。Pilot可以通過底層平台提供的服務發現機制實現自動注冊service，也可以通過ServiceEntry手動注冊service。

使用服務注冊表，Envoy代理可以將流量定向到相關的服務中。大多數基於微服務的應用會有多個實例，且每個實例處理一部分服務流量，這些實例有時也被稱為負載均衡池。默認情況下，Envoy代理會使用輪詢模式，通過服務的負載均衡池分發流量，此時會按照順序將請求發送到負載均衡池中的各個成員。

雖然istio的基本服務發現和負載均衡提供了一個可運行的服務網格，但istio的功能遠非如此。在大多數場景下，用戶可能想更好地控制網格的流量，如在A/B測試中，按照百分比將流量導入一個新版本的服務，或對某些服務實例應用不同的負載均衡策略，對進出網格的流量應用特殊的規則，或將網格的外部依賴項添加到服務注冊表中等。這些功能都可以通過istio的流量管理API，在istio中添加流量配置來實現。

跟其他istio配置相同，流量管理的API也使用CRD進行配置。下面介紹各個流量管理API的資源，以及這些API的功能。API資源包括：

• Virtual services
• Destination rules
• Gateways
• Service entries
• Sidecars

Virtual services

Virtual services和destination rules是istio流量路由功能的核心部分。virtual service允許(在用戶平台提供的基本連接和服務發現的基礎上)配置如何將一個請求路由到一個istio服務網格中的服務。每個virtual service都包含一個按順序處理的路由規則集，istio會通過這些規則將每個匹配virtual service的請求分發到網格中某個特定的目的地。根據需求可以使用多個或不使用virtual service。

為什么使用virtual service

virtual service將客戶端請求與目標負載進行解耦，通過這種方式，大大提升了istio流量管理的靈活性，並增強了流量管理的功能。virtual service還提供了大量方式來指定不同的流量路由規則，用於將流量發送到目標負載中。

如果沒有virtual service，Envoy會像前面介紹的那樣，在所有服務實例中采用輪詢負載均衡方式進行流量分發。使用virtual service后，用戶可以根據具體的負載做進一步動作。例如，某些負載可能代表不同版本的服務，這樣就可以用於A/B測試，將不同百分比的流量分發到不同版本的服務中，或直接將流量分發到特定的服務實例。

使用virtual service后，就可以為一個或多個主機名指定流量行為，使用virtual service中的路由規則告訴Envoy如何將virtual service的流量發送到合適的目的地。路由目的地可能對應相同或不同版本的服務。

一個典型的場景是將流量發送到不同版本的服務。客戶端將virtual service視為一個獨立的實體，並將請求發送到virtual service，Envoy會根據virtual service中的規則將流量路由到不同的版本：例如，"20%的調用分發到新版本"，或"將來自某些用戶的調用分發到版本2"。通過這種方式可以實現金絲雀發布。流量路由完全獨立於實例的部署，這意味着新版本的服務實例的數量可以根據流量負載擴大或縮小，而不必參考流量路由。相比之下，像Kubernetes這樣的容器編排平台只支持基於實例縮放的流量分布，這樣情況很快就會變得復雜。

Virtual services允許：

• 通過一個virtual service處理多個應用服務。如果網格使用了kubernetes，可以通過一個virtual service處理特定命名空間下的所有服務。通過將一個virtual service映射到多個"真實的"服務，可以方便地將單一應用程序轉換為由不同的微服務組成的復合服務，而無需服務的使用者去適應這種轉變(可以看作是kubernetes service之上的service)，例如可以將"到URI monolith.com的調用分發給 microservice A"。
• 將配置的流量規則與gataways進行結合來控制ingress和egress的流量。

在一些場景下還需要配置destination rule來使用這些特性，此時需要指定服務子集(subset)。在一個獨立的對象中指定服務子集和其他destination指定的策略(如負載均衡)，可以在不同的virtual service之間重用這些配置。

Virtual services舉例

下面是virtual service的一個例子，它根據路由規則將請求分發到不同版本的服務。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews #虛擬service，客戶端請求中的目的地址。內部訪問時與k8s service名稱相同；外部訪問內部時，與外部客戶端的目的地相同，內部訪問外部時，與內部客戶端的目的地相同。總之就是客戶端可達的目的地，istio對對攔截的請求進行解析
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews #對應kubernetes的service "reviews"，與DestinationRule的host相同，均為注冊到注冊中心的service表項
        subset: v2    #對應destination rule中的服務子集，有了subset就會用到DestinationRule
  - route:
    - destination:
        host: reviews
        subset: v3

hosts字段

hosts字段列出了virtual service的主機，即用戶可尋址的目標或路由規則應用的目標。它是客戶端向服務發送請求時使用的一個或多個地址，通過該字段提供的地址訪問virtual service，進而訪問后端服務。在集群內部(網格內)使用時通常與kubernetes的Service同命；當需要在集群外部(網格外)訪問時，該字段為gateway請求的地址，即與gateway的hosts字段相同，也可采用DNS的模糊匹配。

hosts:
- reviews

virtual service的主機名可以是IP地址、DNS名稱，也可以是短名稱(例如Kubernetes服務短名稱)，該名稱會被隱式或顯式解析為全限定域名（FQDN），具體取決於istio依賴的平台。可以使用前綴通配符（“*”）為所有匹配的服務創建一組路由規則。virtual service的hosts不一定是Istio服務注冊表的一部分，它們只是虛擬目的地，允許用戶為網格無法路由到的虛擬主機建立流量模型。

virtual service的hosts短域名在解析為完整的域名時，補齊的namespace是VirtualService所在的命名空間，而非Service所在的命名空間。如上例的hosts會被解析為：reviews.default.svc.cluster.local。

路由規則

http部分包含了virtual service的路由規則，描述了匹配條件，以及將HTTP/1.1，HTTP2和gRPC流量路由到hosts字段指定的目的地的相關動作(可以使用tcp和tls字段配置TCP路由規則和非終結TLS流量)。一個路由規則包含流量的目的地以及0個或多個條件，具體取決於實際的場景。

match

第一個路由規則的例子如下，它有一個以match字段開頭的條件，這種情況下希望路由來自用戶"jason"的所有請求，使用headers, end-user和exact 字段來選擇合適的請求。

- match:
   - headers:
       end-user:
         exact: jason

destination

路由的destination字段指定了匹配條件的流量的實際地址。與virtual service的主機不同，該host必須是存在於istio的服務注冊表(如kubernetes services，consul services等)中的真實目的地或由ServiceEntries聲明的hosts，否則Envoy不知道應該將流量發送到哪里。它可以是一個帶代理的網格服務或使用service entry添加的非網格服務。在kubernetes作為平台的情況下，host表示名為kubernetes的service名稱：

route:
- destination:
    host: reviews
    subset: v2

注意在本章的其他例子中使用kubernetes的短名稱作為destination的主機。當使用這種規則時，istio會根據包含路由規則的virtual service所在的命名空間添加域后綴，使用短名稱意味着可以在任意命名空間中應用這些規則(僅需簡單拷貝即可)。

Istio根據包含路由規則的虛擬服務的命名空間添加域后綴來獲取主機的完整的名稱。

只有當destination主機和virtual service在相同的kubernetes命名空間下面才會正常工作。由於kubernetes的短名稱可能會導致誤解，因此建議在生成環境中使用完整的主機名。

destination 字段也指定了期望請求的kubernetes的服務子集，上面例子中定義了名為v2的子集。

路由規則優先級

路由規則按從上到下的順序運行， virtual service定義的第一個規則具有最高的優先級。這種情況下當不匹配第一條規則時，會進行第二條規則的匹配，當第二條規則不匹配時，會進行第三條規則的匹配。

- route:
  - destination:
      host: reviews
      subset: v3

建議提供一個無需匹配的默認規則作為每個virtual service的最后一條規則，確保virtual service的流量能夠至少匹配到一條路由。

路由規則的更多介紹

正如上面描述的，可以通過設置路由規則將特定的流量分發到特定的目的地。例如，以下virtual service可以讓用戶將流量分發到兩個獨立的services(reviews和ratings)上，就像這兩個service是virtual service http://bookinfo.com/的一部分。virtual service的路由匹配規則基於請求的URLs，然后將請求分發到正確的service上。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo   #virtual service的名稱
spec:
  hosts:
    - bookinfo.com #virtual service的地址
  http:
  - match:         #匹配條件一
    - uri:
        prefix: /reviews
    route:         ##如果匹配條件一，則路由到真實的reviews服務上
    - destination:
        host: reviews
  - match:         #匹配條件二 
    - uri:
        prefix: /ratings
    route:         #如果匹配條件二，則路由到真實的ratings服務上
    - destination:
        host: ratings

對於一些匹配條件，用戶可以使用確切的值，前綴或正則表達式。

可以在相同的match塊中添加多個匹配條件，多個匹配條件之間的關系為AND；或在相同的規則中添加多個match塊，多個match之間的關系為OR。對於一個給定的virtual service，可以配置多個路由規則，者使得一個virtual serivce中的路由條件變得更加復雜或更加簡單。可以在HTTPMatchRequest reference中找到完整的match字段以及字段值。

除了使用匹配條件，還可以使用百分比的"權重"來分發流量，通常用於A/B測試和金絲雀發布。

spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 75
    - destination:
        host: reviews
        subset: v2
      weight: 25

此外還可以使用路由規則對流量采取某些動作，如：

• 追加或移除首部
• 重寫URL
• 對本目的地的調用設置重試策略

更多參見HTTPRoute reference

Destination Rule

destination rule是istio流量路由功能的重要組成部分。一個virtual service可以看作是如何將流量分發給特定的目的地，然后調用destination rule來配置分發到該目的地的流量。destination rule在virtual service的路由規則之后起作用(即在virtual service的math->route-destination之后起作用，此時流量已經分發到真實的service上)，應用於真實的目的地。

特別地，可以使用destination rule來指定命名的服務子集，例如根據版本對服務的實例進行分組，然后通過virtual service的路由規則中的服務子集將控制流量分發到不同服務的實例中。

destination rule允許在調用完整的目標服務或特定的服務子集(如傾向使用的負載均衡模型，TLS安全模型或斷路器)時自定義Envoy流量策略。更多參見Destination Rule reference。

負載均衡選項

istio默認會使用輪詢策略，此外istio也支持如下負載均衡模型，可以在destination rule中使用這些模型，將請求分發的特定的服務或服務子集。

• Random：將請求轉發到一個隨機的實例上
• Weighted：按照指定的百分比將請求轉發到實例上
• Least requests：將請求轉發到具有最少請求數目的實例上

更多參見Envoy load balancing documentation

Destination rule例子

下面的Destination rule使用不同的負載均衡策略為my-svc目的服務配置了3個不同的子集(subset)。host字段給出了規則作用的istio注冊表中的服務。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  host: my-svc # 規則作用的istio注冊表中的服務
  trafficPolicy:     #默認的負載均衡策略模型為隨機
    loadBalancer:
      simple: RANDOM
  subsets:        
  - name: v1  #subset1，將流量轉發到具有標簽version:v1的deployment對應的服務上
    labels:
      version: v1
  - name: v2  #subset2，將流量轉發到具有標簽version:v2的deployment對應的服務上,指定負載均衡為輪詢
    labels:
      version: v2
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
  - name: v3   #subset3，將流量轉發到具有標簽version:v3的deployment對應的服務上
    labels:
      version: v3

每個子集由一個或多個labels定義，對應kubernetes中的對象(如pod)的key/value對。這些標簽定義在kubernetes服務的deployment的metadata 中，用於標識不同的版本。

除了定義子集外，destination rule還定義了該目的地中所有子集的默認流量策略，以及僅覆蓋該子集的特定策略。默認的策略定義在subset字段上面，為v1和v3子集設置了隨機負載均衡策略，在v2策略中使用了輪詢負載均衡。

Gateway

gateway用於管理進出網格的流量，指定可以進入或離開網格的流量(Gateway既可以支持ingress流量，也可以支持egress流量)。gateway的配置應用於網格邊緣的獨立的Envoy代理上，而不是服務負載的Envoy代理上。

與其他控制進入系統的流量的機制(如kubernetes ingress API)不同，istio gateway允許利用istio的流量路由的強大功能和靈活性。istio的gateway資源允許配置4-6層的負載屬性，如暴露的端口，TLS配置等等，但結合istio的virtual service，就可以像管理istio網格中的其他數據面流量一樣管理gateway的流量。

gateway主要用於管理ingress流量，但也可以配置egress gateway。通過egress gateway可以配置流量離開網格的特定節點，限制哪些服務可以訪問外部網絡，或通過egress安全控制來提高網格的安全性。例如，可以將gateway配置為一個純粹的內部代理。

istio(通過istio-ingressgateway和istio-egressgateway參數)提供了一些預配置的gateway代理，default profile下僅會部署ingress gateway。gateway可以通過部署文件進行部署，也可以單獨部署。

下面是default profile默認安裝的ingress

$ oc get gateways.networking.istio.io -n istio-system
NAME                   AGE
istio-ingressgateway   4d20h

可以看到該ingress就是一個普通的pod，該pod僅包含一個istio-proxy容器

$ oc get pod -n istio-system |grep ingress
istio-ingressgateway-64f6f9d5c6-qrnw2   1/1     Running   0          4d20h

下面是一個gateway的例子，用於配置外部HTTPS的ingress流量：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:             #指定gateway配置下發的代理，如具有標簽app: my-gateway-controller的pod
    app: my-gateway-controller
  servers:
  - port:
      number: 443		# gateway pod監聽端口，當創建該gateway時，會在符合selector的pod中創建按一個443的監聽端口
      name: https
      protocol: HTTPS
    hosts:               #gateway暴露的主機地址
    - ext-host.example.com  
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

上述gateway配置監聽來自ext-host.example.com 流量進入網格的443端口，但沒有指定該流量的路由。(此時流量只能進入網格，但沒有指定處理該流量的服務，因此需要與virtual service進行綁定)

為了給gateway指定路由，需要通過virtual service的gateway字段，將gateway綁定到一個virtual service上，將來自ext-host.example.com流量引入一個VirtualService，hosts可以是通配符，表示引入匹配到的流量。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com #指定了處理gateway流量的目的地
  gateways:        #將gateway "ext-host-gwy"綁定到virtual service上，接收並處理來自gateway上的流量
  - ext-host-gwy

可以使用 / 格式引用其他命名空間的gateway，如果沒有指定命名空間，則默認使用與virtual service相同的命名空間，參見virtual service gateway字段 描述

Gateway的spec.servers.hosts與VirtualService的spec.hosts有匹配關系，具體參見gateway server描述

Service entries

可以看作是一個網格外部的virtual service，與kubernetes service流量方向相反。

使用service entry可以在istio內部維護的service registry中注冊一個表項。在添加service entry后，Envoy代理就可以將流量轉發到該服務上(就像服務是網格中的服務一樣)。配置service entry可以允許管理網格外的服務的流量，包括：

• 重定向和轉發到達外部目的地的流量，例如web使用的api，或者使用遺留基礎設施提供的服務。
• 為外部目的地定義重試，超時和故障注入策略
• 提供將vm添加到網格中，在VM中運行網格服務
• 在邏輯上將一個不同的集群添加到網格中，來在kubernetes上配置多集群istio網格。

無需為每個網格服務使用的外部服務添加service entry。默認下，istio僅會配置Envoy代理來轉發請求到無法識別的服務。如果一個目的地沒有注冊到網格中，則不能利用istio的特性來控制到該目的地的流量。

下面是一個通過service entry將外部服務ext-svc.example.com 添加到istio的service registry的例子：

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: svc-entry
spec:
  hosts:
  - ext-svc.example.com   #外部服務，與匹配的VirtualServices和DestinationRules中的hosts字段相同。將https://ext-svc.example.com:443認為是外部服務
  ports:                  #外部服務對應的端口
  - number: 443
    name: https
    protocol: HTTPS
  location: MESH_EXTERNAL #flag，表示該服務是網格外的服務
  resolution: DNS         #主機服務的發現模型

使用hosts字段可以是一個完整的域名，也可以是使用前綴通配符的域名。

• hosts 字段可以用於匹配VirtualServices 和DestinationRules.
• 對於HTTP流量， HTTP Host/Authority 首部字段將會與hosts 字段進行匹配
• 對於包含Server Name Indication (SNI)的HTTPS或TLS流量將會與hosts 字段進行匹配

resolution字段表示代理如何解析IP地址，有三種模式：

NONE	假設傳入的連接已經被解析(到一個特定的目的地IP地址)。通常使用諸如IPtable的REDIRECT / eBPF之類的機制通過代理路由此類連接。
STATIC	使用靜態IP給出與服務關聯的endpoints
DNS	使用DNS解析主機IP地址，通常根據本地DNS服務器(如k8s的DNS)來解析hosts和endpoints中的域名

可以使用virtual service和destination rule來控制到達一個service entry的流量。例如，下面destination rule配置了流量路由使用mutual TLS來加密到達外部服務ext-svc.example.com間的連接。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ext-res-dr
spec:
  host: ext-svc.example.com #此處的host為serviceEntry注冊到注冊中心的服務
  trafficPolicy:
    tls:
      mode: MUTUAL
      clientCertificate: /etc/certs/myclientcert.pem
      privateKey: /etc/certs/client_private_key.pem
      caCertificates: /etc/certs/rootcacerts.pem

Sidecars

默認情況下，istio會配置每個Envory代理來接收與其關聯的負載的(所有端口上的)流量，以及在轉發流量時將流量分發到網格中的每個負載。使用sidecar可以實現如下功能：

• 對Envoy代理接受的端口和協議集進行調優
• 限制Envoy代理可以訪問的服務集

在大型應用中，如果在每個服務都經過sidecar代理，可能會因為內存過高而影響網格的性能，這種情況下，可能需要限制sidecar的可達性。

可以將sidecar配置到某個特定的命名空間中，或通過workloadSelector選擇特定的負載。例如，下面的sidecar配置將bookinfo命名空間中的所有服務配置為：僅訪問在同一命名空間和Istio控制平面的服務。

sidecar配置僅能影響到該配置所在的命名空間

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo #sidecar所在的命名空間
spec:
  egress:             #限制bookinfo能夠訪問的egress 
  - hosts:            #使用namespace/dnsName格式的監聽器，參見https://istio.io/docs/reference/config/networking/sidecar/#IstioEgressListener
    - "./*"
    - "istio-system/*"

網絡彈性和測試

除了可以幫助引導網格周圍的流量，Istio還提供可選的故障恢復和故障注入功能。可以在運行時動態配置這些功能。使用這些特性可以幫助增強應用的可靠性，保證服務網格能夠容忍節點失敗，以及防止本地化故障級聯到其他節點。

超時

timeout是Envoy代理在等待給定服務響應前的時間，保證不會無限等待服務的響應，最后返回成功或超時后返回失敗。istio默認禁用HTTP請求的Envoy超時。

對於一些應用和服務，istio的默認超時可能不大合適。例如，超時過長可能會在有失敗的服務下出現大量延時，而超時過短可能會導致不必要的調用失敗(如調用鏈比較長)。為了優化超時設置，istio允許使用virtual service動態調整每個服務的超時，而無需修改服務代碼。下面virtual service將ratings 服務的v1服務子集的超時設置為10s。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

重試

與timeout類似，可以在virtual service中設置單個服務的重試配置。下面例子中配置的最大重試次數為3，每次超時時間為2s。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

斷路器

斷路器是istio提供的另一種構建彈性微服務的機制。在斷路器中，可以設置對服務中單個主機的調用限制，如限制到一台主機的並發連接數，或限制到一台主機的調用失敗的次數，一旦達到限制值，斷路器或發出告警並停止連接這台主機。

由於斷路器會作用到負載均衡池中的真實網格目標，可以在destination rules中配置斷路器閾值，該設置作用到服務中的每個主機。下面例子限制了reviews服務負載的v1服務子集的最大並發連接數為100。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

故障注入

在配置完網絡，包括故障恢復策略后，可以使用istio的故障注入機制來測試應用的故障恢復能力。故障注入是一個測試機制，將錯誤引入到一個系統來保證系統能夠承受該錯誤支持錯誤恢復。使用故障注入可以特別有助於確保不會因為故障恢復策略的兼容性和限制性而導致關鍵服務不可用。

與在網絡層面引入延遲報文或殺死pod不同，istio允許在應用層注入故障，如通過注入HTTP錯誤碼來獲取相關的結果。

使用virtual service可以注入兩種類型的故障：

• 延遲：時間故障。用於模擬增加的網絡延遲或超載的上游服務
• 中斷：崩潰故障。用於模擬上游服務故障，通常以HTTP錯誤代碼或TCP連接失敗的形式出現。

下面例子中，使用virtual service注入故障，對ratings服務的訪問請求中，每1000個請求中就有一個5s的延遲。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1 #對1/1000的流量注入5s的延時
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

與應用的配合

istio的故障恢復功能對應用來說是完全透明的。一個應用無法知道一個Envoy sidecar代理是否為一個被調用的服務配置了失敗處理功能。這意味着如果在應用代理中設置了故障恢復策略，則需要注意這兩個策略是相互獨立的，有可能發送沖突。例如，假設有兩個超時設置，一個配置在virtual service中，一個配置在應用中。應用為調用某個服務的API設置的超時為2s；而virtual service中設置的超時為3s，重試次數為1。這種情況下，應用首先會發送超時，Envoy的超時和重試將失效。

雖然istio的故障恢復功能提升了網格中服務的可靠性和可用性，但應用仍然需要處理故障或錯誤，並做出相應動作。例如，當一個負載均衡池中的所有實例都失敗后，Envoy會返回HTTP 503錯誤，應用必須實現對HTTP 503錯誤碼做出反饋。

總結

• istio的VirtualService主要進行流量路由和故障注入，請求超時等；DestinationRule用於對路由的流量進行更細化的配置；ServiceEntry用於注冊外部服務。如果不需要VirtualService提供的功能，DestinationRule和ServiceEntry都可以單獨使用，將流量分發到注冊的host即可。
• VirtualService+DestinationRule可以進行流量路由，並將流量分發到注冊中心中存在的service或ServiceEntry聲明的hosts上
• VirtualService+DestinationRule+Gateway可以將外部請求的流量引入網格內，外部流量會通過Gateway指定的ingress Pod進入網格，然后使用VirtualService+DestinationRule進行流量控制
• VirtualService+DestinationRule+ServiceEntry可以將網格內部請求的流量通過sidecar代理轉發到網格外部
• VirtualService+DestinationRule+ServiceEntry+Gateway可以將網格內部請求的流量通過sidecar代理轉發到指定egress網關，轉發到網格外部