Istio技術實踐專題(1) Service Mesh Istio 基本概念和架構基礎

Istio被稱作Kubernetes的最佳雲原生拍檔。從今天起，我們推出“Istio技術實踐”系列專題，在本專題中，我們將通過技術文章+視頻授課的方式，爲大家詳細闡述Istio微服務治理，及在企業級雲平臺中的解決方案和實踐。

什麼是Service Mesh？

Service Mesh譯作“服務網格”，作爲服務間通信的基礎設施層，Willian Morgan（Linkerd 的CEO）是這樣定義Service Mesh的：

服務網格是一個用於處理服務間通信的基礎設施層，它負責爲構建複雜的雲原生應用傳遞可靠的網絡請求。在實踐中，服務網格通常實現爲一組和應用程序部署在一起的輕量級的網絡代理，但對應用程序來說是透明的。

Service Mesh 實際是處於 TCP/IP 之上的一個抽象層，它假設底層的 L3/L4 網絡能夠點對點地傳輸字節（當然，它也假設網絡環境是不可靠的，所以 Service Mesh 必須具備處理網絡故障的能力）。

Service Mesh 有如下幾個特點：

多語言支持：
支持幾乎所有的語言，可以自由選擇編程語言；
業務開發變革降低入門門檻，提高穩定性；
業務開發團隊從框架依賴中解放出來，迴歸業務；
強化運維管理對系統強大的管理和控制力；
微服務治理的功能不再和應用有關。

Service Mesh架構圖

微服務體系帶來的問題

實際上，微服務並非一好百好，本質上是以運維的複雜度爲代價獲得敏捷性。分佈式和微服務系統會帶來哪些挑戰呢？

首當其衝是定位和調試困難。

當遇到bug或者性能問題，原來的方式基本都是逐級排查，從客戶遇到問題的地方開始。因爲一個深層次的微服務會引起一系列的上層微服務出現問題。如果發現兩個服務之間的整體調用性能不好，這個時候哪怕你找到某一次性能差的日誌或數據，基於這個數據和日誌找出來的原因不一定是root cause。這種排查問題的方式就像烽火臺，你只看到了最近的烽火臺，並不知道起點在哪。

第二，測試時數據會有遺漏，缺少完整的測試數據。

最好的測試數據是線上的真實數據。但是線上的請求採集下來還需要獨立開發相應的程序，整體實現很麻煩。另外，如果測試微服務的錯誤處理，對於QA的黑盒測試來說，這還需要一個可配置的錯誤生成器。這點對於測試也是一個獨立的工作。

第三，缺少上線流程。

我們原來使用獨立的微服務作爲開關，來判斷是否加載新功能。在新的功能代碼外層加上調用該微服務的代碼，根據返回值來判斷是否執行新功能代碼，上線完成後再把開關代碼刪掉，的確有點麻煩。上線前需要修改源碼增加控制，上線完成後還需要在源碼中刪除這些邏輯。沒有簡單、無侵入的金絲雀和灰度發佈的實現方式。

第四，微服務間的網絡調用策略配置不靈活。

不同的客戶環境需要使用不同的網絡策略，例如重試，超時等等設置，如果對應的設置沒有通過配置文件暴露出來，就只能對代碼進行修改。而且這些代碼在業務代碼裏，統一的維護和升級都需要獨立的流程。

諸如以上這些問題還有很多，涉及到成百上千個服務的通信、管理、部署、版本、安全、故障轉移、策略執行、遙測和監控等，要解決這些微服務架構帶來的問題並非易事。而Istio 提供了一個完整的解決方案，通過爲整個服務網格提供行爲洞察和操作控制來滿足微服務應用的多樣化需求，解決了開發人員和運維人員在向分佈式微服務架構過渡時所面臨的挑戰。

什麼是Istio？

Istio是目前受Google/IBM 等大廠支持和推進的 Service Mesh開源框架組合。官方對 Istio 的介紹：
An open platform to connect, secure, control and observe services.

翻譯過來，就是”連接、安全加固、控制和觀察服務的開放平臺“。Istio提供一種簡單的方式來建立已部署的服務的網絡，具備負載均衡，服務到服務認證，監控等功能，而不需要改動任何服務代碼。

Istio 允許連接、保護、控制和觀測微服務，在較高的層次上，Istio 有助於降低這些部署的複雜性，並減輕開發團隊的壓力。它是一個完全開源的服務網格，可以透明地分層到現有的分佈式應用程序上。它也是一個平臺，包括允許它集成到任何日誌記錄平臺、遙測或策略系統的 API。Istio 的多樣化功能集能夠成功高效地運行分佈式微服務架構，並提供保護、連接和監控微服務的統一方法。

Istio 適用於容器或虛擬機環境（特別是 k8s），兼容異構架構；

Istio 使用 sidecar（邊車模式）代理服務的網絡，不需要對業務代碼本身做任何的改動；

HTTP、gRPC、WebSocket 和 TCP 流量的自動負載均衡；

Istio 通過豐富的路由規則、重試、故障轉移和故障注入，可以對流量行爲進行細粒度控制；支持訪問控制、速率限制和配額；

Istio 對出入集羣入口和出口中所有流量的自動度量指標、日誌記錄和跟蹤。

Istio系統架構

Istio 分爲兩個平面：數據平面和控制平面。

數據平面：
數據平面由一組 sidecar 的代理（Envoy）組成。這些代理調解和控制微服務之間的所有網絡通信，並且與控制平面的 Mixer 通訊，接受調度策略。
控制平面：
控制平面通過管理和配置 Envoy 來管理流量。此外，控制平面配置 Mixers來實施路由策略並收集檢測到的監控數據。

如上圖，
數據平面由一組以 Sidecar 方式部署的智能代理（Envoy）組成。這些代理可以調節和控制微服務及 Mixer 之間所有的網絡通信。

控制平面負責管理和配置代理來路由流量。此外，控制平面配置 Mixer 以實施策略和收集遙測數據。

