深刻淺出Istio:Service mesh快速入門與實踐-讀書筆記(By GisonWin)

時間 2019-11-05

標籤深刻 istio service mesh 快速入門實踐讀書筆記 gisonwin 简体版

原文原文鏈接

01 服務網格歷史

(之後補充)node

02 服務網格的基本特性

鏈接
- 微服務錯綜複雜,要完成其業務目標,鏈接問題是首要問題.鏈接存在於全部服務的整個lifcecycle中,用於維持服務的運行.
安全
- 保障網格間安全,須要具有服務間通訊加密,服務身體認證和服務訪問控制(受權和鑑權)等功能
- 認證失敗後如何處理,外部證書(統一CA)接入,簽發,傳播和更新等
策略
- 對調用頻率的限制,對服務互訪的控制以及針對流量的限制和變動
- Mixer做爲Istio中執行者,Envoy每次調用,邏輯上都會經過Mixer進行事先預檢和過後報告
觀察
- 隨着服務數量增多,監控和跟蹤的需求水漲船高.所以可觀察的保障就成爲系統功能的重要組成部分,也是系統運維功能的重要保障
- 將服務器視爲無個性,可替換的基礎設施.若是機器發生故障,直接替換其便可.
- 服務的健康情況是一系列的連續狀態,如咱們關注服務的調用成功率,響應時間,調用量,傳輸量
- 網格還應提供分佈式跟蹤(Distributed Tracing)能力,對服務的調用鏈路進行跟蹤

03 Istio基本介紹

Istio核心組件及功能python
- 數據面:Sidecar.經過注入方式和業務容器共存於一個Pod,會支持業務應用容器的流量,並接受控制面組件的控制,同時會向控制面輸出日誌,跟蹤及監控數據
- 控制面:Istio核心,管理Istio的全部功能
1. Pilotweb
  
  Pilot是Istio主要控制點,Istio流量由Pilot管理由Sidecar執行完成.shell
  - 從k8s或其餘平臺的註冊中心獲取服務信息,完成服務發現過程
  - 讀取Istio各項控制配置,在進行轉換後將其發給sidecar進行執行
  - sidecar根據pilot指令,將路由,服務,監聽,集羣等定義信息轉換爲本地配置,完成控制行爲本地化.
2. Mixerjson
  
  主要功能:flask
  - 預檢
  - 彙報
  Mixer中包含多個adapter來處理預檢和報告.後端
3. Citadelapi
  
  早期版本稱之爲istio-CA,因此它就是用於管理證書的.在集羣中啓用了服務之間加密後,負責爲集羣中各個服務在統一CA條件下生成證書,並下發給各個服務中的Sidecar.數組
4. SideCar(Envoy)安全
  - 是Istio中的數據面,負責控制面對網格控制的實際執行者角色
  - Istio默認的Sidecar是由Envoy派生的,理論上只支持Envoy的xDS協議,其餘相似反向代理軟件均可以代替Envoy的角色.
  - Istio默認實現中,Istio經過istio-init初始化容器中的iptables指令,對全部的Pod流量進行支持,從而接管Pod中的應用通訊過程,得到通訊控制器,得以實現控制目標.
  - 同一個Pod內多個container間,網絡棧共享,因此sidecar得以實現,sidecar加入後,原來containe間直接通訊方式,經過container1-->sidecar1-->sidecar2-->container2的模式,因此通訊過程當中的控制和觀察被Pilot所控制.
核心配置對象

Istio安裝過程當中會進行CRD初始化,在k8s集羣中註冊一系列的CRD.用戶利用istio控制微服務間通訊就是經過向k8s提交CRD資源方式完成的.

