(以後補充)

02 服務網格的基本特性

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

03 Istio基本介紹

1. Istio核心組件及功能

   • 數據面:Sidecar.通過註入方式和業務容器共存於一個Pod,會支持業務應用容器的流量,並接受控制面組件的控制,同時會向控制面輸出日誌,跟蹤及監控數據
   • 控制面:Istio核心,管理Istio的所有功能
   • 

   1. Pilot

      Pilot是Istio主要控制點,Istio流量由Pilot管理由Sidecar執行完成.

      • 從k8s或其他平臺的註冊中心獲取服務信息,完成服務發現過程
      • 讀取Istio各項控制配置,在進行轉換後將其發給sidecar進行執行
      • sidecar根據pilot指令,將路由,服務,監聽,集群等定義信息轉換為本地配置,完成控制行為本地化.

      

   2. Mixer

      主要功能:

      • 預檢
      • 匯報

      

      Mixer中包含多個adapter來處理預檢和報告.

   3. Citadel

      早期版本稱之為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所控制.

      

2. 核心配置對象

   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綁定.
3. 小結

04 Istio快速入門

1. 環境介紹

   對kubernets的環境要求如下:

   • Kubernets1.9+
   • 具備管理權限的kubectl及其配置文件,能夠操作測試集群
   • Kubernetes集群要有獲取互聯網鏡像的能力
   • 支持istio的自動註入功能,需要檢查kubernetes API Server啟動參數,保證其中admission control 部分按順序啟用MutatingAdmissionWebhook ,ValidatingAdmissionWebhook

2. 快速部署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

3. 部署兩個版本的服務

   #!/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

4. 部署客戶端服務

5. 驗證服務

6. 創建目標規則和默認路由

7. 小結

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

05 用Helm部署Istio

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

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

1. 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組件

2. 全局變量介紹

   我們使用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.

3. Istio安裝清單的生成和部署

   • 編輯values.yaml

     1. 鏡像地址

     如果是內網部署,首先要解決鏡像地址問題,一般在具備外網連接的服務器上拉取所需鏡像,然後導出鏡像,將其推送到本地私有鏡像庫,

     如果我們想獲取其中使用的鏡像名稱,就可以用grep方便過濾出來

     grep -r image:istio-demo.yaml|egrep -o -e "image:."| sort |uniq

     得到這些鏡像名稱之後,就進行鏡像的拉取和推送.根據入私庫地址,修改values.yaml中各個鏡像地址,生成新的安裝清單文件,然後重新用上述命令進行檢查.

     2. 系統資源

     根據實際情況調整各個組件的資源分配.默認設置是非常保守的.

     3. 服務類型

     Istio的istio-ingressgateway服務的默認類型是Loadbalncer,如果在部署的Kubernetes集群中沒有lb支持,就需要對服務類型進行修改.

     4. 可視化組件的服務開放

     在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

4. 小結

06 Istio常用功能

1. 在網格中部署應用

   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. 準備測試應用

      略

2. 修改Istio配置

   略

3. 使用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. 學習和定制 略

4. 使用Prometheus

   1. 訪問prometheus

      默認是開啟的.

      http://localhost:9090

   2. 開放prometheus服務

      prometheus的Service通過values.yaml定制對服務開放方式

   3. 學習和定制

      略

5. 使用Jaeger

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

   1. 啟用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

   2. 訪問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

   3. 跟蹤參數的傳遞:

      (以後有時間再補充)

   4. 開放Jaeger服務

      • 修改服務類型方式
      • 使用Ingress Controller

6. 使用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.

7. 小結

07 HTTP流量管理

1. 定義目標規則

   當Kubernetes訪問一個服務時,需要指定其協議,服務名和端口,Istio的服務網格中對服務進行了進一步抽象

   • 可以使用Pod標簽對具體服務進程進行分組
   • 可以定義服務的負載均衡策略
   • 可以為服務指定TLS要求
   • 可以為服務設置連接池大小

   Kubernetes中,Service和Deployment或其他工作負載關系是一對一.如下圖所示:

   

   而在Istio中,Service經常會對應不同的Deployment,如下圖所示:

   

2. 定義默認路由

   Istio建議為每個服務都創建一個默認路由,在訪問某一服務時如果沒有特定的路由規則,則使用默認路由規則來訪問指定的子集,以此來確保服務在默認情況下的行為穩定性.

3. 流量的拆分和遷移

   通過設置權重來拆分流量

   如果不聲明權重,其默認為100

   流量分配是有權重的,且權重總和必須是100

4. 金絲雀部署

   定義:

   • 就是在發布新版本時,部署的新版本並不對外開放,而是選擇一小部分用戶作為測試目標,這部分用戶對服務的訪問會指向特定版本,通過對這些金絲雀用戶的使用情況觀察,來確定新版本服務的發布效果,在確定結果之前,所有其他用戶都繼續使用原有版本
   • 在金絲雀用戶訪問時產生的流量http header中會有一行lab:canary.我們用它區別用戶,其他用戶全都訪問舊版本.