Pilot是整個架構中的抽象層，將對接K8S等資源調度器的步驟進行抽象並以適配器的形式展現，並和用戶以及Sidecar交互。

Galley負責驗證資源配置。

Citadel用於生成身份，及密鑰和證書管理。

核心功能包括流量控制、安全控制、可觀測性、多平臺支持、可定製化。

Istio 安全架構

Istio中80%的組件都參與到了安全的功能裏面。

Istio 安全目標：

默認安全
深度防禦
零信任網絡

Istio 安全組件：

citadel，管理密鑰、證書
Sidecar，實現安全通信
Pilot，授權策略分發
Mixer，管理授權和審計

感謝參考

https://www.alauda.cn/news/blog_detail/id/416.html

Istio技術實踐專題(2) Istio 核心組件介紹

上一篇文章中，我們講到Istio的基本概念、架構基礎。Istio 作爲 Service Mesh 領域的集大成者, 提供了流控、安全、遙測等模型，其功能複雜，模塊衆多，本篇文章會對Istio 1.6.1 的各組件進行分析，幫助大家瞭解Istio各組件的職責、以及相互的協作關係。

Istio架構回顧

數據平面：

數據平面由一組 sidecar 的代理（Envoy）組成。這些代理調解和控制微服務之間的所有網絡通信，並且與控制平面的 pilot通訊，接受調度策略。
控制平面：

控制平面通過管理和配置 Envoy 來管理流量。此外，控制平面pilot下發xds規則來實施路由策略，mixer收集檢測到的監控數據。

雖然Istio 支持多個平臺, 但將其與 Kubernetes 結合使用，其優勢會更大, Istio 對Kubernetes 平臺支持也是最完善的, 本文將基於Istio + Kubernetes 進行展開。

下面就來介紹Istio 架構中每個組件的功能及工作方式。

Istio核心組件

Sidecar ( 在 Istio 中，默認的 Sidecar 是 Envoy )

Envoy 是使用 C++ 開發的高性能代理，用於調解服務網格中所有服務的入站和出站流量。在 Istio 中，Envoy 被用於 Sidecar ，和對應的應用服務部署在同一個 Kubernetes 的 Pod 中。

Envoy 調解所有出入應用服務的流量。所有經過 Envoy 的流量行爲都會調用 Mixer（只是report功能，check功能可以通過配置關閉），爲Mixer 提供一組描述請求和請求周圍環境的 Attribute 。根據 Envoy 的配置和 Attribute，Mixer 會調用各種後臺的基礎設施資源。而這些 Attribute 又可以在 Mixer 中用於決策使用何種策略，併發送給監控系統，以提供整個網格行爲的信息。

Pilot

Pilot 爲 Sidecar 提供“服務發現”功能，並管理高級路由( 如 A/B 測試和金絲雀部署 )和故障處理( 超時、重試、熔斷器等 )的流量。Pilot 將這些“高級”的流量行爲轉換爲詳盡的 Sidecar (即 Envoy) 配置項，並在運行時將它們配置到 Sidecar 中。

Pilot 將服務發現機制提煉爲供數據面使用的 API ，即任何 Sidecar 都可以使用的標準格式。這種松耦合的設計模式使 Istio 能在多種環境( Kubernetes、Consul 和 Nomad )下運行，同時保持用於流量管理操作的相同。

除了服務發現， Pilot 更重要的一個功能是向數據面下發規則，包括VirtualService 、DestinationRule 、Gateway 、ServiceEntry 等流量治理規則，也包括認證授權等安全規則。Pilot 負責將各種規則轉換成Envoy 可識別的格式，通過標準的XDS 協議發送給Envoy,指導Envoy 完成功作。在通信上， Envoy 通過gRPC 流式訂閱Pilot 的配置資源。如下圖所示， Pilot 將VirtualService 表達的路由規則分發到Evnoy 上， Envoy 根據該路由規則進行流量轉發。

Mixer

Mixer 是一個獨立於平臺的組件，通過從 Sidecar 和一些其他服務處收集數據，進而在整個 Service Mesh 上控制訪問和執行策略。Sidecar 請求級別的 Attribute 被髮送到 Mixer 進行評估。

Mixer 中還包括一個靈活的插件，使其能接入各種主機環境和基礎設施的後段，並得到 Sidecar 代理和 Istio 所管理的服務。

Mixer 的設計具有以下特點：

無狀態：Mixer 本身是無狀態的，它沒有持久化存儲的管理功能。
高可用：Mixer 被設計成高度可用的組件，任何單獨的 Mixer 實例實現 > 99.999% 的正常運行時間。
緩存和緩衝：Mixer 能夠積累大量短暫的瞬間狀態。

Mixer 是Istio 獨有的一種設計,不同於Pilot ，在其他平臺上總能找到類似功能的服務組件。從調用時機上來說，Pilot 管理的是配置數據，在配置改變時和數據面交互即可；然而，對於Mixer 來說，在服務間交互時Envoy 都會對Mixer 進行一次調用，因此這是一種實時管理。當然，在實現上通過在Mixer 和Proxy 上使用緩存機制，可保證不用每次進行數據面請求時都和Mixer 交互。

Istio-telemetry

Istio-telemetry是專門用於收集遙測數據的Mixer服務組件;

如下圖所示所示，當網格中的兩個服務間有調用發生時，服務的代理Envoy 就會上報遙測數據給Istio-telemetry服務組件，Istio-telemetry 服務組件則根據配置將生成訪問Metric等數據分發給後端的遙測服務。數據面代理通過Report 接口上報數據時訪問數據會被批量上報。

Istio-policy

Istio-policy 是另外一個Mixer 服務，和Istio-telemetry 基本上是完全相同的機制和流程。

如圖所示，數據面在轉發服務的請求前調用Istio-policy 的Check接口檢查是否允許訪問， Mixer 根據配置將請求轉發到對應的Adapter 做對應檢查，給代理返回允許訪問還是拒絕。可以對接如配額、授權、黑白名單等不同的控制後端，對服務間的訪問進行可擴展的控制。

