istio-0.8 規則配置官方案例

時間 2019-11-26

標籤 istio 0.8 規則配置官方案例简体版

原文原文鏈接

Istio提供了一個簡單的配置模型來控制API調用和第4層流量如何跨應用程序部署中的各類服務流動。配置模型容許操做員配置服務級屬性，例如斷路器，超時，重試，以及設置常見的連續部署任務，例如金絲雀推出，A / B測試，基於％的流量分割的分階段推出等。算法

例如，可使用以下配置來描述將評論服務的100％傳入流量發送到版本「v1」的簡單規則：後端

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

此配置表示發送到評論服務（在hosts字段中指定）的流量應路由到基礎評論服務實例的v1子集。路由subset指定相應目標規則配置中已定義子集的名稱：api

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

子集指定一個或多個標識特定於版本的實例的標籤。例如，在Istio的Kubernetes部署中，「version：v1」表示只有包含標籤「version：v1」的pod纔會收到流量。服務器

可使用istioctl CLI配置規則，也可使用命令在Kubernetes部署中配置規則kubectl，儘管只會istioctl執行模型驗證並建議使用。有關示例，請參閱配置請求路由任務。cookie

Istio中有四種流量管理配置資源：VirtualService，DestinationRule，ServiceEntry和Gateway。下面描述了這些資源的一些重要方面。有關詳細信息，請參閱網絡參考網絡

虛擬服務

甲VirtualService定義了控制如何用於服務請求的服務Istio網格內路由的規則。例如，虛擬服務能夠將請求路由到不一樣版本的服務，或者其實是將請求路由到與請求徹底不一樣的服務。能夠根據請求源和目標，HTTP路徑和標頭字段以及與各個服務版本關聯的權重來路由請求。架構

規則目的地

路由規則對應於VirtualService配置中指定的一個或多個請求目標主機。這些主機可能與實際目標工做負載相同或不一樣，甚至可能不對應於網格中的實際可路由服務。例如，要使用其內部網格名稱或經過主機爲審閱服務定義請求的路由規則，可使用以下字段：reviewsbookinfo.comVirtualServicehostsapp

hosts: - reviews - bookinfo.com

該hosts字段隱式或顯式指定一個或多個徹底限定的域名（FQDN）。reviews上面的短名稱將隱式擴展爲特定於實現的FQDN。例如，在Kubernetes環境中，全名是從VirtualSevice（例如reviews.default.svc.cluster.local）的集羣和名稱空間派生的。負載均衡

按源/標頭限定規則

能夠選擇將規則限定爲僅應用於符合某些特定條件的請求，例如：tcp

1.限制爲特定呼叫者。例如，規則能夠指示它僅適用於來自實現評論服務的工做負載（pod）的調用。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: sourceLabels: app: reviews ...

值sourceLabels取決於服務的實現。例如，在Kubernetes中，它可能與相應Kubernetes服務的pod選擇器中使用的標籤相同。

2.限制到呼叫者的特定版本。例如，如下規則將前一個示例簡化爲僅應用於評論服務的版本「v2」的調用。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 ...

3.根據HTTP標頭選擇規則。例如，若是傳入請求包含包含子字符串「user = jason」的「cookie」標頭，則如下規則將僅適用於傳入請求。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

若是提供了多個標頭，則全部相應的標頭必須匹配才能應用規則。

能夠同時設置多個標準。在這種狀況下，取決於嵌套，應用AND或OR語義。若是多個條件嵌套在單個匹配子句中，則條件爲AND。例如，如下規則僅適用於請求的來源是「reviews：v2」而且存在包含「user = jason」的「cookie」標題。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

相反，若是條件出如今單獨的匹配子句中，則只能應用其中一個條件（OR語義）：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 - headers: cookie: regex: "^(.*?;)?(user=jason)(;.*)?$" ...

在服務版本之間拆分流量

每一個路由規則標識在激活規則時要調用的一個或多個加權後端。每一個後端對應於目標服務的特定版本，其中版本可使用標籤表示。若是存在多個具備指定標籤的已註冊實例，則它們將根據爲服務配置的負載平衡策略進行路由，或者默認爲循環。

例如，如下規則會將評論服務的25％流量路由到具備「v2」標籤的實例，將剩餘流量（即75％）路由到「v1」。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v1 weight: 75 - destination: host: reviews subset: v2 weight: 25

超時和重試