istio中的資源:
1. networking.istio.io
  
  流量管理功能的執行者.
  
  如下爲最經常使用的對象:
  - Gateway
  - 訪問服務時,不管是網格內部的服務互訪仍是經過Ingress進入網格的外部流量,都要通過Gateway.
  - 它描述了邊緣接入對象設備:包含對外開放端口,主機名及可能存在的TLS證書的定義.
  - Ingress流量經過對應的istio Ingress Gateway Controler進入
  - 網格內部服務互訪經過虛擬mesh( sidecar)進行
  - Polit根據Gateway和主機名檢索,若是存在對應的VirtualService,則交由其處理,若是是Mesh gateway且不存在對應的主機名的VirtualService,則嘗試調用k8s Service,若是還不存在則報404 error
  - VirtualService
  - Host:該對象負責的主機名稱,在k8s集羣中,能夠是服務名
  - Gateway:流量來源網狀,也被稱爲mesh
  - 路由對象:網格中的流量.若是符合前面host,gateway條件,就須要根據實際協議對流量的處理方式進行區別,緣由是Http是一種透明協議,能夠通過對報文解析,完成更細緻的控制.而對於TCP流來講就不能完成過於複雜的任務.
  - TCP/TLS/HTTP Route
  - 路由對象能夠是http,tcp,tls中的一個,分別針對不一樣的協議進行工做.
  - 每一個路由對象至少包含兩部分:匹配條件和目的路由
  - httproute對象中包含匹配httpmatchrequest對象數組,以及描述目標服務的destinationweight對象,且httpmatchrequest匹配條件較爲豐富,能夠超時控制,重試,錯誤注入等.
  - Tcproute簡單不少,它的匹配藉助L4MatchAttributes對象完成,包含源標籤,gateway,地址和端口
  - DestinationWeight
  - 各協議路由的目標定義是一致的,都是destinationweight對象數組完成.它指到某個目標destination對象的流量權重,這意味着,多個目標能夠同時爲該virtualservice提供服務,並按照相權重進行流量分配
  - Destination
  - Subset:服務的一個子集,它在k8s中表明使用標籤選擇器區分的不一樣Pod.
  - Port:服務端口
2. config.istio.io
  
  該對象用於爲mixer組件提供配置.Mixer對數據的處理過程以下
  - Rule:Mixer入口,包含一個match成員和一個邏輯表達式,只有符合表達式判斷的數據纔會交給action處理.邏輯表達式中變動稱爲attribute,其中內容來自Envoy提交的數據
  - Action:將符合入口標準的數據,在用什麼方式加工以後,交給哪一個適配器進行處理.
  - Instance:使用Template對接收到數據進行處理
  - Handler:表明一個適配器實例,用於接收處理後的數據
  - Instance:用於爲進入的數據選擇一個模板,並在數據中抽取某些字段做爲模板的參數,傳輸給模板進行處理.
  - Adapter:Istio中定義的一個行爲規範,而一些必要的實例化數據是須要再次進行初始化的.只有數據獲得正式初始化後Adapter才能被投入使用.
  通過Handler實例化以後的Adapter,就具有了工做功能,有自身實現(listcheck,memquota)也有第三方實現(prometheus,datadog).Envoy傳出數據將會經過具體的Adapter處理,獲得預檢結果,或者輸出各類監控,日誌及跟蹤數據.
  - Template:用於對接收到的數據進行再加工.用戶編制模板對象後,通過模板處理原始數據會被轉換成符合適配器輸入要求的數據格式,就能夠在Instance字段中引用.
  - Handler:用於對Adapter進行實例化.
  Mixer管理了全部第三方資源接入,大大擴展了Istio的做用範圍,但應用難度系統增高.
3. authentication.istio.io
  
  用於定義認證策略.在網格級別,命名空間級別以及服務級別都提供了認證策略的要求.要求在內容中包含服務間通訊認證,及基於JWT的終端認證.
  - Policy:用於指定服務一級的認證策略,如將其命令爲default,則該對象所在命名空間會默認採用這一認證策略
  - 策略目標:服務名稱(主機名稱)及服務端口號
  - 認證方法:設置服務間認證的perrs子對象,用於設置終端認證的origins子對象.
  - MeshPolicy:只能被命名爲default,它表明全部網格內部應用默認認證策略,其餘部分和Policy一致.
