istio1.0 實現藍綠髮布 環境: 192.168.0.91 master 192.168.0.92 node 第一步:安裝k8s集羣,參照:https://www.cnblogs.com/effortsing/p/10312081.html 第二步:安裝 istio1.0 參照:https://www.cnblogs.com/effortsing/p/10603392.html 第三步:部署同一個應用的兩個版本 咱們構建了簡單的基於Nginx的Docker鏡像來做爲應用案例:janakiramm/myapp:v1和janakiramm/myapp:v2。 部署完成以後,這兩個版本的Nginx會分別顯示藍色或者綠色背景的靜態頁面。咱們用這些圖像來完成咱們的教程 cat>myapp.yaml<<EOF apiVersion: extensions/v1beta1 kind: Deployment metadata: name: myapp-v1 spec: replicas: 1 template: metadata: labels: app: myapp version: v1 spec: containers: - name: myapp image: janakiramm/myapp:v1 imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: myapp-v2 spec: replicas: 1 template: metadata: labels: app: myapp version: v2 spec: containers: - name: myapp image: janakiramm/myapp:v2 imagePullPolicy: IfNotPresent ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: myapp labels: app: myapp spec: type: ClusterIP ports: - port: 80 name: http selector: app: myapp EOF 咱們先從建立YAML文件開始,來定義V1和V2版本Nginx的部署,同時也設置集羣IP把服務暴露出來。請注意咱們用不一樣的標籤來區分Pods——app和版本。由於兩次部署的版本號不同,app名字能夠相同。 這是Istio所但願的,像單一的app那樣處理它們,用不一樣的個版原本區分。 集羣的服務定義也是同樣的,標籤app: myapp關聯了基於不一樣版本所建立的Pod。 經過kubectl來建立deployment和service。注意deployment和service是Kubernetes的相關術語,和Istio沒有關係。惟一和Istio的關聯是咱們爲deployment和service建立標籤的方式 kubectl apply -f myapp.yaml [root@test2 ~]# kubectl apply -f myapp.yaml deployment.extensions/myapp-v1 created deployment.extensions/myapp-v2 created service/myapp created [root@test2 ~]# kubectl get pod NAME READY STATUS RESTARTS AGE myapp-v1-58c55dbfb6-lcvzq 1/1 Running 0 48s myapp-v2-5c8c686fc6-4v4mn 1/1 Running 0 48s [root@test2 ~]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 22d myapp ClusterIP 10.100.239.218 <none> 80/TCP 4m 配置Istio以前,咱們先來檢查一下app的版本。咱們能夠經過port-forward deployments訪問Pod。經過運行下面的命令訪問V1的8080端口。準備好CTRL+C kubectl port-forward deployment/myapp-v1 8080:80 訪問: 能夠看到下面的訪問結果中倒數第5行是nignx的V1版本 [root@test2 ~]# curl http://10.100.239.218:80 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Sample Deployment</title> <style> body { color: #ffffff; background-color: blue; font-family: Arial, sans-serif; font-size: 14px; } h1 { font-size: 500%; font-weight: normal; margin-bottom: 0; } h2 { font-size: 200%; font-weight: normal; margin-bottom: 0; } </style> </head> <body> <div align="center"> <h1>Welcome to V1 of the web application</h1> <h2>This application will be deployed on Kubernetes.</h2> </div> </body> </html> 運行下面的命令訪問V2的8081端口,繼續CTRL+C kubectl port-forward deployment/myapp-v2 8081:80 訪問: 能夠看到下面的訪問結果中倒數第5行是nignx的vNext版本 [root@test2 ~]# curl http://10.100.239.218:80 <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Sample Deployment</title> <style> body { color: #ffffff; background-color: green; font-family: Arial, sans-serif; font-size: 14px; } h1 { font-size: 500%; font-weight: normal; margin-bottom: 0; } h2 { font-size: 200%; font-weight: normal; margin-bottom: 0; } </style> </head> <body> <div align="center"> <h1>Welcome to vNext of the web application</h1> <h2>This application will be deployed on Kubernetes.</h2> </div> </body> </html> 第四步:配置藍綠部署 咱們的實驗目標是讓流量有選擇的訪問某一個部署,並且不能有服務中止。爲了達到這目的,咱們要告訴Istio依照權重來路由流量 爲了達到這個效果咱們須要設置三個對象: 網關 Istio網關描述了在網格邊界的負載均衡器如何處理進出的HTTP/TCP鏈接。着重描述了哪些端口應該被暴露出來,有哪些協議能夠用,負載均衡器的SNI配置等等。 接下來,咱們把網關指向默認的Ingress網關,它在Istio安裝的時候就被建立出來了 建立網關: cat>apigatway.yaml<<EOF apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: app-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF kubectl create -f apigatway.yaml 報錯以下:(暫時不作了) [root@test2 ~]# kubectl create -f apigatway.yaml Error from server (Timeout): error when creating "apigatway.yaml": Timeout: request did not complete within allowed duration 目的地規則 Istio目的地規則定義了流量被路由之後訪問服務的規則。請注意在Kubernete中這個規則是如何利用標籤來聲明的。 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: myapp spec: host: myapp subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2 虛擬服務 虛擬服務定義了當主機得到地址之後一系列流量的路由規則。每一條路由規則都定義了某個基於特定協議的流量的匹配規則。當一個流量被匹配了,基於版本,它會被髮送到相關的目標服務 在下面的操做中,咱們聲明瞭V1和V2的權重都爲50,這就意味着流量會被平均分配 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: myapp spec: hosts: - "*" gateways: - app-gateway http: - route: - destination: host: myapp subset: v1 weight: 50 - destination: host: myapp subset: v2 weight: 50 參照:http://dockone.io/article/8297 https://it.baiked.com/kubernetes/3444.html(未作成) https://blog.csdn.net/qq_33093199/article/details/51397628(解決報錯的)https://blog.csdn.net/liukuan73/article/details/81165716http://blog.itpub.net/28624388/viewspace-2199899/http://blog.itpub.net/28624388/viewspace-2199899/https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/81571517https://istio.io/docs/setup/kubernetes/additional-setup/sidecar-injection/ (官網這個簡單的sleep實例都作不成)