默認狀況下，http請求的超時爲15秒，但這能夠在路由規則中覆蓋，以下所示：

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

也能夠在路由規則中指定給定http請求的重試次數。能夠按以下方式設置最大嘗試次數，或者在默認或覆蓋的超時期限內儘量多的嘗試次數：

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

請注意，還能夠基於每一個請求覆蓋請求超時和重試。

有關超時控制的演示，請參閱請求超時任務。

在請求路徑中注入錯誤

路由規則能夠指定在將http請求轉發到規則的相應請求目的地時要注入的一個或多個故障。故障能夠是延遲或停止。

如下示例將向評級微服務的「v1」版本的10％請求中引入5秒延遲。

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

另外一種故障停止可用於過早終止請求，例如，模擬故障。

如下示例將向評級服務「v1」返回10％請求的HTTP 400錯誤代碼。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1

有時延遲和停止故障一塊兒使用。例如，如下規則將審覈服務「v2」的全部請求延遲5秒到評級服務「v1」，而後停止10％：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - match: - sourceLabels: app: reviews version: v2 fault: delay: fixedDelay: 5s abort: percent: 10 httpStatus: 400 route: - destination: host: ratings subset: v1

要查看故障注入操做，請參閱故障注入任務。

HTTP路由規則優先

當給定目的地有多個規則時，它們按照它們出現的順序進行評估VirtualService，即列表中的第一個規則具備最高優先級。

爲何優先重要？每當特定服務的路由故事純粹基於權重時，就能夠在單個規則中指定。另外一方面，當使用其餘標準（例如，來自特定用戶的請求）來路由流量時，將須要不止一個規則來指定路由。這是必須仔細考慮規則優先級的地方，以確保以正確的順序評估規則。

廣義路由規範的一種常見模式是提供一個或多個更高優先級的規則，這些規則經過源/頭限定規則，而後提供單個基於權重的規則，最後沒有匹配條件，以提供全部其餘狀況的流量的加權分佈。

例如，如下VirtualService包含2個規則，它們一塊兒指定對包含名爲「Foo」且值爲「bar」的標題的評論服務的全部請求將被髮送到「v2」實例。全部剩餘的請求將被髮送到「v1」。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - match: - headers: Foo: exact: bar route: - destination: host: reviews subset: v2 - route: - destination: host: reviews subset: v1

請注意，基於標頭的規則具備更高的優先級。若是它較低，這些規則將沒法按預期工做，由於基於權重的規則（沒有特定的匹配標準）將首先進行評估，而後將全部流量簡單地路由到「v1」，甚至包括匹配「Foo」的請求「頭。一旦找到適用於傳入請求的規則，它將被執行而且規則評估過程將終止。這就是爲何在存在多個規則時仔細考慮每一個規則的優先級很是重要的緣由。

目標規則

一個DestinationRule配置組策略後應用的請求VirtualService已經發生路由。它們旨在由服務全部者編寫，描述斷路器，負載平衡器設置，TLS設置等。

A DestinationRule還定義subsets了相應目標主機的可尋址（即，命名版本）。VirtualService在將流量發送到特定版本的服務時，這些子集用於路由規範。

如下DestinationRule配置評論服務的策略和子集：

apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host: reviews trafficPolicy: loadBalancer: simple: RANDOM subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 trafficPolicy: loadBalancer: simple: ROUND_ROBIN - name: v3 labels: version: v3

請注意，能夠在單個DestinationRule配置中指定多個策略（例如，默認和特定於v2）。

斷路器

能夠根據許多標準（例如鏈接和請求限制）設置簡單的斷路器。

例如，如下DestinationRule設置對評論服務版本「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

有關斷路器控制的演示，請參閱斷路任務。

DestinationRule評估

與路由規則相似，策略與特定主機相關聯，但若是它們是特定於子集，則激活取決於路由規則評估結果。

規則評估過程當中的第一步評估VirtualService對應於所請求主機的路由規則（若是有任何已定義的），以肯定當前請求將被路由到的目標服務的子集（即，特定版本）。接下來，評估與所選子集相對應的策略集（若是有的話）以肯定它們是否適用。

注意：要記住的算法的一個細微之處在於，只有在明確路由到相應的子集時，纔會應用爲特定子集定義的策略。例如，考慮如下配置，做爲爲評論服務定義的惟一規則（即，相應的路由規則中沒有路由規則）VirtualService。

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