4. rbac.istio.io
  
  用於基於RBAC(基於角色)訪問控制系統
  - ServiceRole:一系列規則rules組成,每條規則對應一條權限,其中描述了權限所對應的服務,服務路徑及方法,還能夠進行下定義的約束
  - ServiceRoleBinding:相似於k8s的RBAC,用於將用戶主體(用戶或服務)和ServiceRole綁定.
小結

04 Istio快速入門

環境介紹

對kubernets的環境要求以下:
- Kubernets1.9+
- 具有管理權限的kubectl及其配置文件,可以操做測試集羣
- Kubernetes集羣要有獲取互聯網鏡像的能力
- 支持istio的自動注入功能,須要檢查kubernetes API Server啓動參數,保證其中admission control 部分按順序啓用MutatingAdmissionWebhook ,ValidatingAdmissionWebhook
快速部署Istio

下載過程略

下載安裝包解壓後,進入安裝目錄,將bin目錄中的istioctl複製到PATH路徑中,而後開始部署istio
```
kubectl apply -f install/kubernetes/istio-demo.yaml
```
運行以下命令,查看istio-system namespace中pod啓動情況 ,-w 用於持續查詢Pod狀態的變化
```
kubectl get pods -n istio-system -w
```

部署兩個版本的服務

#!/usr/bin/env python3
from flask import Flask,request
import os
import urllib.request

app = Flask( name )

@app.route('/env/<env>')
def show_env(env) :
return os.environ . get(env)

@app.route('/fetch')
def fetch_env() :
url = request.args.get('url','')
with urllib.request.urlopen(url) as response:
    return response.read()
if __name__ =="__main__":
            app.run(host="0.0.0.0",port=80,debug=True)

咱們爲這個App建立兩個Deployment,將其分別命名爲flaskapp-v1,flaskapp-v2,同時建立一個service,命名爲flaskapp.

建立flaskapp.istio.yaml

apiVersion: v1
kind: Service
metadata: 
  name: flaskapp
  lables: 
     app: flaskapp
spec:
 selector:  
    app:flaskapp
  ports:
     -name: http
     port: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp-v1
spec:
  replicas: 1
  template:
    metadata:
      lables:
         app: flaskapp
         version: v1
    spec:
      containers:
        name: flaskapp
        image: distise/flashapp
        imagePullPolicy: IfNotPresent
        env:
          name: version
          value: v1
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: flaskapp-v2
spec:
  replicas: 1
  template:
    metadata:
      lables:
         app: flaskapp
         version: v2
    spec:
      containers:
        name: flaskapp
        image: distise/flashapp
        imagePullPolicy: IfNotPresent
        env:
          name: version
          value: v2

接下來使用istio進行注入.istioctl,基本做用是修改kubernetes Deployment.在Pod中注入前面提到的Sidecar 容器,並使用管道命令,將yaml文件經過istioctl處理以後經過管道輸出給kubectl.最終提交到Kuernetes集羣

istioctl kube-inject -f flask.istio.yaml |kuberctl apply -f -service/flaskapp created
#建立以後可看建立出來的Pod
kubectl get po -w
#也可使用kubectl describe po查看Pod容器
kubectl describe po flaskapp-v1-6647dd84b9-2ndf4

部署客戶端服務
驗證服務
建立目標規則和默認路由
小結

本章實踐了一個較爲典型的Istio服務上線流程:注入-->部署-->建立目標規則-->建立默認路由.絕大多數istio網格應用都會遵循這一流程進行上線.

05 用Helm部署Istio

經過前面知識咱們瞭解到,Istio由多個組件構成,而且能夠經過kubectl命令在Kubernetes集羣上進行部署,部署時會在Kubernetes集羣上建立大量對象,Istio與Kubernetes進行了深度集成,構成Istio的組件都以Deployment形式在Kubernetes中運行,並在運行過程當中所需的配置數據也須要依賴各類CRD及ConfigMap,Secret來進行存儲.

這種包含複雜依賴關係的應用部署過程,須要由功能足夠強大的模板系統來提供支持,Istio官方推薦使用Helm對istio進行部署.

Istio Chart概述

