Step 2: Release the latest version of a service

In the left-side navigation pane, click Clusters.

On the Clusters page, click the name of a cluster or click Details in the Actions column. The details page of the cluster appears.

In the left-side navigation pane, click Workload.

Select the Deployments tab.

Click Create from Template in the upper-right corner of the Deployments tab.

Select a sample template or use an existing template, and click Create.

Deploy an Nginx application of the latest version that contains the deployment, the service, and an Ingress. The following orchestration template contains the deployment and the service:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: new-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: new-nginx
  template:
    metadata:
      labels:
        run: new-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/xianlu/new-nginx
        imagePullPolicy: Always
        name: new-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort

The following Ingress orchestration templates apply to different annotation settings:

Note If you do not set service-match or service-weight in the annotations field of an Ingress template, the Ingress controller forwards client requests evenly to the latest and earlier versions of the service in a random manner.

Ingress template used to specify that only the client requests that meet the requirement of the regular expression foo=bar can be routed to the latest version of the service

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      nginx.ingress.kubernetes.io/service-match: |# Only requests whose request headers meet the requirement of the regular expression foo=bar can be routed to the latest version of the service new-nginx.
          new-nginx: header("foo", /^bar$/)
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Earlier version of the service
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Latest version of the service
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Ingress template used to specify the proportion of requests that can be routed to the latest version of the service

Note In this example, the latest version of the service and the earlier version of the service are weighted at 50% each.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
      nginx.ingress.kubernetes.io/service-weight: |# Allows 50% of the traffic to be routed to the latest version of the service new-nginx.
          new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Earlier version of the service
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Latest version of the service
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

Ingress template used to specify that only 50% of the client requests that meet the requirement of foo=bar can be routed to the latest version of the service

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gray-release
  annotations:
    nginx.ingress.kubernetes.io/service-match: |# Only requests whose request headers meet the requirement of the regular expression foo=bar can be routed to the latest version of the service new-nginx.
        new-nginx: header("foo", /^bar$/)
    nginx.ingress.kubernetes.io/service-weight: |# Only 50% of the requests whose request headers meet the requirement of the regular expression foo=bar can be routed to the latest version of the service new-nginx.
        new-nginx: 50, old-nginx: 50
spec:
  rules:
  - host: www.example.com
    http:
      paths:
      # Earlier version of the service
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80
      # Latest version of the service
      - path: /
        backend:
          serviceName: new-nginx
          servicePort: 80

In the left-side navigation pane, click Ingresses.

You can see that the virtual host name points to old-nginx.

Log on to a master node of the cluster. Then, use curl to run the following command to send requests to the ingress:

Only the client requests that meet the requirement of the regular expression foo=bar can be routed to the latest version of the service.
```
# curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP> 
```
The specified proportion of requests can be routed to the latest version of the service.
```
# curl -H "Host: www.example.com" http://<EXTERNAL_IP> 
```
Only 50% of the client requests that meet the requirement of foo=bar can be routed to the latest version of the service.
```
# curl -H "Host: www.example.com" -H "foo: bar" http://<EXTERNAL_IP> 
```

Prerequisites

Procedure