使用K8s遇難題？Istio來幫您！

若是你正在使用容器，特別是Kubernetes，那麼你應該也據說過Istio。對於初學者來講，Istio是Kubernetes的服務網格（service mesh）。所謂服務網格，它是一個網絡層，而且能夠動態管理服務流量，而後以安全的方式進行管理。

如何充分使用Istio，這不是一篇博客文章能闡述清楚的。所以，在本文中我將介紹一些它的特性，更重要的是，你能夠經過這篇文章，瞭解到一些方法來自動化解決某些實際問題。

Istio可讓你使用一組自定義Kubernetes資源來管理網絡流量，而且能夠幫助你保護和加密服務之間以及集羣內外的網絡流量。它全面集成了Kubernetes API，這意味着可使用與其餘Kubernetes配置徹底相同的方式來定義和管理Istio設置。

權衡利弊,再作選擇

若是要開始使用Istio，首先應該問本身爲何。Istio提供了一些很是有價值的功能，如金絲雀發佈等，可是若是不增長一些複雜性，就沒法使用它們。你還須要投入必定的時間來學習它。也就是說，若是你的狀況合適使用它，你能夠（而且應該）在本身的集羣中謹慎且逐步地採用Istio的功能。

若是你要從頭開始構建新環境，而且通過利弊權衡決定繼續使用Istio，那麼必定要從一開始就使用嚴格的相互TLS對其進行設置，並積極使用其強大的功能。具體操做請參考：

https://istio.io/docs/setup/install/kubernetes/#installation-steps

爲了使一切都有價值而且具備必定的性價比，咱們須要在實際應用程序的上下文中考慮Istio，可是若是沒有快速免責聲明的話，最好不要這樣作。若是你只須要管理少許服務（且位於單個集羣內），那麼引入Istio的性價比相對而言沒有那麼高。

本文中的代碼示例不必定可以徹底幫助你解決你的問題，可是若是你須要全部的代碼以及如何使用它的詳細說明均可以在GitLab上找到：

https://gitlab.com/ContainerSolutions/k8s-deployment-mtl/

接下來是你在Cloud Native旅程中可能遇到的兩個常見問題，以及如何使用Istio來解決這些問題。

問題1：我不相信個人測試

若是測試範圍並無徹底涵蓋你所更改的應用程序，那麼你可能會很快採起行動進行新一輪測試，但也有可能應用程序沒法正常運行了。

在理想情況下，咱們都想要確保每一個代碼通過全面的測試，不然就不會將功能添加到應用程序中。可是現實總歸是骨感的，咱們經常被ddl追趕，可能還未編寫或者更新測試，功能就得上傳到項目中了。

解決方案：放慢速度

那麼，如何確保我絕大多數用戶不受代碼中潛伏的任何錯誤的影響，又如何進行更改和部署新功能呢？答案是經過先將新版本部署到最少數量的用戶來最大程度地減小這些小問題的輻射範圍。

若是更改可以按照預期工做的話，你能夠緩慢增長使用新版本的用戶百分比。若是各項指標出現問題，你能夠輕鬆回滾你的更改，而後重試。

在沒有Istio的狀況下能夠在Kubernetes上運行金絲雀部署嗎？固然沒問題，可是若是要自動化這一過程，你須要徹底將本身的精力放在web服務器代碼和自定義自動化腳本方面。這樣的操做方式性價比並不高。

Istio有一些十分優雅的流量分配解決方案，咱們可使用它們在恰當的時間爲合適的版本提供適當的客戶端服務，而且咱們只需調整其中的1個或2個參數。

爲了實現這一點，你須要設置一個網關入口（Ingress gateway）、一個虛擬服務（virtual service）和一個destination rule。這將位於通常的部署和服務之上，併爲你分配流量。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hos
ts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - "*"
  gateways:
    - http-gateway
  http:
  - match:
    - uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v1
          port:
            number: 80
        weight: 90
      - destination:
          host: my-app
          subset: v2
          port:
            number: 80
        weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  subsets:
  - name: v1
    labels:
      version: v1.0.0
  - name: v2
    labels:
      version: v2.0.0