Citadel

Citadel 通過內置身份和憑證管理提供“服務間”和“最終用戶”身份驗證。Citadel 可用於升級服務網格中未加密的流量，並能夠爲運維人員提供基於服務標識( 如 Kubernetes 中 Pod 的標籤或版本號 )而不是網絡層的強制執行策略。

Citadel 一直監聽Kube-apiserver ，以Secret 的形式爲每個服務都生成證書密鑰，並在Pod 創建時掛載到Pod 上，代理容器使用這些文件來做服務身份認證，進而代理兩端服務實現雙向TLS認證、通道加密、訪問授權等安全功能，這樣用戶就不用在代碼裏面維護證書密鑰了。如下圖所示，frontend 服務對forecast 服務的訪問用到了HTTP 方式，通過配置即可對服務增加認證功能，雙方的Envoy 會建立雙向認證的TLS 通道，從而在服務間啓用雙向認證的HTTPS 。

Istio-galley

Istio-galley 並不直接向數據面提供業務能力，而是在控制面上向其他組件提供支持。Galley 作爲負責配置管理的組件，驗證配置信息的格式和內容的正確性，並將這些配置信息提供給管理面的Pilot和Mixer服務使用，這樣其他管理面組件只用和Galley 打交道，從而與底層平臺解耦。在新的版本中Galley的作用越來越核心。

Istio-sidecar-injector

Istio-sidecar-injector 是負責向動注入的組件，只要開啓了自動注入，在Pod 創建時就會自動調用Istio-sidecar-injector 向Pod 中注入Sidecar 容器。

在Kubernetes環境下，根據自動注入配置， Kube-apiserver 在攔截到Pod 創建的請求時，會調用自動注入服務Istio-sidecar-injector生成Sidecar 容器的描述並將其插入原Pod的定義中，這樣，在創建的Pod 內除了包括業務容器，還包括Sidecar 容器。這個注入過程對用戶透明，用戶使用原方式創建工作負載。

Istio-ingressgateway

Istio-ingressgateway 就是入口處的Gateway ，從網格外訪問網格內的服務就是通過這個Gateway 進行的。Istio-ingressgateway 比較特別，是一個Loadbalancer 類型的Service,不同於其他服務組件只有一兩個端口, Istio-ingressgateway 開放了一組端口，這些就是網格內服務的外部訪問端口.如下圖所示，網格入口網關Istio-ingressgateway 的負載和網格內的Sidecar 是同樣的執行體，也和網格內的其他Sidecar 一樣從Pilot處接收流量規則並執行。。Istio 通過一個特有的資源對象Gateway 來配置對外的協議、端口等。

感謝參考

https://www.alauda.cn/news/blog_detail/id/417.html

Istio技術實踐專題(3) 在K8s集羣上部署Istio的三種方式

近兩年微服務架構成爲企業應用架構的流行趨勢，除了互聯網企業，傳統企業也紛紛選擇擁抱微服務。加之容器Kubernetes、DevOps、微服務雲原生技術“黃金三角”的互相賦能，微服務架構成爲當前企業IT架構設計的首選。

Isito是Service Mesh的產品化落地，是目前最受歡迎的服務網格，功能豐富、成熟度高。本文主要根據官網文檔整理而成，介紹Istio針對單集羣的三種主流部署安裝方式：使用Istioctl安裝、使用Helm自定義安裝、獨立Operator安裝。多集羣安裝部署暫不涉及，在今後的文章中我們再做詳細闡述。

使用 Istioctl 安裝

使用默認配置文件安裝 Istio

最簡單的方法是安裝 default Istio 配置文件使用以下命令：

$ istioctl manifest apply

此命令用於在配置好的 Kubernetes 集羣上安裝 default 配置文件。default 配置文件是建立生產環境的起點，這與旨在評估廣泛的 Istio 功能特性的較大的 demo 配置文件不同。

如果要在 default 配置文件之上啓用 Grafana dashboard，用下面的命令設置 addonComponents.grafana.enabled 配置參數：

$ istioctl manifest apply --set addonComponents.grafana.enabled=true

可以像使用 helm 一樣在 istioctl 中配置 --set 標誌。唯一的區別是必須爲配置路徑增加 values. 前綴，因爲這是 Helm 透傳 API 的路徑，如下所述。

$ istioctl manifest apply --set addonComponents.grafana.enabled=true

可以像使用 helm 一樣在 istioctl 中配置 —set 標誌。這其中唯一的區別是必須爲配置路徑增加 values. 前綴，因爲這是 Helm 透傳 API 的路徑，如下所述。

附件操作命令案例詳解

從外部Chart安裝

通常，istioctl 使用內置 Chart 生成安裝清單。這Chart 會和與 istioctl 一起發佈，用於審覈和自定義，它們放置在 install/kubernetes/operator/charts 目錄下。除了使用內置 Chart 外，istioctl 還可以使用外部 Chart 生成安裝清單。要選擇外部 Chart ，請配置 installPackagePath 參數（接收本地文件系統路徑）：

$ istioctl manifest apply --set installPackagePath=< base directory where installed >/istio-releases/istio-1.6.1/install/kubernetes/operator/chart

如果使用 istioctl 1.6.1 二進制文件，該命令執行結果與通過 istioctl manifest apply 安裝相同，因爲它指向的 Chart 與內置 Chart 相同。除了試驗或測試新特性之外，我們建議使用內置 Chart 而不是外部提供，以確保 istioctl 二進制文件與 Chart 的兼容性。

安裝其他配置文件（demo）

可以通過在命令行上設置配置文件名稱安裝其他 Istio 配置文件到羣集中。例如，可以使用以下命令，安裝 demo 配置文件：

$ istioctl manifest apply --set profile=demo

顯示可用配置文件的列表

您可以使用以下 istioctl 命令來列出 Istio 配置文件名稱：

