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

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

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

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

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.

Reference:https://www.alibabacloud.com/blog/enabling-blue-green-release-with-alibaba-cloud-container-service-for-kubernetes_594113?spm=a2c41.12228256.0.0