×
Community Blog Enabling Blue-Green Release with Alibaba Cloud Container Service for Kubernetes

Enabling Blue-Green Release with Alibaba Cloud Container Service for Kubernetes

In this article, we will explore how development teams can use Alibaba Cloud's container service and simplify traffic splitting in phased releases with blue-green deployment.

11.11 The Biggest Deals of the Year. 40% OFF on selected cloud servers with a free 100 GB data transfer! Click here to learn more.

When releasing an application, it is often necessary to first release a new version and then test its availability with a small amount of traffic. However, Kubernetes's ingress resource does not implement traffic control and splitting. As a result, only one service is available in the directory with the same domain name. This is undesirable for a phased release. In this article, we will introduce Alibaba Cloud's Container Service blue-green release function, which enables easy traffic splitting.

Prerequisites

Since we need blue-green releases, there should already be an old service that is serving normally. Here we will take Nginx as an example. Assume that there is already an nginx deployment exposing ports through NodePort and an ingress is providing services. The template we will use is as follows:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: old-nginx
  name: old-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      run: old-nginx
  template:
    metadata:
      labels:
        run: old-nginx
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/xianlu/old-nginx
        imagePullPolicy: Always
        name: old-nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: old-nginx
  name: old-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: old-nginx
  sessionAffinity: None
  type: NodePort
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo
spec:
  backend:
    serviceName: default-http-backend
    servicePort: 80
  rules:
  - host: mini-echo.io
    http:
      paths:
      - path: /
        backend:
          serviceName: old-nginx
          servicePort: 80

We can see the created ingress address

[root@iZwz91e2au5xvyw5jdpqp7Z manifests]# kubectl get ing
NAME      HOSTS          ADDRESS        PORTS     AGE
echo      mini-echo.io   47.106.45.47   80        3m

When accessing via curl on the host, we can see the following results:

  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
old

Performing Blue-Green Release

Creating New Deployment and Service

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    run: new-nginx
  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:
  labels:
    run: new-nginx
  name: new-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: new-nginx
  sessionAffinity: None
  type: NodePort

As you can see, the only change is that all old-nginxes become new-nginxes.

Modifying Ingress

1

There are primarily two additions:

  1. annotations is added, and the tag ingress.aliyun.weight/new-nginx: "50" indicates that the content after the slash (/) is the name of the new service, i.e., new service name. The following "50" represents the percentage (%), and 50 indicates that the new service occupies 50% of the traffic. The complete meaning of this tag is that 50% the traffic is switched into the pod of the new service.
  2. The second addition is to specify the corresponding new serviceName. This is in parallel with the above old service, that is to say, two different services exist in the same path and these services correspond to the new and old applications.

Result

  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
old
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
old
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
old
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new

We can see that we have executed six requests and got three responses in return from the new service, while three were from the old service. This indicates that the weight setting has taken effect.

Switching Traffic to the New Service Completely

2

You can set the percentage of the new service to 100 and try again.

  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new

As we can see, all traffic has switched to the new service.

Finalizing the Blue-Green Release

3

We just need to delete the annotation of the weight setting, and then delete the corresponding serviceName below, thus restoring the original ingress, and changing the old service into a new service. Let's look at the effect again:

  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new
  ~ curl -H "Host: mini-echo.io" http://47.106.45.47
new

Now we can see that the new service is already online. This means that the lifecycle of the entire blue-green release is finished.

Read similar articles and learn more about Alibaba Cloud's products and solutions at www.alibabacloud.com/blog.

0 0 0
Share on

Alibaba Clouder

2,605 posts | 747 followers

You may also like

Comments