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.
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
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.
There are primarily two additions:
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.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. ~ 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.
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.
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.
Translating 100 Billion Words Every Day for E-Commerce with Alibaba Machine Translation
2,599 posts | 764 followers
FollowXi Ning Wang - March 1, 2019
DavidZhang - December 30, 2020
Alibaba Cloud Storage - June 4, 2019
Alibaba Cloud Native - November 3, 2022
Alibaba Cloud Native Community - April 9, 2024
Alibaba Cloud Native Community - September 20, 2022
2,599 posts | 764 followers
FollowLearn More
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn MoreElastic and secure virtual cloud servers to cater all your cloud hosting needs.
Learn MoreMore Posts by Alibaba Clouder