Istio Chart是一個總分結構,其分級結構和設計結構是一致的.
1. Chart.yml:chart基礎信息文件,包含版本號,名稱,關鍵字等元數據信息.
2. values-*.yml:
  - 提供Istio在各類場景下關鍵配置範本.能夠做爲Heml的輸入文件,來對Istio進行典型定製.
  - 可對這些輸入文件進行改寫,改寫完成後使用helm template命令生成最終部署文件.就能用Kubectl完成部署了.
  - values-istio-auth-galley.yaml:啓用控制面mTLS,默認打開網格內部的mTLS,啓用Galley
  - values-istio-multicluster.yaml:多集羣配置
  - values-istio-auth-multiclusterm.yaml:
  - values-istio-auth.yaml:
  - values-istio-demo-auth.yaml
  - values-istio-demo.yaml
  - values-istio-galley.yaml
  - values-istio-gateways.yaml
  - values-istio-one-namespace.yaml
  - values-istio-one-namespace-auth.yaml
  - values.yaml:羅列了絕大多數經常使用變量,也是咱們定製的基礎參考.
3. requirements.yaml
  
  該文件用於管理對子Chart的依賴關係,並定義了一系列形狀變量.
4. templates/_affinity.yaml:
  
  生成一組節點新和或互斥元素,供各個組件在渲染yaml時使用,定義一系列變量用於控制Istio組件節點親和性.
  - nodeAffinityRequiredDuringScheduling:
  - nodeAffinityPreferredDuringScheduling:
5. templates/sidecar-injector-configmap.yaml
  
  用於生成一個Configmap對象,在該對象中保存的配置數據被用於進行Sidecar注入.
6. templates/configmap.yaml:
  
  也生成一個ConfigMap,名稱爲istio,用於爲Pilot提供啓動配置數據.
7. templates.crds.yaml:
  
  包含Istio所需CRD定義,部署方式以下:
  - 若是使用Helm2.10以前版本,須要先使用kubectl提交該文件到Kubernetes集羣中
  - 若是使用Helm2.10以後版本,則Helm hook會自動提交安裝,無須關注
8. charts:
  
  這個目錄中的子目錄就是Istio的組件:
  - certmanager:一個基於Jestack Cert-manager項目的ACME證書客戶端,用於自動進行證書申請,獲取及分發
  - galley:Istio利用galley進行配置管理工做
  - gateways:對Gateways Chart進行配置,可發安裝多個Gateway Controller
  - grafana:圖形化的Istio Dashboard
  - ingress:一個遺留設計,默認關閉,在流量控制協議升級到network.istio.io.v1alpha3以後,已建議棄用
  - kiali:帶有分佈式跟蹤,配置校驗等多項功能的Dashboard
  - mixer:Istio策略實施組件
  - pilot:Istio流量管理組件
  - prometheus:監牢軟件,包含Istio特定的指標抓取設置
  - security:Citadel組件,用於證書的自動管理
  - serviegraph:分佈式跟蹤組件,用於獲取和展現服務調用關係圖,即將被棄用
  - sidecarInjectorWebhook:自動注入webhook的相關配置
  - tracing:分佈式跟蹤組件,使用Jaeger實現,替代原有的ServiceGraph組件
全局變量介紹

咱們使用Chart時,一般不會修改Chart本體,僅經過對變量的控制來實現對部署過程的定製.Istio Helm Chart提供了大量變量來幫助用戶對Istio進行定製.
1. hub&tag
  - 對內網部署很是有必要,將Istio鏡像Pull並推送到私庫後,只要在values.yaml修改就能夠將Istio所需鏡像的引用指向內網私庫.
  - 多數狀況下這兩個變量表明全部鏡像地址,具體名稱通常{{.Values.global.hub}}/[component]/:{{.Values.global.tag}}拼接而成.
  - 在proxy_init,mixer,grafana,polit的Deployment模板中,一量在其image變量中包含路徑符/,則會棄用global.hub,直接採用image的定義
  - ```
  {{- if contains "/".Values.image}}
     image: "{{.Values.image}}"
  {{- else}}
     image: "{{.Values.global.hub}}/{{.Values.image}}:{{.Values.global.tag}}"
  {{- end}}
```
2. ingress.enabled:
  
  用來控制是否啓用Istio的Ingress Controller,若是設置爲True,就會啓用Kubernetes Ingress資源的支持,Istio並不推薦Ingress方式,建議使用Ingress Gateway取代它．
