采用rancher2+kubernetes+skywalking部署springcloud项目(五[istio蓝绿部署]-错误演示)

本系列文章目录
(一)基础k8s yaml脚本发布
(二)helm+shell脚本优化大量冗余配置发布
(三)jenkins用户审核的流水化方式部署
(四)service mesh(istio)服务网格化发布
(五)istio对项目进行金丝雀部署(待完成)

在有了上一篇采用rancher2+kubernetes+skywalking部署springcloud项目(四[istio服务网格化版本])的实战后,对istio有了一个初步简单的认识。

这一次我决定来把spring-boot-cloud项目中的svca-service做个蓝绿发布的测试

此部分直接参考的istio官方的BookInfo示例

创建两个版本的deployment

#-------------svca-service-----------------
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: svca-service-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: svca-service
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: svca-service
        version: v1
    spec:
      initContainers:
        - name: init-skywalking-agent
          image: ccr.ccs.tencentyun.com/haiyang/skywalking-agent:7.0.0
          command:
            - 'sh'
            - '-c'
            - 'set -ex;mkdir -p /vmskywalking/agent;cp -r /skywalking/agent/* /vmskywalking/agent;'
          volumeMounts:
            - mountPath: /vmskywalking/agent
              name: skywalking-agent
      containers:
        - image: ccr.ccs.tencentyun.com/spring-boot-cloud/svca-service:latest
          imagePullPolicy: Always
          name: svca-service
          ports:
            - containerPort: 8080
              protocol: TCP
          volumeMounts:
            - mountPath: /opt/skywalking/agent
              name: skywalking-agent
      volumes:
        - name: skywalking-agent
          emptyDir: {}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: svca-service-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: svca-service
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: svca-service
        version: v2
    spec:
      initContainers:
        - name: init-skywalking-agent
          image: ccr.ccs.tencentyun.com/haiyang/skywalking-agent:7.0.0
          command:
            - 'sh'
            - '-c'
            - 'set -ex;mkdir -p /vmskywalking/agent;cp -r /skywalking/agent/* /vmskywalking/agent;'
          volumeMounts:
            - mountPath: /vmskywalking/agent
              name: skywalking-agent
      containers:
        - image: ccr.ccs.tencentyun.com/spring-boot-cloud/svca-service:v2
          imagePullPolicy: Always
          name: svca-service
          ports:
            - containerPort: 8080
              protocol: TCP
          volumeMounts:
            - mountPath: /opt/skywalking/agent
              name: skywalking-agent
      volumes:
        - name: skywalking-agent
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: svca-service
spec:
  ports:
    - name: http
      port: 8080
      protocol: TCP
      targetPort: 8080
  selector:
    app: svca-service

上面的yaml定义了两个版本的svca-service

测试正常响应

通过postman测试一下接口:
测试
通过上面的postman请求,我们可以看出:同一个url的请求在多次访问下会出现不同的结果,因为svca-service的v1和v2版本中加入了**[][][v2][][]**这个字符串以做版本区分
svca-service代码变动
其访问的kiali监控面板如下:
svca-service的kiali监控面板
从上图可以看出对于一个发向svca-service的请求会最终发向svca-servcie的两个版本,也就是上图中的v1和v2。所以也就会出现postman里的情况,每次请求同一个url其结果不一样,因为有负载均衡服务在轮询不同的服务

蓝绿部署

此演示没有成功,可忽略

接下来演示蓝绿部署,将所有的服务的请求全执行到v2版本

添加一个DestinationRule和VirtualService

DestinationRule介绍:https://istio.io/latest/zh/docs/reference/config/networking/destination-rule/
VirtualService介绍:https://istio.io/latest/zh/docs/reference/config/networking/virtual-service/

然后执行下面的yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: svca-service
spec:
  hosts:
  - svca-service
  http:
  - route:
    - destination:
        host: svca-service
        subset: v2
---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: svca-service
spec:
  host: svca-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

执行完毕后,再进行测试
然后………………
在postman里观察请求是否全到了v2版本的svca-service,结果………………结果很尴尬!
与预期结果不一样,请求仍然是轮询的,这里就不贴图了。

分析原因
之所以在添加了VirtualService和DestinationRule的配置后仍然没有生效是因为这个项目是基于spring cloud的,访问服务时是通过spring cloud的ribbon框架来进行负载的,如果想通过istio来实现各种部署最快的办法是通过spring-cloud-kubernetes来实现

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章