kubernetes中如何實現(xiàn)Istio流量管理-創(chuàng)新互聯(lián)

這篇文章主要為大家展示了“kubernetes中如何實現(xiàn)Istio流量管理”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“kubernetes中如何實現(xiàn)Istio流量管理”這篇文章吧。

站在用戶的角度思考問題，與客戶深入溝通，找到廉江網(wǎng)站設計與廉江網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設計與互聯(lián)網(wǎng)技術結合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站制作、做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、雅安服務器托管、企業(yè)郵箱。業(yè)務覆蓋廉江地區(qū)。

一：簡介

Istio 提供了一個簡單的配置模型，用來控制 API 調(diào)用以及應用部署內(nèi)多個服務之間的四層通信。運維人員可以使用這個模型來配置服務級別的屬性，這些屬性可以是斷路器、超時、重試，以及一些普通的持續(xù)發(fā)布任務，例如金絲雀發(fā)布、A/B 測試、使用百分比對流量進行控制，從而完成應用的逐步發(fā)布等。

例如，將 reviews 服務 100％ 的傳入流量發(fā)送到 v1 版本，這一需求可以用下面的規(guī)則來實現(xiàn)：

apiVersion: networking.istio.io/v1alpha3
    kind: VirtualServicemetadata:
  name: reviewsspec:
  hosts:
  - reviews  http:
  - route:
    - destination:
        host: reviews        
        subset: v1

這個配置的用意是，發(fā)送到 reviews 服務（在 host 字段中標識）的流量應該被路由到 reviews 服務實例的 v1 子集中。路由中的 subset 制定了一個預定義的子集名稱，子集的定義來自于目標規(guī)則配置

apiVersion: networking.istio.io/v1alpha3
      kind: DestinationRulemetadata:
      name: reviewsspec:
      host: reviews  
      subsets:
      - name: v1    
      labels:
      version: v1  
      - name: v2    
      labels:
      version: v2

子集中會指定一或多個標簽，用這些標簽來區(qū)分不同版本的實例。假設在 Kubernetes 上的 Istio 服務網(wǎng)格之中有一個服務，version: v1 代表只有標簽中包含 “version:v1” 的 Pod 才會收到流量。

規(guī)則可以使用 istioctl 客戶端工具 進行配置，如果是 Kubernetes 部署，還可以使用 kubectl 命令完成同樣任務，但是只有 istioctl 會在這個過程中對模型進行檢查，所以我們推薦使用 istioctl。在配置請求路由任務中包含有配置示例。

Istio 中包含有四種流量管理配置資源，分別是 VirtualService、DestinationRule、ServiceEntry、以及 Gateway。下面會講一下這幾個資源的一些重點。在網(wǎng)絡參考中可以獲得更多這方面的信息。

二：Virtual Services

Virtual Services在Istio服務網(wǎng)格中定義了對服務的請求如何進行路由控制。例如一個 Virtual Service 可以把請求路由到不同版本，甚至是可以路由到一個完全不同于請求要求的服務上去。路由可以用很多條件進行判斷，例如請求的源和目的、HTTP 路徑和 Header 以及各個服務版本的權重等。

  1. 路由規(guī)則定義

    路由規(guī)則對應著一或多個用 VirtualService 配置指定的請求目的主機。這些主機可以是、也可以不是實際的目標負載，甚至可以不是一個網(wǎng)格內(nèi)可路由的服務。例如要給到 reviews 服務的請求定義路由規(guī)則，可以使用內(nèi)部的名稱 reviews，也可以用域名 bookinfo.com，VirtualService 可以這樣使用 host 字段：

    hosts:

     - reviews

      - bookinfo.com

    host 字段用顯示或者隱式的方式定義了一或多個完全限定名（FQDN）。上面的 reviews，會隱式的擴展成為特定的 FQDN，例如在 Kubernetes 環(huán)境中，全名會從 VirtualService 所在的集群和命名空間中繼承而來（比如說 reviews.default.svc.cluster.local）

 2.根據(jù)來源或 Header 制定規(guī)則

a.根據(jù)特定用戶進行限定。例如，可以制定一個規(guī)則，只對來自 reviews 服務的 Pod 生效

apiVersion: networking.istio.io/v1alpha3
  kind: VirtualServicemetadata:
  name: ratingsspec:
  hosts:
  - ratings  
  http:
  - match:
      sourceLabels:
        app: reviews    ...

sourceLabels 的值依賴于服務的實現(xiàn)。比如說在 Kubernetes 中，跟服務的 Pod 選擇標簽一致。

b.根據(jù)調(diào)用方的特定版本進行限定。例如下面的規(guī)則對前一個例子進行修改，reviews 服務的 v2 版本發(fā)出的請求才會生效：

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

c.根據(jù) HTTP Header 選擇規(guī)則。下面的規(guī)則只會對包含了 end-user 頭，且值為 jason 的請求生效：

apiVersion: networking.istio.io/v1alpha3
  kind: VirtualServicemetadata:
  name: reviewsspec:
  hosts:
    - reviews  
  http:
  - match:
    - headers:
        end-user:
          exact: jason    ...

3.在服務之間分拆流量

每個路由規(guī)則都需要對一或多個有權重的后端進行甄別并調(diào)用合適的后端。每個后端都對應一個特定版本的目標服務，服務的版本是依靠標簽來區(qū)分的。如果一個服務版本包含多個注冊實例，那么會根據(jù)為該服務定義的負載均衡策略進行路由，缺省策略是 round-robin。

