Istio 核心組件的作用了解

Proxy[Envoy]：

　　Proxy在Istio架構中必須要有，Envoy是由Lyft開發並開源，使用C++編寫的高性能代理，負責在服務網格中服務的進出流量。Istio使用Envoy代理的擴展版本。Envoy是用c++開發的高性能代理，用於協調服務網格中所有服務的所有入站和出站流量。Envoy代理是唯一與數據平面通信交互的Istio組件。Envoy代理被部署為服務的sidecars，在邏輯上增加了Envoy的許多內置特性，例如:

• 動態服務發現
• 負載平衡
• TLS終止
• HTTP/2和gRPC代理
• 斷路器
• 健康檢查
• 分階段推出基於%的流量分割
• 故障注入
• 豐富的指標

　　為什么選擇Envoy?

　　對於Sidecar/Proxy其實不僅僅可以選擇Envoy，還可以用Linkerd、Nginx和NginMesh等。像Nginx作為分布式架構中比較廣泛使用的網關，Istio默認卻沒有選擇，是因為Nginx沒有Envoy優秀的配置擴展，Envoy可以實時配置。

Mixer ：

　　Mixer在Istio架構中不是必須的，Mixer是一個獨立於平台的組件。Mixer跨服務網格執行訪問控制和使用策略，並從特使代理和其他服務收集遙測數據。代理提取請求級屬性，並將它們發送到Mixer進行評估。Mixer包括一個靈活的插件模型。該模型使Istio能夠與各種主機環境和基礎設施后端進行交互。因此，Istio從這些細節中抽象出Envoy代理和Istio管理的服務。

• 為集群執行訪問控制，哪些用戶可以訪問哪些服務，包括白名單檢查、ACL檢查等
• 策略管理，比如某個服務最多只能接收多少流量請求
• 遙測報告上報，比如從Envoy中收集數據[請求數據、使用時間、使用的協議等]，通過Adpater上報給Promethues、Heapster等

Pilot：

　　Pilot在Istio架構中必須要有，Pilot為 Envoy sidecars 提供服務發現、用於智能路由的流量管理功能(例如，A/B測試、canary滾動等)和彈性(超時、重試、斷路器等)。Pilot將控制流量行為的高級路由規則轉換為特定於環境的配置，並在運行時將它們傳播到sidecars。Pilot將特定於平台的服務發現機制抽象出來，並將它們合成為任何符合Envoy API的sidecar都可以使用的標准格式。下圖顯示了平台適配器和特使代理如何交互。

 

Galley:

　　Galley在Istio架構中不是必須的,主要負責istio配置的校驗、各種配置之間統籌，為istio提供配置管理服務。通過kubernetes的webhook機制對pilot和mixer的配置進行驗證。

Citadel:

　　Citadel在Istio架構中不是必須的,Citadel支持強大的服務對服務和終端用戶身份驗證，內置身份和憑證管理。您可以使用Citadel來升級服務網格中的未加密流量。使用Citadel，運營商可以執行基於服務身份的策略，而不是相對不穩定的第3層或第4層網絡標識。從0.5版開始，您可以使用Istio的授權特性來控制誰可以訪問您的服務。在有一些場景中，對於安全要求是非常高的，比如支付，所以Citadel就是用來保證安全的。

Istio 官方Demo  Bookinfo:

　　官網：https://istio.io/docs/examples/bookinfo/

　　該應用程序由四個單獨的微服務組成，用於演示各種Istio功能。該應用程序顯示有關書籍的信息，類似於在線書籍商店的單個目錄條目。頁面上顯示的是書的說明，書的詳細信息（ISBN，頁數等）和一些書評。Bookinfo應用程序分為四個單獨的微服務：

• productpage。該productpage微服務調用details和reviews微服務來填充頁面。
• details。該details微服務包含圖書信息。
• reviews。該reviews微服務包含了書評。它還稱為ratings微服務。
• ratings。該ratings微服務包含預定伴隨書評排名信息。

　　reviews微服務有3個版本：

• 版本v1不會調用該ratings服務。
• 版本v2調用該ratings服務，並將每個等級顯示為1到5個黑星。
• 版本v3調用該ratings服務，並將每個等級顯示為1到5個紅色星號。

　　該應用程序的端到端體系結構如下所示。

　　該應用程序是多語言的，即微服務以不同的語言編寫。值得注意的是，這些服務不依賴於Istio，而是提供了一個有趣的服務網格示例，特別是由於服務的多樣性，服務的語言和版本reviews。要使用Istio運行示例，無需更改應用程序本身。相反，您只需要在啟用Istio的環境中配置和運行服務，並在每個服務旁邊注入Envoy輔助工具。最終的部署將如下所示：