3. Proxy relation args：
  
  在values.yaml定義了一級proxy變量,用於對Sidecar進行控制
  - proxy.resources
  - proxy.concurrency
  - proxy.accessLogFile
  - proxy.privileged
  - proxy.enableCoreDump
  - proxy.includeIPRanges
  - proxy.excludeIPRanges
  - proxy.includeInboundPort
  - proxy.autoInject
  - proxy.envoyStatsd
4. proxy_init.image
  
  網格中的服務Pod在啓前,首先會運行一個初始化鏡像來完成流量工做,這個變量能夠用於指定初始化容器鏡像
5. imagePullPolicy:
  
  鏡像摘取策略,default is IfNotPresent
6. controlPlaneSecurityEnabled
  
  指定是否在Istio控制面組件上啓用mTLS通訊.啓用後哦組件包括Ingress,Mixer,Pilot,Sidecar
7. disablePolicyChecks:
  
  設置爲True,會禁用Mixer的預檢功能.預檢功能是一個同步過程,有可能由於預檢緩慢形成業務應用的阻塞.
8. enableTracing:
  
  是否啓用分佈式跟蹤,default is True
9. mtls.enabled:
  
  服務之間是否默認啓用mTLS,若是設置爲True,則網格內服務間的通訊都會使用mTLS進行安全加固.這一設置是全局的,對每一個服務還能夠單獨使用目標規則或服務註解的方式,自行決定是否採用mTLS加固
10. imagPullSecrets:
  
  用於爲ServiceAccount分配鏡像拉取過程當中的所需的認證憑據.默認爲空
11. arch:
  
  在設置Istio組件的節點親和性過程當中,會使用這個變量的列表內容來肯定可用於部署的節點範圍 ,並按照不一樣的服務器架構設置了優先順序,它默認的列表內容以下:
```
amd64: 2
s390x: 2
ppc64ie: 2
```
12. oneNamespace:
  
  默認爲false.若是設置爲true,則會在Polit的服務發現參數中加入-a,此時Pilot只會對Istio組件所在的命名空間進行監控.
13. configValidation:
  
  用於配置是否開啓服務端的配置驗證,默認爲true.該選項開啓後,會生成一個ValidatingWebhookConfiguration對象,並被包含到Galley配置中,從而啓用校驗功能.
14. meshExpansion:
  
  要將服務網格擴展到物理或虛擬機上,會使用到,默認爲false.若是設置爲true,則會在Ingress Gateway上公開Pilot,Citadel的服務
15. meshExpansionILB:
  
  是否在內部網狀中公開Pilot和Citadel端口,默認爲false.
16. defaultResources:
  
  爲全部istio組件都提供一個最小資源限制.默認狀況下只設置一個請求10mCPU資源的值,能夠在各個Chart局部變量中分別設置資源需求
17. hyperkube:
18. priotyClassname
  
  默認爲空,可選值包括system-cluster-critical,system-node-critical
19. crds
  
  該變量用於決定是否包含CRD定義.若是使用helm template,或2.10後的版本helm install ,就將其設置爲true.不然在安裝以前首先要執行kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml.並將該變量設置爲false.
Istio安裝清單的生成和部署
- 編輯values.yaml
  1. 鏡像地址
  若是是內網部署,首先要解決鏡像地址問題,通常在具有外網鏈接的服務器上拉取所需鏡像,而後導出鏡像,將其推送到本地私有鏡像庫,
  
  若是咱們想獲取其中使用的鏡像名稱,就能夠用grep方便過濾出來
