In the gray Bookinfo micro-publishing service example in, KubeSphere service based Istio example of Bookinfo micro applications to achieve a gray-scale release. A user that their project is not yet on Istio, how to achieve gray publish?
The Ingress-Nginx (0.21.0 version) , the introduction of a new Canary function, can be used to configure the gateway to the plurality of inlet backend services, you may also be used to specify the annotation to control the flow distribution between the plurality of back-end services . KubeSphere in the 2.0.2 version , the upgrade project Gateway (Ingress Controller) version to 0.24.1, supports Ingress-Nginx release gray.
Previous articles have been published on the gray a few application scenarios are described in detail, this article will introduce and demonstrate a direct realization of gray publish based KubeSphere use application routing (Ingress) and Project Gateway (Ingress Controller).
Description: yaml used herein are exemplary and the source code has been uploaded to GitHub , easy reference may be local to clone.
Ingress-Nginx Annotation Introduction
KubeSphere based on Nginx Ingress Controller implements a gateway project, as a project outside of the inlet flow rate of each project and reverse proxy services. Ingress-Nginx supports the Ingress Annotations configured to publish and Grayscale tested under different scenarios, meet the release canary, cyan deployment and A / B testing business scenarios.
Nginx Annotations supports the following four kinds Canary rules:
nginx.ingress.kubernetes.io/canary-by-header: Flow Request Header based segmentation for gradation publish and A / B test. When the Request Header is setalways, the request will be sent up to the Canary version; when the Request Header is setnever, the request will not be sent to the Canary inlet; for any other value Header, Header ignored, and the priority of the request by other rules canary priority comparison.nginx.ingress.kubernetes.io/canary-by-header-value: The value to match Request Header for routing requests to notify Ingress Ingress Canary specified service. When the Request Header is set to this value, it will be routed to the Canary inlet. This rule allows the user to customize the values Request Header, one must Annotation (i.e.: canary-by-header) used together.nginx.ingress.kubernetes.io/canary-weight: Weight cut points based on traffic service weights, suitable for deployment cyan, weight range 0 - 100 percentage Canary Ingress route the request to the specified service. A weight of 0 means that the canary rule does not send any request to the Canary entry services. Weight is 100 means that all requests are sent to the Canary inlet.nginx.ingress.kubernetes.io/canary-by-cookie: Flow Cookie based segmentation, and applies the gradation release A / B test. Ingress is used to route requests to notify cookie Canary Ingress specified services. When the cookie value is setalways, it will be routed to the inlet Canary; when the cookie value is setnever, the request will not be sent to the Canary inlet; for any other value, and ignores the cookie request priority rules with other canaries level comparison.Note: The following rules Canary sort of priority:
canary-by-header - > canary-by-cookie - > canary-weight
The more than four annotation rules can generally be divided into the following two categories:
- Canary rules based on the weight
- Canary rules based on a user request
Step 1: Create Project and Production versions of the application
1.1. Creating a business space (workspace) in KubeSphere and project (namespace), refer to the multi-tenant Management Quick Start . Below we have created a sample project.
1.2. In order to quickly create applications, create workloads and services in the project when by 编辑 yamlthe way, or use lower-right corner of KubeSphere toolbox open web kubectland create a Production version of the application using the following command and yaml files and exposed to the cluster outside access. Production versions of the following to create deploymentand service.
$ kubectl appy -f production.yaml -n ingress-demo
deployment.extensions/production created
service/production createdYaml file which is used as follows:
production.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: production
spec:
replicas: 1
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
containers:
- name: production
image: mirrorgooglecontainers/echoserver:1.10
ports:
- containerPort: 8080
env:
- name: NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
---
apiVersion: v1
kind: Service
metadata:
name: production
labels:
app: production
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
name: http
selector:
app: production1.3 Create Production versions of the application routes (Ingress).
$ kubectl appy -f production.ingress -n ingress-demo
ingress.extensions/production createdYaml file which is used as follows:
production.ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: production
annotations:
kubernetes.io/ingress.class: nginx
spec:
rules:
- host: kubesphere.io
http:
paths:
- backend:
serviceName: production
servicePort: 80Step two: Access Production versions of the application
2.1. At this time, the enterprise space KubeSphere UI demo-workspace, you can see all of the resources of the ingress-demo project.
Deployment
Service
Ingress
2.2 Application Access Production versions of the need to ensure that the current project has opened the gateway to the external network access to open gateways, the type is NodePort.
2.3. Production versions of the application are as follows access.
$ curl kubesphere.io:30205
Hostname: production-6b4bb8d58d-7r889
Pod Information:
node name: ks-allinone
pod name: production-6b4bb8d58d-7r889
pod namespace: ingress-demo
pod IP: 10.233.87.165
Server values:
server_version=nginx: 1.12.2 - lua: 10010
Request Information:
client_address=10.233.87.225
method=GET
real path=/
query=
request_version=1.1
request_scheme=http
request_uri=http://kubesphere.io:8080/
Request Headers:
accept=*/*
host=kubesphere.io:30205
user-agent=curl/7.29.0
apiVersion: extensions/v1beta1
x-forwarded-for=192.168.0.88
x-forwarded-host=kubesphere.io:30205
x-forwarded-port=80
x-forwarded-proto=http
x-original-uri=/
x-real-ip=192.168.0.88
x-request-id=9596df96e994ea05bece2ebbe689a2cc
x-scheme=http
Request Body:
-no body in request-Step 3: Create Canary version
Production versions of the above reference production.yamldocument, and then create a Canary version of the application, including a Canary version deploymentand service(for the convenience of a quick demonstration, just to production.yamlthe deployment and service keywords in the productiondirect replacement for the canaryactual scene may be involved in the business code change).
Step four: Ingress-Nginx Annotation rules
Based on the weight (Weight)
Typical application scenarios based on the weight flow rate is sliced 蓝绿部署, it can be reset to 0 by weight or 100 to achieve. For example, the version is set to the main part of Green, and Blue version of an inlet configured to Canary. Initially, the weight is set to 0, it will not proxy traffic to Blue version. Once the new version of the test and verification are successful, you can version of the Blue weight is set to 100, that is, all traffic from turning Blue Green version.
4.1. The following canary.ingressis yaml then create a file weights Canary version of the application routes (Ingress) based.
Note: To turn gray-release mechanism, you first need to set
nginx.ingress.kubernetes.io/canary: "true"Canary, the Canary version of Ingress example enables the use of a weight-based traffic segmentation annotation rules will be allocated 30% of the traffic request to the Canary version.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: canary
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "30"
spec:
rules:
- host: kubesphere.io
http:
paths:
- backend:
serviceName: canary
servicePort: 80
4.2. The domain access applications.
Description: The application of Canary version for traffic segmentation based on weight (30%), the Canary version access to the probability of close to 30%, the proportion of traffic might be floating a small range.
Based on Request Header
4.3. That is based on a typical application scenarios Request Header traffic segmentation 灰度发布或 A/B 测试场景. Reference to the following theme, the Canary KubeSphere to a new version of the Ingress Annotation nginx.ingress.kubernetes.io/canary-by-header: canary(Annotation of this value may be any value), so that the current to achieve Ingress traffic segmentation based Request Header.
Description: Canary rule to prioritize
canary-by-header - > canary-by-cookie - > canary-weightthe following sort, so the following rules will be ignored canary-weight of the original.
4.4. Different Header added value in the request, access to the domain name application again.
Description:
Two examples, as mentioned at the beginning when the Request Header is set
neveroralwayswhen the request不会or一直be sent to the Canary version;For any other value Header, Header ignored, and the priority of the requests by priority compared with other Canary rules (as the second request sent
基于 30% 权重as a first priority).
4.5. At this time may be added on a basis of an Annotation (i.e. canary-by-header) on nginx.ingress.kubernetes.io/canary-by-header-value: user-value. Ingress for notifying Canary Ingress route requests to the services specified.
4.6. Follows accessing application domain, when the Request Header meet this value, all requests are routed to Canary version (This rule allows a user defined value of the Request Header).
Cookie Based
4.7. Similar annotation usage rules based Request Header. For example A/B 测试场景, the need to allow local access Canary version Beijing users. Then when the cookie annotation set nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing", then the background can be requested by the user logged on to check if the user access to the source from Beijing to set a cookie users_from_Beijingvalue always, so that you can ensure that users access only Beijing Canary version.
to sum up
Gray release can ensure the stability of the whole system, you can test the new version in the initial gray and found the problem and adjusted to ensure that the degree of influence. Through presentations and a number of examples illustrate the application using the user KubeSphere Based Routing (Ingress) and Project Gateway (Ingress Controller) grayscale release, and describes four Annotation Ingress-Nginx detailed, yet can also use Istio aid Ingress-Nginx easily and gray were released canary.
reference
- NGINX Ingress Controller - Annotations
- canary deployment with ingress-nginx
- ON Kubernetes the without the Deployments Service Canary Mesh
KubeSphere (https://github.com/kubesphere/kubesphere) is an open source application-centric container management platform to support deployed on any infrastructure, and provides easy to use UI greatly reduce the daily development, testing, operation and maintenance complexity, aimed at resolving Kubernetes inherent in the storage, networking, security and ease of use pain points to help businesses easily deal with the agile automated monitoring operation and maintenance, end-to-application delivery, micro-management services, multi-tenant management, multi-cluster management, network management, mirroring warehouse, AI platform edge computing and business scenarios.