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

分手后的思念是犯贱 2023-02-22 05:06 11阅读 0赞

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

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

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

此部分直接参考的istio官方的[BookInfo示例][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测试一下接口：  
![测试][20200701173513168.gif_pic_center]  
通过上面的postman请求，我们可以看出：同一个url的请求在多次访问下会出现不同的结果，因为svca-service的v1和v2版本中加入了\*\*\[\]\[\]\[v2\]\[\]\[\]\*\*这个字符串以做版本区分  
![svca-service代码变动][svca-service]  
其访问的kiali监控面板如下：  
![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][]来实现

[k8s yaml]: https://blog.csdn.net/puhaiyang/article/details/105738550
[helm_shell]: https://blog.csdn.net/puhaiyang/article/details/106925885
[jenkins]: https://blog.csdn.net/puhaiyang/article/details/106934404
[service mesh_istio]: https://blog.csdn.net/puhaiyang/article/details/106948850
[istio]: https://blog.csdn.net/puhaiyang/article/details/107206635
[BookInfo]: https://istio.io/latest/zh/docs/examples/bookinfo/
[20200701173513168.gif_pic_center]: https://img-blog.csdnimg.cn/20200701173513168.gif#pic_center
[svca-service]: https://img-blog.csdnimg.cn/20200701174445315.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1aGFpeWFuZw==,size_16,color_FFFFFF,t_70
[svca-service_kiali]: https://img-blog.csdnimg.cn/20200701174613987.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3B1aGFpeWFuZw==,size_16,color_FFFFFF,t_70#pic_center
[spring-cloud-kubernetes]: https://github.com/spring-cloud/spring-cloud-kubernetes