第一步:
找到對應的版本
第二步:
執行yaml文件
[root@VM-0-15-centos istio-1.5.9]# kubectl apply -f istio-1.5.9/install/kubernetes/istio-demo.yaml
第三步
等待pod都running,這里可能等待時間較長,因為要拉取鏡像,如果有拉取鏡像失敗,可以嘗試docker pull去拉取
第四步:
創建pod,這里要注意的是一個service關聯了2個deployment,並且2個deployment內容並不一樣,一個v1,一個v2
[root@VM-0-15-centos ~]# cat flaskapp.yaml apiVersion: v1 kind: Service metadata: name: flaskapp labels: app: flaskapp spec: selector: app: flaskapp ports: - name: http port: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: flaskapp-1 spec: replicas: 1 selector: matchLabels: app: flaskapp template: metadata: labels: app: flaskapp version: v1 spec: containers: - name: flaskapp image: dustise/flaskapp imagePullPolicy: IfNotPresent env: - name: version value: v1 --- apiVersion: apps/v1 kind: Deployment metadata: name: flaskapp-2 spec: replicas: 1 selector: matchLabels: app: flaskapp template: metadata: labels: app: flaskapp version: v2 spec: containers: - name: flaskapp image: dustise/flaskapp imagePullPolicy: IfNotPresent env: - name: version value: v2
[root@VM-0-15-centos ~]# kubectl apply -f flaskapp.yaml service/flaskapp created deployment.apps/flaskapp-1 created deployment.apps/flaskapp-2 created
查看pod
現在我們將istio注入到pod,可以看到istio已經注入到pod當中了
部署客戶端,如下:
[root@VM-0-15-centos ~]# vim sleep.yaml kind: Service metadata: name: sleep labels: app: sleep version: v1 spec: selector: app: sleep version: v1 ports: - name: ssh port: 80 --- apiVersion: apps/v1 kind: Deployment metadata: name: sleep spec: selector: matchLabels: app: sleep version: v1 replicas: 1 template: metadata: labels: app: sleep version: v1 spec: containers: - name: sleep image: dustise/sleep imagePullPolicy: IfNotPresent
[root@VM-0-15-centos ~]# kubectl apply -f sleep.yaml service/sleep created deployment.apps/sleep created
給sleep.yaml也加上istio
[root@VM-0-15-centos ~]# istioctl kube-inject -f sleep.yaml | kubectl apply -f -
查看
驗證服務,可以看到基本上是輪調
接下來我們用istio來控制這2個服務的流量,我們定義一個名字為flaskapp的destinationrule,它利用Pod標簽把flaskapp服務分成兩個subset,分別為v1和v2
[root@VM-0-15-centos ~]# cat flaskapp-destinationrule.yaml apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: flaskapp spec: host: flaskapp subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2
[root@VM-0-15-centos ~]# kubectl apply -f flaskapp-destinationrule.yaml destinationrule.networking.istio.io/flaskapp created
接下來就需要為flaskapp服務創建默認規則,不論是否進行進一步的流量控制,我們都應該給它創建默認路由,以防止發生意料之外的訪問結果
如下:我們定義的規則為凡是訪問flaskapp這個主機的都交給v2這台主機做相應
[root@VM-0-15-centos ~]# vim flaskapp-default-vs-v2.yaml kind: VirtualService metadata: name: flaskapp-default-v2 spec: hosts: - flaskapp http: - route: - destination: host: flaskapp subset: v2
[root@VM-0-15-centos ~]# kubectl apply -f flaskapp-default-vs-v2.yaml virtualservice.networking.istio.io/flaskapp-default-v2 created
再次驗證,可以看到流量都跑到了v2上面
istio其他操作
以上是手動注入istio,我們也可以自動注入istio
- 如果將 sidecarinjectorWebhook enabled 設置為 true 就會開啟 Sidecar 自動注入特性
- 如果將 enableNamesp cesByDefault 變量賦值為 true ,就會為所有命名空間開啟自動注入功能,如果賦值為false,則只有標簽為istio-injection:enabled的命名空間才會開啟自動注入功能·
- autolnject 這個變量命名有歧義 它的 enabled di abl 賦值,設置的並不是是否開啟自動注入功能,而是在啟用自動注入功之后,對於指定命名空間內新建Pod 是否進行自動注人 如果取值為 enabled,則該命名空間內的pod只要沒有被注解為sidecar.istio.io/inject: "false",就會自動完成注入,如果取值為disabled,則需要為pod設置注解sidecar. istio.io/inject:”true”,才會進行注入
案例:
我們常見了2個命名空間auto和manually,並且給auto打上自動注入istio的標簽
然后分別在這兩個命名空間下創建pod,可以看到,auto下的pod自動注入了istio,而manually下的pod卻沒有
istio的自動注入可與根據標簽進行例外設置,不管命名空 標簽及策略如何 對符和標簽選擇器要求的pod都不能進行注入,也可以選擇對有此標簽的才進行注入,多個標簽間是或的關系。
格式如下:
istio-grafana安裝
默認istio的grafana是沒有安裝的,我們可以選擇安裝
[root@VM-0-15-centos istio-1.5.9]# helm template ./install/kubernetes/helm/istio -n test --set grafana.enabled=true --namespace istio-system > default-grafana.yaml
然后修改service以便訪問
打開瀏覽器
如果要打開prometheus直接編輯svc就可以訪問