$ istioctl profile list
Istio configuration profiles:
    remote
    default
    demo
    empty
    minimal
    preview

顯示配置文件的配置

您可以查看配置文件的配置設置。通過以下命令查看 default 配置文件的設置：

$ apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  addonComponents:
    grafana:
      enabled: true
      k8s:
        replicaCount: 1
    istiocoredns:
      enabled: false
    kiali:
      enabled: true
      k8s:
        replicaCount: 1
    prometheus:
      enabled: true
      k8s:
        replicaCount: 1
    tracing:
      enabled: true
...

查看整個配置的子集

查看整個配置的子集，可以使用 --config-path 標誌，這一標誌僅選擇部分給定路徑下的配置：

$ istioctl profile dump --config-path components.pilot demo |head -30
2020-08-15T08:17:59.939333Z	info	proto: tag has too few fields: "-"
enabled: true
k8s:
  env:
  - name: POD_NAME
    valueFrom:
      fieldRef:
        apiVersion: v1
        fieldPath: metadata.name
  - name: POD_NAMESPACE
    valueFrom:
      fieldRef:
        apiVersion: v1
        fieldPath: metadata.namespace
  - name: GODEBUG
    value: gctrace=1
  - name: PILOT_TRACE_SAMPLING
    value: "100"
  - name: CONFIG_NAMESPACE
    value: istio-config
  readinessProbe:
    httpGet:
      path: /ready
      port: 8080
    initialDelaySeconds: 1
    periodSeconds: 3
    timeoutSeconds: 5
  resources:
    requests:
      cpu: 10m
      memory: 100Mi
...

顯示配置文件中的差異

profile diff 子命令可用於顯示配置文件之間的差異，在將更改應用於集羣之前，這對於檢查自定義的效果很有用。您可以使用以下命令顯示default和 demo 配置文件之間的差異：

$ istioctl profile diff default demo

安裝前生成清單

您可以在安裝 Istio 之前使用 manifest generate 子命令生成清單，而不是 manifest apply。例如，使用以下命令爲 default 配置文件生成清單：

$ istioctl manifest generate > $HOME/generated-manifest.yaml

根據需要檢查清單，然後使用以下命令應用清單：

$ kubectl apply -f $HOME/generated-manifest.yaml

由於集羣中的資源不可用，此命令可能顯示暫時錯誤。

驗證安裝成功

使用 verify-install 命令檢查 Istio 安裝是否成功，它將集羣上的安裝與您指定的清單進行比較。

如果未在部署之前生成清單，請運行以下命令以現在生成它：

$ istioctl manifest generate <your original installation options> > $HOME/generated-manifest.yamlerated-manifest.yaml

然後運行以下 verify-install 命令以查看安裝是否成功：

$ istioctl verify-install -f $HOME/generated-manifest.yaml

使用 Helm 自定義安裝

這種安裝方式使用 Helm charts 自定義 Istio 控制平面和 Istio 數據平面的 sidecar。你只需使用 helm template 生成配置並使用 kubectl apply 命令安裝它, 或者你可以選擇使用 helm install 讓 Tiller 來完全管理安裝。

通過這些說明, 您可以選擇 Istio 內置的任何一個配置文件並根據的特定的需求進行進一步的自定義配置。

添加 Helm chart 倉庫

下面的命令使用了包含 Istio 發行版鏡像的 Helm charts。如果要使用 Istio 發行版 Helm chart ，建議使用下面的命令添加 Istio 發行版倉庫：

$ helm repo add istio.io https://storage.googleapis.com/istio-release/releases/1.6.1/charts/

安裝步驟

將目錄切換到 Istio 發行版的根目錄，然後在以下兩個選項中選擇一種安裝方式：

如果不使用 Tiller 部署 Istio，請查看方案 1。
如果選擇 Helm 的 Tiller pod 來管理 Istio 發行版, 請查看方案 2。

默認情況下，Istio 使用 LoadBalancer 服務類型。而有些平臺是不支持 LoadBalancer 服務的。對於不支持 LoadBalancer 服務類型的平臺, 執行下面的步驟時，可以在 Helm 命令中加入 --set gateways.istio-ingressgateway.type=NodePort 選項，使用 NodePort 來替代 LoadBalancer 服務類型。

方案 1: 使用 helm template 命令安裝

在集羣沒有安裝 Tiller 的情況下，可以選擇此方案。

爲 Istio 組件創建命名空間 istio-system：

$ kubectl create namespace istio-system

使用 kubectl apply 安裝所有 Istio 的自定義資源 (CRDs) ：

$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -

等待所有的 Istio CRD 創建完成：

$ kubectl -n istio-system wait --for=condition=complete job --all

選擇配置文件，部署與選擇的配置文件相對應的 Istio 核心組件。我們建議在生產環境使用默認的配置文件：

可以添加一個或多個 --set = 來進一步自定義 helm 命令的安裝選項。

default：

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl apply -f -

demo:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \  --values install/kubernetes/helm/istio/values-istio-demo.yaml | kubectl apply -f -

minimal:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-minimal.yaml | kubectl apply -f -

sds:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml | kubectl apply -f -

Istio CNI enabled:

安裝 Istio CNI 組件：

$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl apply -f -

將 --set istio_cni.enabled=true 設置追加到 helm 命令上，來啓用 Istio CNI件。以 Istio 默認配置文件爲例：

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --set istio_cni.enabled=true | kubectl apply -f -

方案 2: 在 Helm 和 Tiller 環境中使用 helm install 命令安裝

這個方案使用 Helm 和 Tiller 來對 Istio 的生命週期進行管理。

請確保集羣的 Tiller 設置了 cluster-admin 角色的 Service Account。如果沒有定義，可以執行下面命令創建：
```
$ kubectl apply -f manifests/UPDATING-CHARTS.md
```
使用 Service Account 在集羣上安裝 Tiller：
```
$ helm init --service-account tiller
```

安裝 istio-init chart，來啓動 Istio CRD 的安裝過程：

