1. 程式人生 > >istio1.0 實現藍綠發布(未完成)

istio1.0 實現藍綠發布(未完成)

containe orm ice sub ctr mda lse metadata ons

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(解決報錯的)

istio1.0 實現藍綠發布(未完成)