Manage application lifecycle and traffic governance using native Kubernetes workloads-Enterprise Distributed Application Service(EDAS)-阿里云帮助中心

The EDAS application management engine has been upgraded to include a new application model. This model supports native Kubernetes workloads and lets you manage the application lifecycle using Custom Resource (CR) policy configurations. By default, EDAS applications converted from native Kubernetes workloads have built-in observability and service governance capabilities. You can use the EDAS console to quickly visualize application monitoring. This topic uses a deployment workload as an example.

Convert a Kubernetes deployment to an EDAS application

Prerequisites: Make sure that the cluster is imported to EDAS. For more information, see Import a Kubernetes cluster in the EDAS console and Import a Kubernetes cluster using Helm.

Use the kubectl command to install a native Kubernetes deployment.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: native-deploy-a
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test

kubectl apply -f native-deploy.yaml

Edit the deployment and add a label to flag this deployment for conversion to an EDAS application.

Note

The application name must be the same as the deployment name.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  name: native-deploy-a
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test

kubectl apply -f native-deploy.yaml

Confirm that EDAS environment variables are injected into the new pod. By default, the application is registered with the registry and configuration center that is hosted by EDAS.
```
kubectl get pod native-deploy-b-7795bdfb5f-nvfbz -oyaml | grep EDAS
```
Log on to the EDAS console to view the deployment. The deployment is converted to an EDAS application.
View the service list to see the registered microservices.
View the application monitoring details to monitor Java Virtual Machine (JVM) performance, analyze SQL statements, and analyze call chains.

Perform a manually controlled phased release using a native Kubernetes workload

Prerequisites: Make sure that the cluster where the application is deployed is imported to EDAS. For more information, see Import a Kubernetes cluster in the EDAS console and Import a Kubernetes cluster using Helm.

Use the kubectl command to create a CR for the application release configuration. This configuration specifies that the application is released in two phases.

Note
Ensure that the number of batches is less than the number of replicas.
```
apiVersion: cloudapp.alibabacloud.com/v1
kind: CanaryReleasePolicy
metadata:
  name: test-canary-release-policy
spec:
  config:
    batch: 2
```

Use the kubectl command to install a native Kubernetes deployment and configure a label to convert it to an EDAS application.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  name: native-deploy-a
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test

Configure an annotation for the deployment to associate the release configuration from Step 1, and then modify the template to trigger the application release.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  annotations:
    cloudapp.alibabacloud.com/canary-release-policy: test-canary-release-policy
  name: native-deploy-a
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test

View the application release status. Only one pod of the new version is released, and one pod of the old version remains.
Remove the cloudapp.alibabacloud.com/release-paused annotation from the deployment to trigger the release of the next phase of instances.

Perform a content-based canary release using a native Kubernetes workload

Note

Currently, canary release is supported only for Java microservice applications. The canary release phase defaults to the first phase.

Use the kubectl command to create a canary release policy configuration for the application. The configuration specifies the number of canary instances, the number of release phases, and the canary traffic rules.
```
apiVersion: cloudapp.alibabacloud.com/v1
kind: CanaryReleasePolicy
metadata:
  name: test-canary-content-policy
spec:
  config:
    batch: 2
    canaryReplicas: 1
    canaryConfig:
      http:
        - matches:
            - headers:
                - name: env
                  type: Equal
                  values:
                    - grey
              matchPolicy: OR
              path:
                type: Equal
                values:
                  - /b
```
In this example configuration, the release is divided into two phases. One instance is released in the canary phase. The remaining instance is released in the next phase. In addition, a canary traffic rule is configured: if the URI of the request is /b and the value of env in the request header is grey, traffic from consumer instances is forwarded to the canary instance.

In this deployment, test applications A, B, and C have invocation relationships. Application B is the object of the canary release, and its number of replicas is 2.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  name: native-deploy-a
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      labels:
        app: native-deploy-b
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-c
  name: native-deploy-c
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-c
  template:
    metadata:
      labels:
        app: native-deploy-c
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-c:headers
      imagePullSecrets:
        - name: test