```
grep -r image:istio-demo.yaml|egrep -o -e "image:."| sort |uniq
```
  獲得這些鏡像名稱以後,就進行鏡像的拉取和推送.根據入私庫地址,修改values.yaml中各個鏡像地址,生成新的安裝清單文件,而後從新用上述命令進行檢查.
  1. 系統資源
  根據實際狀況調整各個組件的資源分配.默認設置是很是保守的.
  1. 服務類型
  Istio的istio-ingressgateway服務的默認類型是Loadbalncer,若是在部署的Kubernetes集羣中沒有lb支持,就須要對服務類型進行修改.
  1. 可視化組件的服務開放
  在Istio中包含的Prometheus,Grafana,Kiali等可視化組件,在默認狀態下都是ClusterIP類型,要順利使用,則可能須要爲其分配Ingress或者修改服務類型
- 生成部署清單
  
  使用helm template 生成最終部署清單.
```
helm template install/kubernetes/helm/listio --name istio --namespace istio-system -f my-values.yaml > my-istio.yaml
```
  命令完成後打開my-istio.yaml文件,檢查其中內容是否符合預期.
- 部署Istio
  
  上面生成的my-istio.yaml是要求部署到istio-system命名空間的,使用命令以下
```
kubectl create ns istio-system
```
```
kubectl apply -f my-istio.yaml
```
  命令運行完成後可用使用命令來查看Pod運行狀況,直至所有Pod成功進入Running或Completed狀態,Istio安裝部署工做就完成了
```
kubectl get po -n istio-system -w
```
小結

06 Istio經常使用功能

在網格中部署應用
```
istioctl kube-inject -f flash.istio.yaml -o flask.istio.injected.yaml
```
打開文件後發現Deployment對象有很大改變,多出了一個sidecar容器,並出現了一個初始化容器istio-init.
1. 對工做負載的要求
  - 要正確命令服務端口
  - 工做負載的Pod必須有關聯的Service
2. 使用自動注入
  - 若是將sidecarInjectorWebhook.enabled設置爲true,就會開啓Sidecar自動注入特性
  - enableNamespacesByDefault爲true,則會爲全部命名空間開啓自動注入功能.
  - autoInject,它設置的並非自動注入功能,而是在啓用自動注入功能以後,對於指定的命名空間內新建的Pod是否進行自動注入,若是取值爲enabled,則該命名空間內的Pod只要沒有被註解爲sidecar.istio.io/inject:false就會完成自動注入,若是取值爲disabled,則須要爲Pod設置註解爲sidecar.istio.io/niject:true纔會進行注入.
3. 準備測試應用
  
  略
修改Istio配置

略
使用Istio Dashboard

提供了條形圖,餅圖,表格,拆線圖等豐富的可視化組件.且對其中的數據源和可視化組件均可以二次開發.
1. 啓用Grafana
  
  默認未啓用grafana.啓動命令以下
```
helm template istio --name istio --set grafana.enabled=true --namespace istio-system > default-grafana.yaml
######
kubectl apply -f default-grafana.yaml
```
2. 訪問Grafana
```
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath-'{.items[0].metadata.name}') 3000:3000 &
```
  接下來打開 browser,type http://localhost:3000/ ,單擊左上角Home連接.打開Istio內置的Dashboard.
3. 開放Grafana服務
  
  kubectl端口轉發方式不是很穩定,要長期使用的話,對grafana進行定製.
  
  security.enabled=true並設置用戶名和密碼.
4. 學習和定製略
使用Prometheus
1. 訪問prometheus
  
  默認是開啓的.
  
  http://localhost:9090
2. 開放prometheus服務
  
  prometheus的Service經過values.yaml定製對服務開放方式
3. 學習和定製
  
  略

使用Jaeger

用於分佈式跟蹤的開源軟件.提供了原生的OpenTracing支持,向下兼容Zipkin,同時支持多種存儲後端.

啓用Jaeger

默認未啓用

helm template istio --name istio --set tracing.enabled=true --namespace istio-system > default-tracing.yaml
#########
kubectl apply -f default-tracing.yaml
#########
kubectl get po -w istio-system

訪問Jaeger:

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=jaeger -o jsonpath='{.items[0].metadata.name}') 16686:16686

browser,type

http://127.0.0.1:16686