　　所有微服務都將與Envoy sidecar 打包在一起，該Envoy sidecar 攔截對服務的呼入和呼出，並通過Istio控制平面，路由，遙測收集和整個應用程序的策略實施提供外部控制所需的鈎子。

Sidecar自動注入到微服務：

　　官網 ：https://istio.io/docs/examples/bookinfo/#start-the-application-services

1.默認的Istio安裝使用自動sidecar注入。標簽的名稱空間，它將在啟用 istio-injection=enabeld的情況下托管應用程序

　　kubectl label namespace default istio-injection=enabled
　　kubectl get namespaces --show-labels

2.查看所需鏡像，並且下載，所有節點

　　下載鏡像：

docker pull    istio/examples-bookinfo-details-v1:1.8.0        
docker pull    istio/examples-bookinfo-ratings-v1:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v1:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v2:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v3:1.8.0        
docker pull    istio/examples-bookinfo-productpage-v1:1.8.0 

3.創建資源  kubectl apply -f istio-1.0.6/samples/bookinfo/platform/kube/bookinfo.yaml

4.kubectl get pods

5.kubectl get svc

6.測試一下是否成功

kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"

　　成功顯示如下：

通過ingress方式訪問：

1.創建ingress規則，productpage-ingress.yaml

#ingress apiVersion: extensions/v1beta1 kind: Ingress metadata: name: productpage-ingress spec: rules: - host: productpage.istio.wuzz.com http: paths: - path: / backend: serviceName: productpage servicePort: 9080

 　　kubectl apply -f  productpage-ingress.yaml

　　kubectl get ingress

2.訪問測試 productpage.istio.wuzz.com ,記得用虛擬機的在本地hosts添加域名映射

通過istio的ingressgateway訪問：

　　官網：https://istio.io/docs/examples/bookinfo/#determine-the-ingress-ip-and-port

1.istio-1.0.6/samples/bookinfo/networking/bookinfo-gateway.yaml 可以查看一下該yaml文件，一個是Gateway，一個是VirtualService

　　kubectl apply -f bookinfo-gateway.yaml

2.Confirm the gateway has been created:

　　kubectl get gateway

3.set the INGRESS_HOST and INGRESS_PORT variables for accessing the gateway

export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].status.hostIP}')
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

4.Set GATEWAY_URL :

export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

5.查看INGRESS_PORT端口  env | grep INGRESS_PORT  ，比如結果為31380

7.測試不斷訪問測試，發現會訪問的review的不同版本,可以設置規則：

 

8.Apply default destination rules

　　官網 ：https://istio.io/docs/examples/bookinfo/#apply-default-destination-rules

　　Before you can use Istio to control the Bookinfo version routing, you need to define the available versions, called subsets, in destination rules

　　kubectl apply -f istio-1.0.6/samples/bookinfo/networking/destination-rule-all.yaml

體驗Istio的流量管理:

　　流量這塊就體現了Pilot和Envoy的功能

基於版本的路由：

　　官網 ：https://istio.io/docs/tasks/traffic-management/request-routing/#apply-a-virtual-service

　　之前刷新productpage頁面的時候，發現review的版本一直會變，能不能一直訪問某個版本呢？

 　　在 istio-1.0.6/samples/bookinfo/networking/ 目錄下有很多的測試用的 yaml。

1.比如v3   istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-v3.yaml   kubectl apply -f virtual-service-reviews-v3.yaml   

2.再次訪問測試：http://192.168.1.102:31380/productpage  一直在V3版本

基於用戶身份的路由：

　　官網 ：https://istio.io/docs/tasks/traffic-management/request-routing/#route-based-on-user-identity

1.根據對應文件創建資源 istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

2.測試：

# 使用jason來登錄[右上角有Sign in的功能或者url?u=jason]，一直會訪問到v2版本
On the /productpage of the Bookinfo app, log in as user jason.
Refresh the browser. What do you see? The star ratings appear next to each
review.
# 使用其他用戶登錄，一直會訪問到v1版本
Log in as another user (pick any name you wish).
Refresh the browser. Now the stars are gone. This is because traffic is routed
to reviews:v1 for all users except Jason.

基於權重的路由：

1.根據對應文件創建資源 istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml一半幾率訪問到v1，一半幾率訪問到v3，這里就相當於之前的藍綠部署、AB測試或灰度發布，權重加起來必須是100