$ helm install install/kubernetes/helm/istio-init --name istio-init --namespace istio-system

等待所有Istio CRD 創建完成：

$ kubectl -n istio-system wait --for=condition=complete job --all

選擇一個配置文件，然後部署與選擇的配置文件相對應的 istio 的核心組件。我們建議在生成環境部署中使用默認配置文件:

添加一個或多個 --set = 來進一步定義 Helm 命令的安裝選項。

default:

$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system

demo:

- $ helm install install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-demo.yaml

minimal:

- $ helm install install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-minimal.yaml

sds:

$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml

Istio CNI enabled:

安裝 Istio CNI chart：

$ helm install install/kubernetes/helm/istio-cni --name istio-cni --namespace kube-system

將 --set istio_cni.enabled=true 設置追加到 helm 命令上，來啓用 Istio CNI 插件。以 Istio 默認配置文件爲例：

$ helm install install/kubernetes/helm/istio --name istio --namespace istio-system --set istio_cni.enabled=true

驗證安裝
1. 查詢配置文件的組件表，驗證是否已部署了與選擇的配置文件相對應的 Kubernetes 服務：
```
$ kubectl get svc -n istio-system
```
1. 確保相應的 Kubernetes Pod 已部署並且 STATUS 是 Running：
```
$ kubectl get pods -n istio-system
```

卸載

對於使用 helm template 命令安裝的 Istio，使用如下命令卸載：

default:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system | kubectl delete -f -$ kubectl delete namespace istio-system

demo:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-demo.yaml | kubectl delete -f -$ kubectl delete namespace istio-system

minimal:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-minimal.yaml | kubectl delete -f -$ kubectl delete namespace istio-system

sds:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \   --values install/kubernetes/helm/istio/values-istio-sds-auth.yaml | kubectl delete -f -$ kubectl delete namespace istio-system

Istio CNI enabled:

$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system \  
--set istio_cni.enabled=true | kubectl delete -f 

$ helm template install/kubernetes/helm/istio-cni --name=istio-cni --namespace=kube-system | kubectl delete -f -

對於使用的 Helm 和 Tiller 安裝的 Istio, 使用如下命令卸載：

$ helm delete --purge istio

$ helm delete --purge istio-init

$ helm delete --purge istio-cni

$ kubectl delete namespace istio-system

刪除 CRD 和 Istio 配置

在Istio 的設計中，自定義資源以 CRD 形式存在於 Kubernetes 環境之中。CRD 中包含了運維過程中產生的運行時配置。正因如此，我們建議運維人員應該顯式的對其進行刪除，從而避免意外操作。

istio-init Chart 包含了 istio-init/files 目錄中的所有原始 CRD。下載該 Chart 之後，可以簡單使用 kubectl 刪除 CRD。要永久刪除 Istio 的 CRD 以及所有 Istio 配置, 請運行如下命令:

$ kubectl delete -f install/kubernetes/helm/istio-init/files

三、安裝獨立 Operator

該指南將指引使用獨立的 Istio operator 來安裝 Istio。唯一的依賴就是一個 Kubernetes 集羣和 kubectl 命令行工具。

如果要安裝生產環境的 Istio，我們還是建議您參考使用 istioctl 安裝。

前提條件

執行必要的平臺特定設置。
檢查 Pods 和 Services 需求。
部署 Istio operator。

$ kubectl apply -f https://preliminary.istio.io/operator.yaml

這條命令會在 istio-operator 命名空間中創建以下資源，並運行 Istio operator :

operator 自定義資源
operator 控制器 deployment
operator 指標信息 service
operator 必要的 RBAC 規則

安裝

運行以下命令用 operator 安裝 Istio demo 配置文件：

$ kubectl create ns istio-system
$ kubectl apply -f - <<EOF
apiVersion: install.istio.io/v1alpha1
kind: IstioControlPlane
metadata:  
namespace: istio-operator  
name: example-istiocontrolplane 
 spec:   
profile: demo 
EOF

控制器會檢測 IstioControlPlane 資源，然後按照指定的（demo）配置安裝 Istio 組件。

使用以下命令來確認 Istio 控制面板服務是否部署：

$ kubectl get svc -n istio-system

$ kubectl get pods -n istio-system

更新

現在，控制器已經運行，可以通過編輯或替換 IstioControlPlane 資源改變 Istio 的配置。控制器將會檢測該變化，並更新 Istio 的安裝。運行以下命令將安裝切換爲 default 配置：

$ kubectl apply -f -<<EOF
apiVersion: install.istio.io/v1alpha1
kind:IstioControlPlane
metadata:
  namespace: istio-operator  
  name: example-istiocontrolplanespec:  
  profile:default
EOF

可以啓用或禁用指定的特性或組件。例如，禁用遙測特性：

$ kubectl apply -f -<<EOF
apiVersion: install.istio.io/v1alpha1
kind:IstioControlPlane
metadata:
  namespace: istio-operator  
  name: example-istiocontrolplane
spec: 
profile:default  
telemetry:   
  enabled:false
EOF

卸載

刪除 Istio operator 和 Istio 部署：

$ kubectl -n istio-operator get IstioControlPlane example-istiocontrolplane -o=json | jq '.metadata.finalizers = null' | kubectl delete -f -
$ kubectl delete ns istio-operator --grace-period=0 --force
$ kubectl delete ns istio-system --grace-period=0 --force

Istio技術實踐專題(4) 應用接入Istio的正確姿勢

上一篇文章中，我們介紹了Istio針對單集羣的三種主流部署安裝方式：使用Istioctl安裝、使用Helm自定義安裝、獨立Operator安裝。本文將向大家介紹kubernetes 中的應用接入Istio。主要包括kubernetes 中應用接入Istio使用實例、應用技巧、基本知識點總結和需要注意事項。

用什麼姿勢接入 istio？