例如下面的規(guī)則會把 25% 的 reviews 服務流量分配給 v2 標簽；其余的 75% 流量分配給 v1：

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

4.超時和重試

缺省情況下，HTTP 請求的超時設置為 15 秒，可以使用路由規(guī)則來覆蓋這個限制：

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

5.在請求中進行錯誤注入

在根據(jù)路由規(guī)則向選中目標轉發(fā) http 請求的時候，可以向其中注入一或多個錯誤。錯誤可以是延遲，也可以是退出。

下面的例子在目標為 ratings:v1 服務的流量中，對其中的 10% 注入 5 秒鐘的延遲。

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

三：DestinationRule

1.目標規(guī)則

在請求被 VirtualService 路由之后，DestinationRule 配置的一系列策略就生效了。這些策略包含斷路器、負載均衡以及 TLS 等的配置內(nèi)容。DestinationRule 還定義了對應目標主機的可路由 subset（例如有命名的版本）。VirtualService 在向特定服務版本發(fā)送請求時會用到這些子集。

apiVersion: networking.istio.io/v1alpha3
  kind: DestinationRulemetadata:
  name: reviewsspec:
  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

2.斷路器

可以用一系列的標準，例如連接數(shù)和請求數(shù)限制來定義簡單的斷路器。

例如下面的 DestinationRule 給 reviews 服務的 v1 版本設置了 100 連接的限制：

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

3.目標規(guī)則的評估

和路由規(guī)則類似，這些策略也是和特定的 host 相關聯(lián)的，如果指定了 subset，那么具體生效的 subset 的決策是由路由規(guī)則來決定的。

規(guī)則評估的第一步，是確認 VirtualService 中所請求的主機相對應的路由規(guī)則（如果有的話），這一步驟決定了將請求發(fā)往目標服務的哪一個 subset（就是特定版本）。下一步，被選中的 subset 如果定義了策略，就會開始是否生效的評估。

這一算法需要留心是，為特定 subset 定義的策略，只有在該 subset 被顯式的路由時候才能生效。例如下面的配置，只為 review 服務定義了規(guī)則（沒有對應的 VirtualService 路由規(guī)則）。

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

既然沒有為 reviews 服務定義路由規(guī)則，那么就會使用缺省的 round-robin 策略，偶爾會請求到 v1 實例，如果只有一個 v1 實例，那么所有請求都會發(fā)送給它。然而上面的策略是永遠不會生效的，這是因為，缺省路由是在更底層完成的任務，策略引擎無法獲知最終目的，也無法為請求選擇匹配的 subset 策略。

有兩種方法來解決這個問題?？梢园崖酚刹呗蕴岣咭患?，要求他對所有版本生效：

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

還有一個更好的方法，就是為服務定義路由規(guī)則，例如給 reviews:v1 加入一個簡單的路由規(guī)則：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualServicemetadata:
  name: reviewsspec:
  hosts:
  - reviews  
http:
  - route:
    - destination:
        host: reviews        
        subset: v1

雖然 Istio 在沒有定義任何規(guī)則的情況下，能將所有來源的流量發(fā)送給所有版本的目標服務。然而一旦需要對版本有所區(qū)別，就需要制定規(guī)則了。從一開始就給每個服務設置缺省規(guī)則，是 Istio 世界里推薦的最佳實踐。

四：Service Entries

Istio 內(nèi)部會維護一個服務注冊表，可以用 ServiceEntry 向其中加入額外的條目。通常這個對象用來啟用對 Istio 服務網(wǎng)格之外的服務發(fā)出請求。例如下面的 ServiceEntry 可以用來允許外部對 *.foo.com 域名上的服務主機的調(diào)用。

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

五：Gateway

Gateway 為 HTTP/TCP 流量配置了一個負載均衡，多數(shù)情況下在網(wǎng)格邊緣進行操作，用于啟用一個服務的 Ingress 流量。

和 Kubernetes Ingress 不同，Istio Gateway 只配置四層到六層的功能（例如開放端口或者 TLS 配置）。綁定一個 VirtualService 到 Gateway 上，用戶就可以使用標準的 Istio 規(guī)則來控制進入的 HTTP 和 TCP 流量。

例如下面提供一個簡單的 Gateway 代碼，配合一個負載均衡，允許外部針對主機 bookinfo.com 的 https 流量：

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

要為 Gateway 配置對應的路由，必須為定義一個同樣 host 定義的 VirtualService，其中用 gateways 字段來綁定到定義好的 Gateway 上：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualServicemetadata:
  name: bookinfospec:
  hosts:
    - bookinfo.com  gateways:
  - bookinfo-gateway # <---- 綁定到 Gateway
  http:
  - match:
    - uri:
        prefix: /reviews    
route:
    ...

雖然主要用于管理 Ingress 流量，Gateway 還可以用在純粹的內(nèi)部服務之間或者 egress 場景下使用。不管處于什么位置，所有的網(wǎng)關都可以以同樣的方式進行配置和控制。

以上是“kubernetes中如何實現(xiàn)Istio流量管理”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道！

本文名稱：kubernetes中如何實現(xiàn)Istio流量管理-創(chuàng)新互聯(lián)
分享地址：http://bm7419.com/article24/gjije.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供云服務器、商城網(wǎng)站、外貿(mào)建站、自適應網(wǎng)站、網(wǎng)頁設計公司、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都seo排名網(wǎng)站優(yōu)化