Istio流量管理实践之(3): 基于Istio实现流量对比分析
流量鏡像
流量鏡像，也稱為影子流量，流量鏡像提供一種盡可能低的風險為生產帶來變化的強大功能。鏡像會將實時流量的副本發送到鏡像服務。鏡像流量發生在主服務的關鍵請求路徑之外。
在非生產或者測試環境中，嘗試訪問一個服務所有可能的測試用例組合是個非常不現實的任務。 在某些情況下，編寫這些用例的所有工作也可能與實際生產所需的用例不匹配。在理想情況下，可以使用實時的生產用例和流量來幫助完善在測試環境中錯過的功能區域。
一旦我們能夠可靠地鏡像流量，就可以開始做一些有價值的事情，例如通過請求流量對比工具Diffy，可以將引入測試集群的流量與生產集群中的預期行為進行比較。例如，我們可能想比較請求結果與預期結果間的偏差，或是API協議中的數據損壞情況，以便更好地兼容。
除此之外，需要注意：
當流量鏡像到不同的服務時，會發生在請求的關鍵路徑之外；
忽略對任何鏡像流量的響應; 流量被視為“即發即忘”；
流量對比
此處，插入一個代理就可以負責此類流量的協調，并對其進行有趣的比較。Diffy就是一款這樣的代理工具。Diffy啟動一個代理服務（例如監聽端口8880），再根據用戶設置的primary、secondary兩個舊服務地址（primary和secondary代碼完全相同，目的是為了減少噪音干擾）、candidate新服務地址。
它還能夠檢測結果中的噪音，并通過先調用兩個實時服務的實例來忽略它們（例如時間戳，單調遞增計數器等提示），總結來說就是檢測，然后在測試服務中忽略掉這部分。
Diffy還提供了一個不錯的頁面可以用來查看調用結果、對比情況、和基于某些特征的過濾。它還有一個很好的管理控制臺，可以查看有關調用比較結果的功能指標（metrics）和統計數據（statistics）。
創建用于Istio流量鏡像的服務
在此任務中，將首先強制所有流量到 v1 版本的服務。然后，將使用規則將一部分流量鏡像到 v2版本。
首先部署兩個版本的示例服務。
版本1的部署使用了Docker鏡像httpbin，提供常見的http請求訪問：
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mirrorservice-sample-v1
spec:
replicas: 1
template:
版本2的部署使用了自定義的Docker鏡像，對應的Dockerfile如下：
FROM nginx:latest
COPY default.conf /etc/nginx/conf.d/
EXPOSE 80
所需的nginx 配置文件:
server {
listen 44134; server_name localhost;location / {proxy_pass http://httpbin-diffy.diffy:8880/;proxy_http_version 1.1;proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade"; }}
版本2的部署作為Istio的流量鏡像目標，在接收到流量之后會轉發到Diffy的代理中。當前沒有直接將Diffy代理作為Isito流量鏡像目標，原因是Diffy代理與Envoy代理目前本身有沖突，無法正常流量轉發，因此需要此部署中轉一下。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: mirrorservice-sample-v2
spec:
replicas: 1
template:
對應的Kubernetes service:
apiVersion: v1
kind: Service
metadata:
name: mirrorservice-sample
spec:
type: ClusterIP
ports:
- name: http
port: 44134
selector:
app: mirrorservice-sample創建流量鏡像的Istio策略
默認情況下，Kubernetes 在服務的兩個版本之間進行負載均衡。創建如下流量鏡像規則將 100％ 的流量發送到 v1， 同時指定流量鏡像到v2。當流量被鏡像時，請求將通過其主機/授權報頭發送到鏡像服務附上 -shadow 。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mirrorservice-sample
spec:
host: mirrorservice-sample
subsets:
-
name: v1
version: v1
labels: -
name: v2
version: v2
labels:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: mirrorservice-sample
spec:
hosts:
http:
-
route:
-
destination:
host: mirrorservice-sample subset: v1weight: 100
-
搭建Diffy用于請求流量對比
Diffy可以作為代理，截取請求并發送至所有運行的服務實例，通過對比響應結果來發現每次迭代代碼中可能存在的問題。其中，Diffy上運行了三類代碼實例：
線上穩定版本：一個運行線上穩定版本代碼的節點
線上穩定版本備份：同樣運行了線上的穩定版本，用于消除噪音
測試版本：待上線的測試版本，用于和線上環境代碼進行對比
在實際Diffy測試中，會發現大部分的接口都會有一定差異，原因是這些響應中存在了噪音，噪音可能包括：
server響應中生成的時間戳
隨機生成的數字
系統服務間的有條件競爭
Diffy能夠通過一定的方式，清除這類噪音，保證分析結果不被影響。
創建Diffy及示例服務
通過以下YAML創建Diffy服務：
apiVersion: v1
kind: Service
metadata:
name: httpbin-diffy
labels:
spec:
ports:
- name: http-proxy
port: 8880 - name: http-admin
port: 8881 - name: http-console
port: 8888
selector:
app: httpbin-diffyapiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
name: httpbin-diffy-v2
spec:
replicas: 1
selector:
template:
metadata:labels:app: httpbin-diffyversion: v2 spec:containers:- image: lordofthejars/diffy:1.0imagePullPolicy: IfNotPresentlivenessProbe:exec:command:- curl- localhost:8888initialDelaySeconds: 10periodSeconds: 60timeoutSeconds: 1name: httpbin-diffyargs: ["-candidate=httpbin-candidate:8080", "-master.primary=httpbin-master:8080", "-master.secondary=httpbin-master:8080", "-service.protocol=http", "-serviceName=httpbin", "-proxy.port=:8880", "-admin.port=:8881", "-http.port=:8888", "-rootUrl='localhost:8888'"]ports:- containerPort: 8888name: http-consoleprotocol: TCP- containerPort: 8880name: http-proxyprotocol: TCP- containerPort: 8881name: http-adminprotocol: TCPreadinessProbe:exec:command:- curl- localhost:8888initialDelaySeconds: 10periodSeconds: 60timeoutSeconds: 1securityContext:privileged: false通過以下YAML創建示例所用的primary、secondary(當前示例中與primary相同)與candidate服務：
apiVersion: v1
kind: Service
metadata:
name: httpbin-master
labels:
spec:
ports:
- name: http
port: 8080
selector:
app: httpbin version: v1apiVersion: v1
kind: Service
metadata:
name: httpbin-candidate
labels:
spec:
ports:
- name: http
port: 8080
selector:
app: httpbin version: v2apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: httpbin-v1
spec:
replicas: 1
template:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: httpbin-v2
spec:
replicas: 1
template:
發送流量進行鏡像驗證
啟動 sleep 服務，這樣就可以使用 curl 來提供負載：
cat <<EOF | istioctl kube-inject -f - | kubectl create -f -
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: sleep
spec:
replicas: 1
template:
EOF
進入到SLEEP_POD， 具體POD名稱根據實際賦值。
kubectl exec -it $SLEEP_POD -c sleep sh
發送流量：
curl -v http://mirrorservice-sample:44134/headers
可以查看 v1的訪問日志記錄，如下所示創建的請求100%指向了v1。
與此同時，查看Diffy的Web界面，可以看到創建的請求也被鏡像到Diffy Proxy：
Diffy能夠通過一定的方式，清除這類噪音，保證分析結果不被影響。
結論
流量鏡像提供一種盡可能低的風險為生產帶來變化的強大功能。鏡像會將實時流量的副本發送到鏡像服務，鏡像流量發生在主服務的關鍵請求路徑之外。一旦我們能夠可靠地鏡像流量，就可以開始做一些有價值的事情，例如通過請求流量對比工具Diffy，可以將引入測試集群的流量與生產集群中的預期行為進行比較。
支持流量鏡像只是 Istio 的眾多功能之一，它將使基于大型微服務的應用程序的生產部署與管理變得更加簡單。歡迎大家使用阿里云上的容器服務，快速搭建微服務的開放治理平臺Istio，比較簡單地集成到自己項目的微服務開發中。
總結
以上是生活随笔為你收集整理的Istio流量管理实践之(3): 基于Istio实现流量对比分析的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Python之在函数中使用列表作为默认参
- 下一篇： 我的VS CODE