雖然 istio 能解決那麼多的問題，但是引入 istio 並不是沒有代價的。最大的問題是 istio 的複雜性，強大的功能也意味着 istio 的概念和組件非常多，要想理解和掌握 istio ，併成功在生產環境中部署需要非常詳細的規劃。一般情況下，集羣管理團隊需要對 kubernetes 非常熟悉，瞭解常用的使用模式，然後採用逐步演進的方式把 istio 的功能分批掌控下來。

我們設定以下目標：

istio部署
dfb相關服務部署
網關功能
流量分配，按比例，header
超時，重試

Istio的幾個基本資源對象：

VirtualService配置影響流量路由的參數，VirtualService 定義了對特定目標服務的一組流量規則。如其名字所示， VirtualService在形式上表示一個虛擬服務，將滿足條件的流量都轉發到對應的服務後端，這個服務後端可以是一個服務，也可以是在Dest in at i onRu l e 中定義的服務的子集。
DestinationRule配置目標規則,DestinationRule定義了在路由發生後應用於服務流量的策略。這些規則指定負載平衡的配置，邊車的連接池大小以及離羣值檢測設置，以從負載平衡池中檢測和清除不正常的主機。
Gateway服務網關，入口.Gateway描述了一個負載均衡器，該負載均衡器在網格的邊緣運行，以接收傳入或傳出的HTTP / TCP連接。
Service Entry外部服務配置,通過ServiceEntry，可以在Istio的內部服務註冊表中添加其他條目，以便網格中自動發現的服務可以訪問/路由到這些手動指定的服務。

網關功能：Gateway

Gateway 在網格邊緣接收外部訪問，並將流量轉發到網格內的服務。Istio 通過Gateway將網格內的服務發佈成外部可訪問的服務，還可以通過Gateway 配置外部訪問的端口、協議及與內部服務的映射關係。

網關功能常見的應用：

將網格內的HTTP 服務發佈爲HTTP 外部訪問
將網格內的HTTPS 服務發佈爲HTTPS 外部訪問
將網格內的HTTP 服務發佈爲HTTPS 外部訪問
將網格內的HTTP 服務發佈爲雙向HTTPS 外部訪問
將網格內的HTTP 服務發佈爲HTTPS 外部訪問和HTTPS 內部訪問

在實踐中。我們更多需要的是1，3兩個場景。

在dfb服務中，dfb-login 作爲最外層的前端，是幾個服務中唯一和外部用戶產生交互的服務。因此我們通過網關功能，將dfb-login 通過域名暴露給用戶。

創建gateway 的yml文件：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:  
  name: login-gateway 
  namespace: dfb-istio
spec:  
  selector:   
    istio: ingressgateway  
  servers: 
  - port:    
      name: https    
      number: 443   
      protocol: HTTPS 
    hosts:   
      - istio-login.dfb.com  
    tls:   
      mode: SIMPLE   
      privateKey: /etc/istio/ingressgateway-certs/dfb.pem   
      serverCertificate: /etc/istio/ingressgateway-certs/dfb.pem 
  - port:   
      name: http    
      number: 80   
      protocol: HTTP
    hosts:   
      - istio-login.dfb.com

創建virtualservice.yml：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:  
  name: dfb-login  
  namespace: dfb-istio
spec:
  hosts: 
    - '*' 
  gateways: 
    - login-gateway  
  http:  
    - uri:   
        prefix: / 
    - route:  
    - destination:     
        host: dfb-login.dfb-istio.svc.cluster.local

我們創建了兩個資源對象，一個VirtualService 用來描述流量的路由關係。所有url 前綴爲/ 的請求都route 到後端dfb-login.dfb-istio.svc.cluster.local 服務。

這個virtuaservice 通過gateways 字段和我們申明的另一個gateway 資源相互綁定。在Gateway 資源對象中。定義了入口的域名，協議，以及TLS 相關的配置。在istio 中。默認的ingressgateway 會監聽gateway 資源對象的變更。多個ingressgateway 通過selector 進行選擇.默認ingressgateway 是一個loadbalancer的service 。

我們將這個ingressgateway 修改爲宿主機網絡，並固定到一個單獨的節點。這樣我們就可以通過將域名解析到這個node節點的方式訪問部署好的入口。

流量分配：按比例，根據請求內容

我們設置了兩個版本的login 服務。V1 版本用戶登錄後顯示的餘額是從數據庫取出來的。V2版本則是0。根據這兩個版本的差異來判斷流量的流向。

首先通過DestinationRule定義兩個版本：

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

根據比例：

修改在網關功能中創建的virtualservice

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:  
  name: dfb-login  
  namespace: dfb-istio
spec:  
  hosts:   
    - '*'  
  gateways:   
    - login-gateway 
  http:   
    - match:    
    - uri:       
       prefix: /    
  route:     
    - destination:      
        host: dfb-login.dfb-istio.svc.cluster.local      
        subset: v1     
        weight: 50    
    - destination:      
        host: dfb-login.dfb-istio.svc.cluster.local      
        subset: v2     
        weight: 50

此時多次刷新頁面。可以看到用戶的現金賬戶餘額在0 和真實額度之間變動。

根據請求內容決定路由：

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:  
  name: dfb-login  
  namespace: dfb-istio
spec: 
  hosts:  
    - '*'  
  gateways:   
    - login-gateway  
  http:   
    - match:     
    - headers:      
  version:        
    exact: v2   
  route:     
    - destination:       
        host: dfb-login.dfb-istio.svc.cluster.local       
        subset: v2  
    - route:    
    - destination:      
        host: dfb-login.dfb-istio.svc.cluster.local      
        subset: v1

修改上文yml 。通過postman請求dfb服務/home頁面。默認情況下會路由指向V1版本的login服務。在請求頭添加version=v2的header。則會轉到v2的服務。

超時，重試功能

我們首先在擴容dfb-api 這個服務爲2個pod，在其中一個pod中攔截用戶資產接口，直接返回500 ，另一個pod 正常返回。此時在dfb-login服務中請求。我們可以發現，接口500 和200 狀態碼交替出現。