　　kubectl apply -f virtual-service-reviews-50-v3.yaml

2.測試

故障注入：

　　官網 ：https://istio.io/docs/tasks/traffic-management/fault-injection/

1.創建一個故障注入規則，使得jason用戶訪問v2到ratings有7秒種的延遲

　　kubectl apply -f virtual-service-ratings-test-delay.yaml

2.使用jason賬戶登錄，並且訪問productpage頁面，會得到這樣的一個返回信息 

　　Error fetching product reviews!  Sorry, product reviews are currently unavailable for this book.

3.View the web page response times:

　　Open the Developer Tools menu in you web browser.Open the Network tab   Reload the /productpage web page. You will see that the page actually loads in  about 6 seconds.

流量遷移：

　　官網 ：https://istio.io/docs/tasks/traffic-management/traffic-shifting/

1.讓所有的流量都到v1

　　kubectl apply -f virtual-service-all-v1.yaml

2.將v1的50%流量轉移到v3

　　kubectl apply -f virtual-service-reviews-50-v3.yaml

3.確保v3版本沒問題之后，可以將流量都轉移到v3

　　kubectl apply -f virtual-service-reviews-v3.yaml

4.訪問測試，看是否都訪問的v3版本

體驗Istio的Observe：

　　這塊就體現了Mixer和Envoy的功能

　　通過 Mixer 收集數據匯報到  Prometheus。

收集Metrics：

　　官網 ：https://istio.io/docs/tasks/observability/metrics/collecting-metrics/

1.kubectl apply -f metrics-crd.yaml

# Configuration for metric instances
apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: doublerequestcount
  namespace: istio-system
spec:
  compiledTemplate: metric
  params:
    value: "2" # count each request twice
    dimensions:
      reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")
      source: source.workload.name | "unknown"
      destination: destination.workload.name | "unknown"
      message: '"twice the fun!"'
    monitored_resource_type: '"UNSPECIFIED"'
---
# Configuration for a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
  name: doublehandler
  namespace: istio-system
spec:
  metrics:
  - name: double_request_count # Prometheus metric name
    instance_name: doublerequestcount.instance.istio-system # Mixer instance name (fully-qualified)
    kind: COUNTER
    label_names:
    - reporter
    - source
    - destination
    - message
---
# Rule to send metric instances to a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: doubleprom
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler.prometheus
    instances:
    - doublerequestcount

2.Send traffic to the sample application

　　http://192.168.1.102:31380/productpage

3.創建ingress。訪問prometheus

#ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prometheus-ingress
  namespace: istio-system
spec:
  rules:
  - host: prometheus.istio.wuzz.com
    http:
      paths:
      - path: /
        backend:
          serviceName: prometheus
          servicePort: 9090

　　http://prometheus.istio.wuzz.com

4.根據 istio_request_bytes_count 進行查詢

5.Understanding the metrics configuration

　　https://istio.io/docs/tasks/observability/metrics/collecting-metrics/#understanding-the-metrics-configuration

查詢Istio的metrics

　　官網 ：https://istio.io/docs/tasks/observability/metrics/querying-metrics/

　　This task shows you how to query for Istio Metrics using Prometheus. As part of this task, you will use the web-based interface for querying metric values.

1.訪問productpage

　　http://192.168.1.102:31380/productpage

2.打開prometheus界面

　　http://prometheus.istio.wuzz.com

3.)輸入查詢指標

　　istio_requests_total

4.About the Prometheus add-on

　　https://istio.io/docs/tasks/observability/metrics/querying-metrics/#about-the-prometheus-add-on

分布式追蹤之Jaeger：

　　官網 ：https://istio.io/docs/tasks/observability/distributed-tracing/overview/

1.查看jaeger的svc

　　kubectl get svc -n istio-system | grep jae

　　kubectl get svc jaeger-query -n istio-system -o yaml

2.配置jaeger的ingress jaeger-ingress.yaml

#ingress apiVersion: extensions/v1beta1 kind: Ingress metadata: name: jaeger-ingress namespace: istio-system spec: rules: - host: jaeger.istio.itcrazy2016.com http: paths: - path: / backend: serviceName: jaeger-query servicePort: 16686

3.瀏覽器訪問測試  jaeger.istio.wuzz.com ,就能看到調用鏈路。

4.發送100個請求 

for i in `seq 1 100`; do curl -s -o /dev/null http://192.168.1.102:31380/productpage; done

5.進入到jaeger界面選擇productpage，查詢詳情

Mesh可視化之Kiali：

　　官網 ：https://istio.io/docs/tasks/observability/kiali/

