手把手教你将传统应用改造成微服务，启用流量治理功能

现状

目前大多数用户，在使用KubeSphere微服务治理功能时，仅仅停留在部署bookinfo，“体验”一把微服务治理的功能而已。如果要完全使用微服务，仍然无法上手；更不知如何将传统服务改造成微服务。

本文将告诉你，如何将一个传统应用转化成微服务，从而来享受servicemesh的各种功能，如“灰度发布”、“服务治理”、“流量拓扑”、Tracing等功能。

介绍

KubeSphere微服务使用application CRD，将相关联的资源抽象成了一个具体的应用，使用istio application功能，实现微服务流量治理、灰度发布、Tracing等功能。屏蔽了istio复杂的destinationrule及virtualservice概念，能根据流量治理设置及灰度发布策略自动生成这些资源。

使用KubeSphere微服务，需满足以下条件：

1. deployment有app version 这两个label；service有app label；且deploy与service的app label一致，等于serviceName（istio 需要）

2. 在一个应用内，所有资源需要有这两个标签 app.kubernetes.io/name=<applicationName>, app.kubernetes.io/version=<Version>（application需要）

3. deployment name为 service name后面加v1；如serevice 为 nginx, deployment 为 nginx-v1 （3.1修复后无需强制规定）

4. deployment template中有相应annotation （istio sidecar自动注入需要）

  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"

5. service/deployment有相应annotation （KubeSphere crd controller 会自动将service同步为virtualservice/destinationrules，crd controller需要）

# Service
kind: Service
metadata:
  annotations:
    servicemesh.kubesphere.io/enabled: "true"
    
# Deployment
kind: Deployment
metadata:
  annotations:
    servicemesh.kubesphere.io/enabled: "true"

示例说明

下面将首先创建 wordpress + mysql两个单独的应用，功能正常后，将它们转化成KubeSphere 微服务，并注入sidecar实现流量治理等功能。

仅仅一个service使用sidecar功能是没有意义的，最少要有两个service才能看到流量拓扑；因此这里使用两个最简单的服务来演示功能。

打开mysql dockerhub页面，可以看到设置 MYSQL_ROOT_PASSWORD 变量，可以设置默认密码。

打开wordpress dockerhub页面，可以看到可以数据库设置的三个变量 WORDPRESS_DB_PASSWORD WORDPRESS_DB_USER WORDPRESS_DB_HOST，通过设置这三个变量，让wordpress连接到mysql应用

创建传统的应用

首先创建workspace、namespace ， 且namespace开启网关及流量治理功能

创建mysql

设置初始密码

同理，创建一个stateless的wordpress服务

待pod全部正常后，根据service NodePort端口，直接访问页面，可以看到应用正常

查看pod，未启用sidecare，每个pod只有一个容器

由于没有使用微服务功能，无法看到流量的具体走向。下面将它转化成servicemesh服务网格形式。

部署application应用

1. apply 下面的yaml，部署出一个application

# wordpress.yaml
apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  annotations:
    kubesphere.io/creator: admin
    servicemesh.kubesphere.io/enabled: "true"
  labels:
    app.kubernetes.io/name: wordpress-app
    app.kubernetes.io/version: v1
  name: wordpress-app  # 注意应用的name要跟label定义的一样：app.kubernetes.io/name
spec:
  addOwnerRef: true
  componentKinds:
  - group: ""
    kind: Service
  - group: apps
    kind: Deployment
  - group: apps
    kind: StatefulSet
  - group: extensions
    kind: Ingress
  - group: servicemesh.kubesphere.io
    kind: Strategy
  - group: servicemesh.kubesphere.io
    kind: ServicePolicy
  selector:
    matchLabels:
      # 相关资源需要打上这两个label，表示归属关系
      app.kubernetes.io/name: wordpress-app
      app.kubernetes.io/version: v1

可以看到现在这个应用状态是 0/0，表示没有关联任何应用

如果看不到应用状态，且无法使用 kubectl get app 命令，说明你环境的application的CRD较老，更新方法：

kubectl apply -f https://raw.githubusercontent.com/kubesphere/ks-installer/master/roles/common/files/ks-crds/app.k8s.io_applications.yaml

2. 给相关应用打上application label，声明服务归属于该应用

kubectl -n sample label deploy/wordpress-v1 app.kubernetes.io/name=wordpress-app app.kubernetes.io/version=v1
kubectl -n sample label svc/wordpress app.kubernetes.io/name=wordpress-app app.kubernetes.io/version=v1

kubectl -n sample label sts/mysql-v1 app.kubernetes.io/name=wordpress-app app.kubernetes.io/version=v1
kubectl -n sample label svc/wordpress app.kubernetes.io/name=wordpress-app app.kubernetes.io/version=v1

此时检查app，可以发现已经可以看到应用中的关联服务数量已经不为0了

3. deployment/service打上相应的annotation

kubectl -n sample annotate svc/wordpress servicemesh.kubesphere.io/enabled="true"
kubectl -n sample annotate deploy/wordpress-v1 servicemesh.kubesphere.io/enabled="true"
kubectl -n sample annotate svc/mysql servicemesh.kubesphere.io/enabled="true"
kubectl -n sample annotate sts/mysql-v1 servicemesh.kubesphere.io/enabled="true"

4. deploy/sts templates中增加相应annotation，启用sidecar

 kubectl -n sample edit deploy/wordpress-v1
...
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"  # 添加该行

kubectl -n sample edit sts/mysql-v1
...
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true" # 添加该行

注意：只需要给template中加annotations就可以注入sidecar，无需给namespace加istio.injection=enable的label

检查已经注入sidecar

5. istio相关label、命名规则符合要求，如果是通过KubeSphere创建的服务，这两项默认支持，不用修改

即app version相关的label，如果是使用KubeSphere页面创建的服务，会默认添加上这两个label

检查

至此，改造已经完成，检查页面

我们将wordpress 服务暴露出来

页面访问服务，可以看到应用正常

检查流量，发现正常，流量可以视化已经可以看到数据

同理，灰度发步/Tracing功能也正常。

Tracing功能需要启用Ingress才能看到效果。

总结：

微服务改造按照上述步骤修改，即可顺利完成应用的改造，但是步骤仍然较为繁锁，KubeSphere会继续优化功能，降低使用门槛。