location =/user/account/list/338fbcd2-1be6-4dde-9918-84b7629b1ba5 {      
 return500;    
 }

此時應用下面的重試規則，再次調用接口。此時接口狀態碼一直返回200。

kind: VirtualService
apiVersion: networking.istio.io/v1alpha3
metadata:  
  name: dfb-api  
  namespace: dfb-istio
spec: 
  hosts:   
    - dfb-api.dfb-istio.svc.cluster.local  
  gateways: ~  
  http:  
    - route:    
    - destination:     
        host: dfb-api.dfb-istio.svc.cluster.local     
  port:     
    number: 80    
    weight: 100  
  retries:    
    attempts: 3  
    perTryTimeout: 2s   
    retryOn: 5xx,gateway-error,connect-failure,refused-stream

通過jaeger查看調用鏈，可以看到調用了兩次dfb-api。雖然中間調用失敗了，但是最終的狀態碼是200。

Istio技術實踐專題(5) 應用服務網關

上一篇文章中，我們向大家介紹了kubernetes 中的應用接入Istio。主要包括kubernetes 中應用接入Istio使用實例、應用技巧、基本知識點總結和需要注意事項。

從本篇開始，我們將以視頻課程的方式，基於靈雀雲的微服務治理平臺Alauda Service Mesh（簡稱：ASM）向大家演示Istio的微服務治理方案。

本節課程將從以下幾方面介紹Istio服務網關:

微服務網關基本作用
Istio gateway介紹
Istio gateway crd
xds匹配流程
asm的網關

Istio Gateway視頻課程來了！

https://v.qq.com/x/page/o0956kx1h0k.html

Istio技術實踐專題(6) Istio監控與跟蹤

上一篇文章中，我們以視頻課程的方式，向大家介紹了Istio服務網關。主要包括微服務網關基本作用、Istio gateway介紹、Istio gateway crd、xds匹配流程、asm的網關等知識點。

容器化微服務需要管理和維護的服務變得越來越多，服務之間的調用關係越來越複雜，包括服務發現、負載平衡、故障恢復、監控度量和調用鏈路追蹤在內的服務治理變得越來越重要。

Istio爲網格內的所有服務通信生成詳細的遙測。遙測技術提供了服務行爲的可觀察性，允許運營商對其應用程序進行故障排除、維護和優化，而不會給服務開發人員帶來任何額外負擔。

本篇，我們將介紹Istio監控與跟蹤的幾個要點，並演示其實踐操作：

服務網格的服務拓撲kiali
服務網格的調用鏈跟蹤
全鏈路監控jaeger
儀表方式展示grafana

“ Istio監控與跟蹤”視頻講解，一起學起來！

https://v.qq.com/x/page/l0963xxmv9i.html

Istio技術實踐專題(7) 30分鐘講透Istio訪問與控制

本文爲Istio系列專題之七--Istio訪問與控制。Istio通過身份認證、授權、多重安全策略，來保證微服務的安全，實現代碼無侵入性。

有時我們需要對微服務間的相互訪問進行控制，比如滿足某些條件的微服務是否能調用特定的微服務，使用 Istio 可以很方便地實現。

“Istio訪問與控制”視頻公開課

微服務架構雖然提供了更好的靈活性、可伸縮性以及服務複用的能力，但微服務也有特殊的安全需求，istio 作爲服務網格的開放平臺，安全性是其不容忽視的一點，本節課程我們主要從以下兩點闡釋：

安全策略：
爲了提供靈活的服務訪問控制，需要雙向 TLS 和細粒度的訪問策略。
Istio 提供兩種類型的身份驗證：傳輸身份驗證和來源身份驗證。通過配置不同級別的認證策略，可以快速控制不同的安全訪問粒度。
黑白名單：
控制工作負載的訪問權限，提高服務訪問的安全性。
黑白名單是作用於服務端Service，用於限定訪問過來的請求。

https://v.qq.com/x/page/f0968fw6huq.html

"Istio訪問與控制"視頻分享

Istio技術實踐專題(8) Istio流量控制 Destination Rule

主題Istio的流量策略。

虛擬服務（Virtual Service）以及目標規則（Destination Rule）是 Istio 流量路由的兩大基石。後面我們會專門講一個灰度發佈的專題，Virtual Service和灰度發佈會一起講，今天主要講述Destination Rule的功能和應用，分三個部分來闡述：

設置負載均衡

熔斷策略

連接池策略

流量管理的本質就是採用策略控制流量的流向和大小。Istio流量管理模型依賴於隨服務一起部署的 Envoy 代理，網格發送和接收的所有流量（數據平面流量）都通過 Envoy 進行代理。基於此模型可以輕鬆引導和控制網格周圍的流量，而無需對服務進行任何更改。

Istio 自身的服務註冊表維護了一組服務以及這些服務背後真正的執行端點，Istio 使用服務註冊表產生 Envoy 配置。使用此服務註冊表，Envoy 代理就可以將流量定向到相關服務。

雖然 Istio 的基本服務發現和負載均衡已經提供了一個有效的服務網格，但 Istio 提供的功能遠不止這麼多。在許多情況下，都希望對網格流量進行更加細粒度的控制。比如，可能希望將流量以百分比分配到不同的服務版本，作爲 A/B 測試的一部分，或者將不同的負載均衡策略應用於特定服務實例版本，又或者你可能還想將特殊規則應用於進出網格的流量等等。以上這些都可以通過使用 Istio 流量管理 API ——虛擬服務（Virtual Service）以及目標規則（Destination Rule）實現。

“Istio流量策略控制” 視頻公開課

今天我們主要討論Destination Rule。前面我們提到的負載均衡、熔斷策略、連接池策略都是配置在Destination Rule上的。

Destination Rule定義在發生路由後應用於服務流量的策略。這些規則指定負載平衡的配置，Sidecar的連接池大小以及離羣值檢測設置，以從負載平衡池中檢測和清除不正常的主機。我們可以將虛擬服務視爲將流量如何路由到給定目標地址，然後使用目標規則來配置該目標的流量。在評估虛擬服務路由規則之後，目標規則將應用於流量的“真實”目標地址。