從虛擬服務的權重字段中能夠看到，Istio將根據指定的值在應用程序的兩個版本之間分配流量。這些值的總和必須爲100％，不然，API將拒絕應用該定義。

而後，你（或者理想狀況下，在「持續集成/連續交付」流水線中手動執行一個或多個步驟）將調整權重，以將新版本推廣給更多用戶，直到全部請求由新版本知足爲止，而且之前的版本能夠中止維護。

經過使用Istio的故障注入功能來模擬網絡中斷和實際流量性能降低，還能夠將Istio集成到您的集成測試策略中。

若是在生產中進行測試的想法給你留下了心理陰影，那必定是你的作法有所欠缺。例如，嘗試在你的虛擬服務規範中添加如下代碼片斷以添加一些混亂，而後再找一篇文章來看看怎麼用Istio解決這樣的混亂。

spec:
  hosts:
  - my-app
  http:
  - fault:
      delay:
        fixedDelay: 7s
        percent: 100
   route:
    - destination:
        host: ratings
        subset: v2

問題2：市場策略沒法肯定發佈版本

一般，業務須要針對實際用戶測試應用程序的多個版本。可是有時實在沒法搞清楚是哪一種營銷策略能夠帶來最佳轉化率，或者哪一種設計選擇能夠帶來最佳的客戶留存率。

使用Kubernetes，你能夠將流量分爲兩個版本，可是要想從練習中得到任何有價值的看法，則再次須要一大堆自定義代碼來獲取相關信息，並以非技術同事能夠理解的方式對其進行處理。

解決方案：使用Istio進行A/B測試

Istio的流量分配規則能夠再次解決這一問題，它與Prometheus和Grafana的緊密集成能夠幫助你獲取直觀的A/B測試的結果。通常而言，根據傳入數據包內容的某些部分，幾乎有無數種方法來決定哪些用戶能夠獲取你的應用程序的版本。

在這一示例中，咱們將使用User-Agent字段爲不一樣的瀏覽器提供不一樣的版本。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - "*"
  gateways:
    - http-gateway
  http:
  - match:
    - headers:
        user-agent:
          regex: ".*Chrome.*"
      uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v1
          port:
            number: 80
  - match:
    - headers:
        user-agent:
          regex: ".*Mozilla.*"
      uri:
        prefix: "/my-app"
    rewrite:
      uri: "/"
    route:
      - destination:
          host: my-app
          subset: v2
          port:
            number: 80

從上面的代碼中能夠看到，使用Firefox的用戶將得到應用程序的版本1，而Chrome用戶將得到版本2。若是瀏覽器的「User-Agent」字段不包含「mozilla」或「chrome」，則他們都將不會得到任一版本。

要爲其餘客戶提供服務，您須要添加一條默認路由，我將做爲練習留給你。（嘿嘿）

若是你不想安裝其餘瀏覽器，只是想嘗試一下，則可使用帶有頭部標誌的curl假裝成所需的任何瀏覽器，例如：

curl /my-app -H "User-Agent: Chrome"

經過更改user-agent的值，你能夠從命令行測試全部不一樣的路由。

總 結

以上兩種狀況大概能讓你體驗到Istio強大功能的冰山一角。正如上文所說，若是沒有Istio，你依然能夠進行金絲雀部署和A/B測試，只是你必須本身實現流量分配。但這大大增長了開發部署的複雜性，實屬性價比低之選。

我但願這篇文章可讓你對Istio的實際應用有很好的理解，而且十分期待你本身嘗試一下。若是你想了解更多關於Istio的信息，能夠訪問它們的官網，上面有許多有用的資料：https://istio.io/

值得一提的是，Rancher 2.3 Preview2版本上開始支持Istio，用戶能夠直接在UI界面中啓動Istio而且能夠爲每一個命名空間注入自動sidecar。此外，Rancher簡化Istio的安裝和配置，內置了一個支持Kiali的儀表盤，用於流量和遙測的可視化，而後用Jaeger進行追蹤，甚至還有本身的Prometheus和Grafana（與用於高級監控的實例不一樣）。這一切讓部署和管理Istio變得簡單而快速。

有關發行說明和安裝步驟，請訪問GitHub：

https://github.com/rancher/rancher/releases/tag/v2.3.0-alpha5