Helm：

　　官網 ：https://istio.io/docs/setup/install/helm/  要使用 Helm 安裝 Istio 參考官網。這也是推薦的

　　Helm是Kubernetes的軟件包管理工具，類似於Ubuntu中的apt、CentOS中的yum等。可以快速查找、下載和安裝軟件包，Helm由客戶端組件helm和服務端組件tiller組成。解決的問題。比如在K8S中部署一個wordpress，需要創建deployment，service，secret、pv等。這些資源有時候不方便管理，過於分散，如果使用kubectl進行操作，發現還是比較惡心的。所以簡單來說，helm就是為了解決上述問題。

　　各種名詞概念：

• chart：helm的打包格式叫chart，chart即一系列文件，描述了一組相關的k8s集群資源
• helm：客戶端命令行工具，用於本地開發及管理chart、chart倉庫等
• tiller：helm的服務端，tiller接收helm的請求，與k8s的apiserver打交道，根據chart生成一個release並且管理release
• release：helm install命令在k8s集群中部署的chart稱為release
• repository helm chart：helm客戶端通過http協議來訪問存儲庫中chart的索引文件和壓縮包

　　圖解Helm原理：

　　release操作

創建release
 (1)helm 客戶端從指定的目錄或本地tar文件或遠程repo倉庫解析出chart的結構信息
 (2)helm 客戶端指定的 chart 結構和 values 信息通過 gRPC 傳遞給 Tiller
 (3)Tiller 服務端根據 chart 和 values 生成一個 release
 (4)Tiller 將install release請求直接傳遞給 kube-apiserver
刪除release
 (1)helm 客戶端從指定的目錄或本地tar文件或遠程repo倉庫解析出chart的結構信息
 (2)helm 客戶端指定的 chart 結構和 values 信息通過 gRPC 傳遞給 Tiller
 (3)Tiller 服務端根據 chart 和 values 生成一個 release
 (4)Tiller 將delete release請求直接傳遞給 kube-apiserver
更新release
 (1)helm 客戶端將需要更新的 chart 的 release 名稱 chart 結構和 value 信息傳給Tiller
 (2)Tiller 將收到的信息生成新的 release，並同時更新這個 release 的 history
 (3)Tiller 將新的 release 傳遞給 kube-apiserver 進行更新

安裝Helm:

　　以這個版本 helm-v2.13.1-linux-amd64.tar.gz 為例，

• 放到k8s集群master節點解壓tar -zxvf helm-v2.13.1-linux-amd64.tar.gz
• 復制helm二進制到 bin目錄下，並且配置環境變量查
  • cp linux-amd64/helm /usr/local/bin/
  • export PATH=$PATH:/usr/local/bin
• 看是否安裝成功  helm version

 　　這樣子就成功了

安裝Tiller：

　　重新安裝tiller：helm reset -f

1.安裝tiller

　　helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

　　kubectl get pods -n kube-system -l app=helm

　　kubectl get svc -n kube-system -l app=helm

 

2.配置rbac

cat >helm-rbac-config.yaml<<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF

　　kubectl create -f helm-rbac-config.yaml

　　配置tiller使用創建的ServiceAccount

　　kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

3.驗證

　　查看pod啟動情況 kubectl get pod -n kube-system -l app=helm

　　再次查看版本，顯示出server版本  helm version

 使用helm操作chart

helm create:創建一個chart模板，比如：helm create test  --->ls test
helm package:打包一個chart模板，比如：helm package test  --->test-0.1.0.tgz
heml search:查找可用的chart模板，比如：helm search nginx
helm inspect:查看指定chart的基本信息，比如：helm inspect test
helm install:根據指定的chart部署一個release到k8s集群，比如：helm install test  --->get pods

chart模板
　　chart文件結構

wordpress
├── charts              # 存放chart的定義
├── Chart.yaml            # 包含chart信息的yaml文件，如chart的版本、名稱等
├── README.md             # chart的介紹信息
├── requirements.lock
├── requirements.yaml         # chart需要的依賴
├── templates             # k8s需要的資源
│  ├── deployment.yaml
│  ├── externaldb-secrets.yaml
│  ├── _helpers.tpl         # 存放可重用的模板片段
│  ├── ingress.yaml
│  ├── NOTES.txt
│  ├── pvc.yaml
│  ├── secrets.yaml
│  ├── svc.yaml
│  └── tls-secrets.yaml
└── values.yaml            # 當前chart的默認配置的值

　　關於更多的 Helm的信息可以查看其官網 https://github.com/helm/helm/releases