Destination rules 是 Istio 流量路由的關鍵功能，它不能獨自使用，必須跟 Virtual Service 共同發揮作用。當 Destination rules 跟 Virtual Service 共同使用的時候，Virtual Service 決定將流量路由到邏輯地址，而 Destination rules 則決定流量路由到物理地址。

視頻中，我們會詳細介紹Destination Rule的功能和應用。

視頻詳解“Istio流量控制”

https://v.qq.com/x/page/w0972p3lquh.html

Istio技術實踐專題(9) 收官-路由控制與灰度發佈

Istio路由控制與灰度發佈。

上一期我們講到，虛擬服務（Virtual Service）以及目標規則（Destination Rule）是 Istio 流量路由的兩大基石。虛擬服務可以將流量路由到 Istio 服務網格中的服務。每個虛擬服務由一組路由規則組成，這些路由規則按順序進行評估。

如果沒有 Istio virtual service，僅僅使用 k8s service 的話，那麼只能實現最基本的流量負載均衡轉發，但是就不能實現類似按百分比來分配流量等更加複雜、豐富、細粒度的流量控制了。

使用Istio的流量管理模型，本質上是將流量與基礎設施擴容進行解耦，讓運維人員可以通過Pilot指定流量遵循什麼規則，而不是指定哪些pods/VM應該接收流量。通過將流量從基礎設施擴展中解耦，就可以讓 Istio 提供各種獨立於應用程序代碼之外的流量管理功能。這些功能都是通過部署的Envoy sidecar代理來實現的。

在使用 Istio實現灰度發佈的情況下，流量路由和副本部署是兩個完全獨立的功能。服務的 pod 數量可以根據流量負載靈活伸縮，與版本流量路由的控制完全無關。這在自動縮放的情況下能夠更加簡單地管理金絲雀版本。

Istio收官之講：路由控制與灰度發佈

在靈雀雲ASM平臺中單獨做了自動化灰度發佈的功能。我們創建灰度規則時，將複製原服務版本（金絲雀）配置，創建出後綴爲primary的服務版本（主版本），同時流量將全部切換至主版本，金絲雀版本實例數調度爲0。通過更新金絲雀版本配置觸發灰度發佈，灰度發佈時，調度金絲雀版本實例，並按照發布規則將流量切換至配置更新後的金絲雀版本。發佈完成後，將金絲雀配置複製到主版本，金絲雀實例重新調度爲0，由主版本提供最新服務。

在發佈過程中，流量將每隔“流量增加週期”，按照“每次流量增加比例”分配至灰度版本，直至比例達到100%。同時通過“指標配置”監控灰度版本的流量狀態。若本次增加流量的平均請求成功率小於“最小請求成功比例”，或者平均響應時間大於“最大響應時間”，則異常次數加1，且暫停下個週期流量的增加。暫停期過後，在下次調度開始時，再次檢查流量是否滿足指標配置。若流量異常總次數達到“觸發回滾異常次數”，則進行回滾。

本期視頻分爲上下兩輯：

Istio路由控制與灰度發佈（上）

https://v.qq.com/x/page/r0976bxupp5.html

Istio路由控制與灰度發佈（下）

https://v.qq.com/x/page/a0976m1p7sj.html

至此，“從小白到專家Istio技術實踐”專題已更新九集，課程圓滿完結！

假如你需要微服務架構中引入 Istio，並用它來解決微服務治理中的諸多難題，那麼，本系列的內容不可錯過！

靈雀雲Istio技術實踐專題整理

Istio技術實踐專題(1) Service Mesh Istio 基本概念和架構基礎

什麼是Service Mesh？

微服務體系帶來的問題

首當其衝是定位和調試困難。

第二，測試時數據會有遺漏，缺少完整的測試數據。

第三，缺少上線流程。

第四，微服務間的網絡調用策略配置不靈活。

什麼是Istio？

Istio系統架構

Istio 安全架構

Istio 安全目標：

Istio 安全組件：

感謝參考

Istio技術實踐專題(2) Istio 核心組件介紹

Istio架構回顧

Istio核心組件

Sidecar ( 在 Istio 中，默認的 Sidecar 是 Envoy )

Pilot

Mixer

Istio-telemetry

Istio-policy

Citadel

Istio-galley

Istio-sidecar-injector

Istio-ingressgateway

感謝參考

Istio技術實踐專題(3) 在K8s集羣上部署Istio的三種方式

使用 Istioctl 安裝

附件操作命令案例詳解

從外部Chart安裝

安裝其他配置文件（demo）

顯示可用配置文件的列表

顯示配置文件的配置

查看整個配置的子集

顯示配置文件中的差異

安裝前生成清單

驗證安裝成功

使用 Helm 自定義安裝

添加 Helm chart 倉庫

安裝步驟

方案 1: 使用 helm template 命令安裝

方案 2: 在 Helm 和 Tiller 環境中使用 helm install 命令安裝

卸載

三、安裝獨立 Operator

更新

卸載

Istio技術實踐專題(4) 應用接入Istio的正確姿勢

用什麼姿勢接入 istio？

Istio的幾個基本資源對象：

網關功能：Gateway

流量分配：按比例，根據請求內容

根據比例：

根據請求內容決定路由：

超時，重試功能

Istio技術實踐專題(5) 應用服務網關

Istio技術實踐專題(6) Istio監控與跟蹤

Istio技術實踐專題(7) 30分鐘講透Istio訪問與控制

“Istio訪問與控制”視頻公開課

Istio技術實踐專題(8) Istio流量控制 Destination Rule

主題Istio的流量策略。

設置負載均衡

熔斷策略

連接池策略

“Istio流量策略控制” 視頻公開課

Istio技術實踐專題(9) 收官-路由控制與灰度發佈

Istio路由控制與灰度發佈。

Istio收官之講：路由控制與灰度發佈