5. 根據來源服務進行路由

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

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

6. 對URI進行重定向

   根據URL進行重定向對目標路由進行分流 .

7. 通信超時控制

   • 微服務間進行相互調用時,由於服務問題或網絡故障影響 發生超時在所難免,對這種情況 不加控制,通常需要等待默認的超時時間,會導致業務處理時間大幅度處長.如果故障繼續存在,往往會造成業務積壓,到了一定程序後會導致故障擴散,造成大面積故障.
   • 即使全部加以控制(對於某一服務的調用,一旦超過一定時間則自動終止該調用),但由於服務和業務情況多變,需要不斷調整控制過程來進行調整和優化.如有哪些調用點需要控制,每個調用節的超時應該設置多少,修改其中一點之後,會對其他調用點的超時設置產生什麽樣的影響.而且這種調整意味著很多重復工作,往往需要非常多的人力和時間投入才能達到較好效果.
   • 通過 Istio的流量控制可以對服務間的超時進行控制,在應用無感知情況下,根據VirtualService配置,動態調整調用過程中的超時上限,從而達到控制故障範圍的目的.相對於代碼修改,這種非***調整方式能夠節省大量成本.

8. 故障重試控制

   • 服務間調用過程中,有時會發生閃斷情況,目標服務在短時間內不可用,此時如果進行重試,則可能會繼續順利完成調用.
   • 和通信超時控制一樣,都是用於應對故障的常用手段.無須開發介入,直接在運行環境中對故障重試行為進行調整,能夠極大增強系統彈性和健壯性.
   • 問題復雜了,重試有超時設置,服務調用本身也有超時設置,兩者如何協調?
   • 對於重試的超時設置和總體的超時設置,可以將重試超時和重試次數的乘積與總體的超時進行比較,哪個小,哪個設置就會優先生效.

9. 入口流量管理

   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. 配置入口流量的路由

      使用過程中可以直接查如何使用,此處略

10. 出口流量管理

    默認情況下網格內部無法對外網網絡請求,但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對外部訪問有了更大的管理能力.

11. 新建Gateway控制器

    略

12. 設置服務熔斷

    • 服務熔思是種保護性措施,即在服務實例無法正常提供服務情況下將其多Lb池中移除,不再為其分配任務,避免在故障實例上積壓更多任務,並且可以在等待服務能力恢復後,重新將發生故障的Pod加入LB池.這是常見的服務降級方法.
    • Istio中提供了非***式的服務熔斷功能.只需要設置DestinationRule對象即可完成.

13. 故障註入測試

    微服務測試過程中,往往需要對網絡故障場景進行模擬,Istio提供了以下兩種故障註入能力:

    1. 註入延遲
       • percent:百分比,用於指定註入延遲的比率,默認為100
       • fixedDelay:表明延遲的時間長度,必須大於1毫秒
    2. 註入中斷

14. 流量復制

    • 另一個強大的測試功能,它可以把指向一個服務版本的流量復制一份出來發發送給另一個服務版本.這一功能能夠將生產流量導入測試應用.在復制出來的鏡像流量發出之後不會等待響應,因此對正常應用的性能影響較小,又能在不影響代碼的情況下,用更實際的數據對應用進行測試.

08 Mixer適配器的應用

1. Mixer適配器簡介
2. 基於Denier適配器的訪問控制
3. 基於Listchecker適配器的訪問控制
4. 使用memQuota適配器進行服務限流
   1. Mixer對象的定義
   2. 客戶端對象的定義
   3. 測試限流功能
   4. 註意事項
5. 使用RedisQuota適配器進行服務限流
   1. 啟動Redis服務
   2. 定義限流相關對象
   3. 測試限流功能
6. 為Prometheus定義監控指標
   1. 默認監控指標
   2. 自定義監控指標
7. 使用stdio輸出自定義日誌
   1. 默認的訪問日誌
   2. 定義日誌對象
   3. 測試輸出
8. 使用Fluentd輸出日誌
   1. 部署Fluentd
   2. 定義日誌對象
   3. 測試輸出
9. 小結

09 Istio的安全加固

1. Istio安全加固概念
2. 啟用mTLS
3. 設置RBAC
4. RBAC的除錯過程

10 Istio的試用建議

1. Istio自身的突出問題
2. 確定功能範圍
3. 選擇試用業務
4. 試用過程
   1. 制定目標
   2. 方案部署
   3. 測試驗證
   4. 切換演練
   5. 試點上線

導入markdown文件時,圖片丟失,請下載附件PDF文件查看.

http://down.51cto.com/data/2459723

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