Connect to an instance of application A to verify the service invocation relationship between applications when no rule is associated.
```
for i in {1..10000}; do curl http://127.0.0.1:8080/a?tag=zone ; echo ""; done
```
The result shows that requests from application A access the instances of application B (XX.XX.0.24 and XX.XX.0.62) in a polling manner.

Configure an annotation for application B to associate the release policy. Then, update the template of application B to trigger the application release. In this example, a new label is added.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    cloudapp.alibabacloud.com/canary-release-policy: test-canary-content-policy
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      labels:
        app: native-deploy-b
        newlabel: newlabelvalue
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test

View the update status of application B. Only the canary instance that is configured in Step 1 is released in the canary phase. The other instance remains on the stable, old version.
```
kubectl get pod -l app=native-deploy-b
```
New version pod IP (canary): XX.XX.0.13. Old version pod IP: XX.XX.0.54.

Verify the traffic during the canary release. Log on to an instance of application A and call the API to verify that traffic is forwarded based on the policy.

# Baseline traffic
for i in {1..10}; do curl http://127.0.0.1:8080/a?tag=zone ; echo ""; done

# Canary traffic
for i in {1..10}; do curl -H "env: grey" http://127.0.0.1:8080/a?tag=zone ; echo ""; done

Remove the release suspension annotation cloudapp.alibabacloud.com/release-paused from the deployment to trigger the update for the next phase of instances. Then, verify the traffic.

Perform a percentage-based canary release using a native Kubernetes workload

This procedure is the same as the procedure for a content-based canary release using a native Kubernetes workload. The only difference is the release template configuration in Step 1. The percentage must be set to a string with a value less than 100. In this example, the percentage is set to 10, which means that 10% of the traffic is routed to the canary instance.
```
apiVersion: cloudapp.alibabacloud.com/v1
kind: CanaryReleasePolicy
metadata:
  name: test-canary-content-policy
spec:
  config:
    batch: 2
    canaryReplicas: 1
    canaryConfig:
      percentage: "10"
```

Update the associated annotation and template in the deployment of application B.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    cloudapp.alibabacloud.com/namespace: cn-hangzhou
    cloudapp.alibabacloud.com/canary-release-policy: test-canary-percent-policy
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      annotations:
        testanno: testannovalue
      labels:
        app: native-deploy-b
        newlabel: newlabelvalue
        newlabel.percent: newlabelvalue
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test

View the current instance update status.
New version pod IP (canary): XX.XX.0.9. Old version pod IP: XX.XX.0.87.
Log on to an instance of application A to check the traffic forwarding percentage. Call the API multiple times to sample and verify the percentage. The following figure shows an example. The result shows that the traffic forwarding percentage complies with the canary rule.
Remove the release suspension annotation cloudapp.alibabacloud.com/release-paused from the deployment of application B. Verify that the application instance status changes and the traffic is distributed as expected.

Configure a zone affinity policy using a native Kubernetes workload

Create an application runtime configuration policy to enable zone affinity for the application runtime. Set the threshold to 0.2. This means that the zone affinity policy takes effect if more than 20% of the provider and consumer instances are in the same zone.
```
apiVersion: cloudapp.alibabacloud.com/v1
kind: CloudAppRuntimePolicy
metadata:
  name: demo-cloudapp-runtime-policy
spec:
  localityLoadBalancer:
    enable: true
    threshold: "0.2"
```

Deploy applications A, B, and C. These applications have microservice invocation relationships. Set the number of replicas for application B to 2. You can configure a pod anti-affinity policy to distribute the pods to nodes in different zones.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  name: native-deploy-a
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      labels:
        app: native-deploy-b
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-c
  name: native-deploy-c
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-c
  template:
    metadata:
      labels:
        app: native-deploy-c
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-c:headers
      imagePullSecrets:
        - name: test

