網絡彈性也稱爲運維彈性,是指網絡在遇到災難事件時快速恢復和繼續運行的能力。災難事件的範疇很普遍,好比長時間停電、網絡設備故障、惡意入侵等。html
工做中經常會碰到這樣的開發、測試場景,好比:「對方處理請求時間過長,沒有及時響應,咱們的程序要怎麼處理來確保不會無限期地等待」。常見的處理方式是被調用方使用 sleep 語句模擬響應時間過長,調用方設定請求超時時間太短,來形成請求超時的結果。可是這種處理方法有不少的弊端,第一:本屬於網絡彈性層的東西,卻須要在代碼中體現;第二:超時時間設置過長可能致使過多的延遲、設置太短可能致使沒必要要的失敗,所以超時時間須要動態調整。基於上面兩個弊端,Istio 使用虛擬服務來優雅實現超時處理。nginx
本實例須要結合 Istio 故障注入模擬被調用方響應請求慢的場景,有關 Istio 失敗注入之延遲請參考本人的另一篇博文,簡單到讓你分分鐘輕鬆完爆。web
該實例的架構圖以下:docker
架構說明以下,本實例就是模擬客戶端調用 nginx,nginx 將請求轉發給 tomcat 的常見功能。tomcat 響應請求設置爲 5s(經過故障注入實現,至關於 sleep 5s 邏輯),nginx 設置 client 的請求超時時間爲 2s。由於 nginx 須要在 2s 內返回給 client,而 nginx 請求 tomcat 卻須要 5s,所以模擬 client 調用 nginx 超時的情景。api
該實例資源文件一共有 4 個,分別以下:tomcat
client.yaml # 客戶端資源網絡
deploy.yaml # nginx、tomcat 的 deployment 資源架構
svc.yaml # nginx、tomcat 的 service 資源app
vs.yaml # Istio 虛擬資源運維
資源內容以下圖所示:
apiVersion: apps/v1 kind: Deployment metadata: name: client spec: replicas: 1 selector: matchLabels: app: client template: metadata: labels: app: client spec: containers: - name: busybox image: busybox imagePullPolicy: IfNotPresent command: ["/bin/sh", "-c", "sleep 3600"]
資源內容以下圖所示:
--- apiVersion: apps/v1 kind: Deployment metadata: name: nginx labels: server: nginx app: web spec: replicas: 1 selector: matchLabels: server: nginx app: web template: metadata: name: nginx labels: server: nginx app: web spec: containers: - name: nginx image: nginx:1.14-alpine imagePullPolicy: IfNotPresent --- apiVersion: apps/v1 kind: Deployment metadata: name: tomcat labels: server: tomcat app: web spec: replicas: 1 selector: matchLabels: server: tomcat app: web template: metadata: name: tomcat labels: server: tomcat app: web spec: containers: - name: tomcat image: docker.io/kubeguide/tomcat-app:v1 imagePullPolicy: IfNotPresent
資源內容以下圖所示:
--- apiVersion: v1 kind: Service metadata: name: nginx-svc spec: selector: server: nginx ports: - name: http port: 80 targetPort: 80 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: tomcat-svc spec: selector: server: tomcat ports: - name: http port: 8080 targetPort: 8080 protocol: TCP
Istio 虛擬服務資源內容以下所示:
--- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: jiuxi-nginx-vs spec: hosts: - nginx-svc http: - route: - destination: host: nginx-svc timeout: 2s --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: jiuxi-tomcat-vs spec: hosts: - tomcat-svc http: - fault: delay: percentage: value: 100 fixedDelay: 5s route: - destination: host: tomcat-svc
此虛擬服務有兩個知識點。
第一:故障注入:
http: - fault: delay: percentage: value: 100 fixedDelay: 5s該設置說明每次調用 tomcat-svc 的 k8s service,都會延遲 5s 纔會調用。
第二:調用超時:
hosts: - nginx-svc http: - route: - destination: host: nginx-svc timeout: 2s該設置說明調用 nginx-svc 的 k8s service,請求超時時間是 2s。
在上面咱們編寫完樣例,下面準備部署。
須要對 client 和 deploy 資源文件進行 Istio 注入,將 client、nginx、tomcat 都放入到網格中。本人是手工注入 Istio 方式,若是你設置了自動 Istio 注入不會影響,同樣能夠輕鬆完爆。
istioctl kube-inject -f client.yaml | kubectl apply -f -
istioctl kube-inject -f deploy.yaml | kubectl apply -f -
執行成功後,經過 kubectl get pods 查看 Istio 注入狀況:
部署 svc.yaml:
kubectl apply -f svc.yaml
部署 vs.yaml:
kubectl apply -f vs.yaml
由於要用到 nginx 對 tomcat 的轉發功能,所以須要對 nginx 作一些設置:
登陸 nginx pod:
kubectl exec -it nginx-7559f7d487-djzbb -- sh
編輯 nginx 配置文件:
vi /etc/nginx/conf.d/default.conf
添加和修改以下內容:
編輯完後,再執行以下語句驗證配置和讓配置生效:
自此,整個樣例配置和部署完畢。
登陸 client,執行以下語句:
kubectl exec -it client-5b77d5949f-nzdtl -- sh
執行以下語句:
wget -q -O - http://nginx-svc
執行結果以下所示:
/ # time wget -q -O - http://nginx-svc wget: server returned error: HTTP/1.1 504 Gateway Timeout Command exited with non-zero status 1 real 0m 2.02s user 0m 0.00s sys 0m 0.00s
說明 timeout 樣例運行成功。
也能夠一樣驗證故障注入效果,執行以下語句:
/ # time wget -q -O - http://tomcat-svc <!DOCTYPE html> <html lang="en"> ... </html> real 0m 5.01s user 0m 0.00s sys 0m 0.00s
執行效果是請求 5s 後纔會返回,說明 Istio 故障注入(延遲 5s)運行成功。