因爲沒有爲評論服務定義特定的路由規則，所以將應用默認的循環路由行爲，有時可能會調用「v1」實例，若是「v1」是惟一運行的版本，甚至可能老是如此。然而，因爲默認路由是在較低級別完成的，所以永遠不會調用上述策略。規則評估引擎將不知道最終目標，所以沒法將子集策略與請求匹配。

您能夠經過如下兩種方式之一修復上述示例。您能夠將流量策略上移一級以使其適用於任何版本：

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

或者，更好的是，爲服務定義正確的路由規則。例如，您能夠爲「reviews：v1」添加簡單的路由規則。

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

雖然默認的Istio行爲能夠方便地將流量從任何源發送到目標服務的全部版本而不設置任何規則，但只要須要版本區分，就須要規則。所以，從一開始就爲每一個服務設置默認規則一般被認爲是Istio中的最佳實踐。

服務條目

一個ServiceEntry用於添加額外的條目成Istio內部維護的服務註冊。它最經常使用於啓用對Istio服務網格以外的服務的請求。例如，如下內容ServiceEntry可用於容許外部調用*.foo.com域下託管的服務。

apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: foo-ext-svc spec: hosts: - *.foo.com ports: - number: 80 name: http protocol: HTTP - number: 443 name: https protocol: HTTPS

ServiceEntry使用該hosts字段指定a的目標，該字段能夠是徹底限定域名或通配符域名。它表示容許訪問網格中的服務的一個或多個服務的白名單集。

A ServiceEntry不限於外部服務配置，它能夠有兩種類型：網狀內部或網狀外部。網狀內部條目與全部其餘內部服務相似，但用於向網格顯式添加服務。它們可用於添加服務，做爲擴展服務網格的一部分，以包括非託管基礎架構（例如，添加到基於Kubernetes的服務網格的VM）。網格外部條目表示網格外部的服務。對於他們來講，mTLS身份驗證被禁用，而且在客戶端執行策略實施，而不是在一般的服務器端執行內部服務請求。

只要服務條目使用匹配引用服務，服務條目就能夠與虛擬服務和目標規則結合使用hosts。例如，如下規則可與上述ServiceEntry規則結合使用，爲外部服務的調用設置10秒超時bar.foo.com。

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bar-foo-ext-svc spec: hosts: - bar.foo.com http: - route: - destination: host: bar.foo.com timeout: 10s

外部目的地支持重定向和轉發流量，定義重試，超時和故障注入策略的規則。然而，加權（基於版本）路由是不可能的，由於沒有外部服務的多個版本的概念。

有關訪問外部服務的更多信息，請參閱出口任務。

網關

甲網關配置HTTP / TCP流量負載平衡器，在網格的邊緣最經常使用操做，以實現入口流量爲應用程序。

與Kubernetes Ingress不一樣，Istio Gateway僅配置L4-L6功能（例如，要暴露的端口，TLS配置）。而後，用戶可使用標準的Istio規則來控制HTTP請求以及Gateway經過綁定VirtualService到它來進入的TCP流量。

例如，如下簡單Gateway配置負載均衡器以容許主機的外部https流量bookinfo.com進入網格：

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway spec: servers: - port: number: 443 name: https protocol: HTTPS hosts: - bookinfo.com tls: mode: SIMPLE serverCertificate: /tmp/tls.crt privateKey: /tmp/tls.key

要配置相應的路由，VirtualService必須爲同一主機定義a 並綁定到Gateway使用gateways配置中的字段：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - bookinfo.com gateways: - bookinfo-gateway # <---- bind to gateway http: - match: - uri: prefix: /reviews route: ...

有關完整的入口網關示例，請參閱入口任務。

雖然主要用於管理入口流量，Gateway但也可用於模擬純內部或出口代理。不管位置如何，全部網關均可以以相同的方式進行配置和控制。有關詳細信息，請參閱網關參考。

https://istio.io/docs/concepts/traffic-management/rules-configuration/

總結：

Istio中有四種流量管理配置資源：VirtualService，DestinationRule，ServiceEntry和Gateway

VirtualService：

VirtualService定義了控制如何用於服務請求的服務Istio網格內路由的規則。例如，虛擬服務能夠將請求路由到不一樣版本的服務，或者其實是將請求路由到與請求徹底不一樣的服務。能夠根據請求源和目標，HTTP路徑和標頭字段以及與各個服務版本關聯的權重來路由請求。