You can verify the relationship between the request invocation chain and zones if application B is not associated with an application configuration policy.
```
for i in {1..20}; do curl http://127.0.0.1:8080/a?tag=zone ; sleep 0.3; echo ""; done
```
The verification results show that when no runtime policy is associated, the application A instance in the cn-hangzhou-j zone accesses the application B instances in the cn-hangzhou-i and cn-hangzhou-j zones using polling.

Associate application B with the application runtime policy using an annotation. This configuration takes effect dynamically.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    cloudapp.alibabacloud.com/namespace: cn-hangzhou
    cloudapp.alibabacloud.com/runtime-policy: demo-cloudapp-runtime-policy
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      annotations:
        testanno: testannovalue
      labels:
        app: native-deploy-b
        newlabel: newlabelvalue
        newlabel.percent: newlabelvalue2
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test

Verify the zone distribution of the service invocation chain between application A and application B. Application A (cn-hangzhou-j) preferentially accesses the instance of application B in the same zone (cn-hangzhou-j).

Remove the annotation that you added in Step 4 from the deployment of application B.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    cloudapp.alibabacloud.com/namespace: cn-hangzhou
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      annotations:
        testanno: testannovalue
      labels:
        app: native-deploy-b
        newlabel: newlabelvalue
        newlabel.percent: newlabelvalue2
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test

Verify the zone distribution of the service invocation chain. After the policy is disassociated, application A in the cn-hangzhou-j zone resumes accessing instances in the cn-hangzhou-i and cn-hangzhou-j zones in a polling manner.

Configure a graceful start policy using a native Kubernetes workload

Create an application update policy to enable the service warm-up configuration for application updates. In this example, service warm-up is enabled, the ramp-up period is set to 180 seconds, and the traffic receiving ratio curvature is set to 2.

apiVersion: cloudapp.alibabacloud.com/v1
kind: CloudAppUpdatePolicy
metadata:
  name: demo-cloudapp-update-policy
spec:
  online:
    enable: true
    readinessAfterRegister: true
    readinessAfterWarmup: true
    registerDelaySecs: 0
    warmupCurvature: 2
    warmupDurationSecs: 180

Create applications A, B, and C. These applications have microservice invocation relationships.

Note

The number of replicas for each application is set to 1. The service warm-up effect is demonstrated by scaling out application B to 2 replicas and checking the traffic received by the new pod.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-a
  name: native-deploy-a
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-a
  template:
    metadata:
      labels:
        app: native-deploy-a
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-a:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      labels:
        app: native-deploy-b
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-c
  name: native-deploy-c
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: native-deploy-c
  template:
    metadata:
      labels:
        app: native-deploy-c
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-c:headers
      imagePullSecrets:
        - name: test

Log on to an instance of application A and continuously send traffic. Then, log on to the EDAS console to monitor the traffic that is received by application B. Currently, application B has one instance and receives traffic at a stable rate.

Associate application B with the application update policy that supports graceful start and service warm-up. Then, change the number of replicas for application B to 2.

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    cloudapp.alibabacloud.com/namespace: cn-hangzhou
    cloudapp.alibabacloud.com/update-policy: demo-cloudapp-update-policy
  labels:
    cloudapp.alibabacloud.com/app: native-deploy-b
  name: native-deploy-b
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: native-deploy-b
  template:
    metadata:
      labels:
        app: native-deploy-b
        test: "aaa"
    spec:
      containers:
        - name: group-1
          image: registry.cn-hangzhou.aliyuncs.com/edas_unified_test/sc-mq-b:headers
      imagePullSecrets:
        - name: test

Log on to the EDAS console, go to the details page of application B, and choose Monitoring > Instance Monitoring. You can view the change in the number of requests that are received by the new scaled-out pod instance.
During the ramp-up period, the new scaled-out instance receives a small percentage of traffic. After the ramp-up period ends, the new instance shares traffic equally with the old instance.