跟蹤參數的傳遞:

(之後有時間再補充)
開放Jaeger服務
- 修改服務類型方式
- 使用Ingress Controller

使用Kiali

是用於Istio可視化軟件,它除了提供監控,可視化及跟蹤外還提供了Iistio配置驗證,健康評估等高級功能
1. 啓用kiali
  - 將kiali.enabled:true便可
  - 設置Ingress 出口
2. 訪問kiali
```
kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=kiali -o jsonpath='{.items[0].metadata.name}') 20001:20001
```
  browser,type http://localhost:20001
  
  tips:default username,password is admin:admin.
3. 開放kiali服務
  
  參考jaeger.
小結

07 HTTP流量管理

定義目標規則

當Kubernetes訪問一個服務時,須要指定其協議,服務名和端口,Istio的服務網格中對服務進行了進一步抽象
- 可使用Pod標籤對具體服務進程進行分組
- 能夠定義服務的負載均衡策略
- 能夠爲服務指定TLS要求
- 能夠爲服務設置鏈接池大小
Kubernetes中,Service和Deployment或其餘工做負載關係是一對一.以下圖所示:

而在Istio中,Service常常會對應不一樣的Deployment,以下圖所示:
定義默認路由

Istio建議爲每一個服務都建立一個默認路由,在訪問某一服務時若是沒有特定的路由規則,則使用默認路由規則來訪問指定的子集,以此來確保服務在默認狀況下的行爲穩定性.
流量的拆分和遷移

經過設置權重來拆分流量

若是不聲明權重,其默認爲100

流量分配是有權重的,且權重總和必須是100
金絲雀部署

定義:
- 就是在發佈新版本時,部署的新版本並不對外開放,而是選擇一小部分用戶做爲測試目標,這部分用戶對服務的訪問會指向特定版本,經過對這些金絲雀用戶的使用狀況觀察,來肯定新版本服務的發佈效果,在肯定結果以前,全部其餘用戶都繼續使用原有版本
- 在金絲雀用戶訪問時產生的流量http header中會有一行lab:canary.咱們用它區別用戶,其餘用戶全都訪問舊版本.
根據來源服務進行路由

根據不一樣版本的服務訪問不一樣版本的目標服務.

在上面的VirtualService定義裏,用sourceLabels對來源路由進行了匹配.
對URI進行重定向

根據URL進行重定向對目標路由進行分流 .
通訊超時控制
- 微服務間進行相互調用時,因爲服務問題或網絡故障影響發生超時在所不免,對這種狀況不加控制,一般須要等待默認的超時時間,會致使業務處理時間大幅度處長.若是故障繼續存在,每每會形成業務積壓,到了必定程序後會致使故障擴散,形成大面積故障.
- 即便所有加以控制(對於某一服務的調用,一旦超過必定時間則自動終止該調用),但因爲服務和業務狀況多變,須要不斷調整控制過程來進行調整和優化.若有哪些調用點須要控制,每一個調用節的超時應該設置多少,修改其中一點以後,會對其餘調用點的超時設置產生什麼樣的影響.並且這種調整意味着不少重複工做,每每須要很是多的人力和時間投入才能達到較好效果.
- 經過 Istio的流量控制能夠對服務間的超時進行控制,在應用無感知狀況下,根據VirtualService配置,動態調整調用過程當中的超時上限,從而達到控制故障範圍的目的.相對於代碼修改,這種非***調整方式可以節省大量成本.
故障重試控制
- 服務間調用過程當中,有時會發生閃斷狀況,目標服務在短期內不可用,此時若是進行重試,則可能會繼續順利完成調用.
- 和通訊超時控制同樣,都是用於應對故障的經常使用手段.無須開發介入,直接在運行環境中對故障重試行爲進行調整,可以極大加強系統彈性和健壯性.
- 問題複雜了,重試有超時設置,服務調用自己也有超時設置,二者如何協調?
- 對於重試的超時設置和整體的超時設置,能夠將重試超時和重試次數的乘積與整體的超時進行比較,哪一個小,哪一個設置就會優先生效.
入口流量管理

Kubernetes爲第三方廠商提供了Ingress Controler規範,用於入站流量管理.而Istio推出了Gateway,用於在網絡邊緣進行入站和出站的流量管理.

Ingress Gateway在邏輯上是至關於網絡邊緣上的一個負載均衡器,用於接收和處理網格邊緣出站和入門的網絡鏈接.

在前面流量管理中使用VirtualService對象,都默認包含gateways字段,若是沒有指定,則默認值爲:mesh.全部網格內部服務間互相通訊,都是經過這個網關進行的.若是要對外提供服務,須要定義Gateway對象,並在gateways字段中進行賦值.一量在gateways中填寫了mesh以外的對象名稱,就要繼續對內部通訊進行流量控制,並必須顯式地將內置的mesh對象名稱也加入列表中.
1. 使用Gateway開放服務
```
apiVersion:networking.istio.io/v1alpha3
kind:Gateway
metadata:
name: example-gateway
spec:
selector:
   istio: ingressgateway
servers:
   port: 
     number: 80
     name: http
     protocol: HTTP
   hosts:
     "*.microservice.rocks"
     "*.microservice.xyz"
```
  selector其實是一個標籤選擇器,用於指定哪些Gateway Pod負責這個Gateway對象的運行
  
  hosts字段用了一個通配符來指明這個gateway可能要負責的主機名.可使用kubectl get svc -n istio-system istio-ingressgateway 查看該服務的IP,並將測試域名映射這個IP
  
  將配置文件提交給Kubernetes集羣
```
kubectl apply -f example.gateway.yaml
############
http flaskapp.microservice.rocks
```
  訪問結果是404.回來發現並無指定負責響應請求的服務.咱們須要對路由規則進行修改
2. 爲Gateway添加證書支持
  
  使用過程當中能夠直接查如何使用,此處略
3. 爲Gateway添加多個證書支持
  
  使用過程當中能夠直接查如何使用,此處略
4. 配置入口流量的路由
  
  使用過程當中能夠直接查如何使用,此處略
出口流量管理

默認狀況下網格內部沒法對外網網絡請求,但Istio提供瞭如下幾種方式用於網格外部通訊
- 設置Sidecar流量劫持範圍:根據IP地址告知Sidecar哪些外部資源能夠放開訪問
- 註冊ServiceEntry:把網格外部的服務使用ServiceEntry的方式註冊到網格內部
1. 設置Sidecar的流量劫持範圍
  
  流量支持由istio-init容器完成.
  - 設置values.yaml中的proxy.includeIPRanges變量
  - 使用Pod註解.traffic.sidecar.istio.io/includeOutboundIpRanges,代表劫持範圍
2. 設置ServiceEntry
  
  能夠爲外部服務設置ServiceEntry,至關於外部服務在網格內部進行了註冊,相對於使用CIDR白名單方式,這種方式讓Istio對外部訪問有了更大的管理能力.
新建Gateway控制器

略
設置服務熔斷
- 服務熔思是種保護性措施,即在服務實例沒法正常提供服務狀況下將其多Lb池中移除,再也不爲其分配任務,避免在故障實例上積壓更多任務,而且能夠在等待服務能力恢復後,從新將發生故障的Pod加入LB池.這是常見的服務降級方法.
- Istio中提供了非***式的服務熔斷功能.只須要設置DestinationRule對象便可完成.
故障注入測試

微服務測試過程當中,每每須要對網絡故障場景進行模擬,Istio提供瞭如下兩種故障注入能力:
1. 注入延遲
  - percent:百分比,用於指定注入延遲的比率,默認爲100
  - fixedDelay:代表延遲的時間長度,必須大於1毫秒
2. 注入中斷
流量複製
- 另外一個強大的測試功能,它能夠把指向一個服務版本的流量複製一份出來發發送給另外一個服務版本.這一功能可以將生產流量導入測試應用.在複製出來的鏡像流量發出以後不會等待響應,所以對正常應用的性能影響較小,又能在不影響代碼的狀況下,用更實際的數據對應用進行測試.