Categories
Uncategorized

Contour study notes (b): Cascading achieve blue-green and canary release deployment

The article introduces the principle Contour distributed architecture, the way a brief introduction of the use of under IngressRoute. This article will explore more advanced usage IngressRoute, which cascade function is the key.

1. IngressRoute big entry

The article created a sample application in the examples / example-workload directory, let’s look at it IngressRoute configuration:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
  labels:
    app: kuard
  name: kuard
  namespace: default
spec: 
  virtualhost:
    fqdn: kuard.local
  routes: 
    - match: /
      services: 
        - name: kuard
          port: 80

    virtualhost: This field is root IngressRoute, representing the top-entry point for this domain.

    fqdn: This field specifies the full domain name, can be specified in the header in the HTTP request Host: field to access the service.

This is the easiest method is to use, looks nothing special, let’s look at some modifications:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
  labels:
    app: kuard
  name: kuard
  namespace: default
spec: 
  virtualhost:
    fqdn: kuard.local
  routes: 
    - match: /test
      services: 
        - name: kuard
          port: 80

The match: / changed to match: / test, then re-apply the new rules. Then if you visit the url kuard.local / test is unreasonable, because the service itself does not kuard / test this path, we can force the path rewritten as /:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
  labels:
    app: kuard
  name: kuard
  namespace: default
spec: 
  virtualhost:
    fqdn: kuard.local
  routes: 
    - match: /test
      prefixRewrite: "/"
      services: 
        - name: kuard
          port: 80

After re-apply, again to access url kuard.local / test to pass.

Here you can and compare standards of ingress objects, advantages IngressRoute is that it can be set individually rewrite rules for each route, and Nginx Ingress Controller can only be set globally rewrite the rules, because it uses annotations. Although it can be achieved by other means, but relatively speaking, would be more trouble.

2. cascade Features

Let us look at IngressRoute cascade function, this is a very unique feature, you can configure the upper IngressRoute be inherited by cascading multiple routing rules lower. For example, we can url path / routing rule cascade to other IngressRoute in other IngressRoute can come from a different namespace.

For example, we can create such a IngressRoute:

$ cat > delegate-from-main.yaml <
$ kubectl apply -f delegate-from-main.yaml

$ kubectl get ingressroute delegate-from-main -o jsonpath='{.status.currentStatus}'
orphaned

The state IngressRoute is orphaned, because it does not contain a valid fqdn. Next you need to create a root IngressRoute and its cascade:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata: 
  labels:
    app: kuard
  name: kuard
  namespace: default
spec: 
  virtualhost:
    fqdn: kuard.local
  routes: 
    - match: /
      delegate:
        name: delegate-from-main
        namespace: default

Then if we check the status IngressRoute delegate-from-main, you will find that it becomes a valid state from orphaned state, kuard.local can smoothly access.

After know how the cascade function, here's a look at its application scenarios.

    Scene One: Cascading can do cyan and gray release deployment, only minor modifications in the upper IngressRoute, switch to another lower IngressRoute, processing rules can be switched traffic.

    Scene 2: Administrators can use the cascade function will release part of the ingress of rights to other namespace, the namespace in which the user can freely update IngressRoute associated with the root IngressRoute cascade. For example, if an administrator wants to prevent other users from illegal configure the domain name or path, you can configure the permissions section into root IngressRoute, the other namespace in the lower IngressRoute can only configure an individual path related information.

Next focuses on a scene.

3. The deployment of blue-green

Simply put blue-green deployment in a production environment is to have two systems: a system that is providing the service, labeled "green"; another set of system is ready to release, labeled "blue." Both systems are fully functional, and the system is running, just different versions of the system and external services situation.

Initially, no system, no blue-green of the points.

Then, the first system developed directly on the line, and this is only one system, no blue-green points.

Later, the development of a new version, replace with a new version of the online version of the old, out of the system on-line, set up a new system with a new version of the code. At this time, a total of two systems in operation, is to provide services outside the old system, green system, the new system is deployed blue system.

Blue system does not provide services for Zuosha?

Used for testing before release, any problems found during the test can be modified directly on the blue system, the system does not interfere with the user is using. (Note that there is no coupling of the two systems when they could not interfere with a 100% guarantee)

Blue system after repeated testing, modification, verification, after determining that the line to achieve the standard, the user directly switches to a blue system:

Some time after the switch is still blue-green two systems co-exist, but the user has access to the system is blue. Blue observation systems within this period of time (the new system) work state, if a problem occurs, switch directly back to the green system.

When the system is certain to provide services outside the blue work properly and not to provide services green system is no longer needed, the system became blue external services system, to become the new green system. The original green system can be destroyed, it will release resources for the next deployment of a blue system.

Can be easily achieved by cascading blue-green function IngressRoute deployment strategy, first create a top of the root IngressRoute (assuming that called root-blog), then the routing policy domain yangcs.net/blogs cascade to lower IngressRoute ( named blog). We will also deploy "blue" version and a "green" version of the application, this time only "green" version of the received traffic.

---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: root-blog
  namespace: root-ingressroute
spec:
  virtualhost:
    fqdn: yangcs.net
    tls:
      secretName: yangcs-net
  routes:
    - match: /blog
      delegate:
        name: blog
        namespace: marketing
---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: blog
  namespace: marketing
spec:
  routes:
    - match: /blog
      services:
        - name: green
          port: 80

---
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: blog2
  namespace: marketing
spec:
  routes:
    - match: /blog
      services:
        - name: blue
          port: 80

After the blue version of the verification test, you can switch the user to use the blue:

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: root-blog
  namespace: root-ingressroute
spec:
  virtualhost:
    fqdn: yangcs.net
    tls:
      secretName: yangcs-net
  routes:
    - match: /blog
      delegate:
        name: blog2
        namespace: marketing

4. canary release

Canary release (Canary) is also a release strategy, and often say gray domestic release is the same type of strategy. And it is a bit like a blue-green, but it is more risk-averse. You can carry on stage, rather than a one-time switch from blue to green version version.

The use of canary deployment, you can deploy the new application code in the infrastructure of small and medium range production environment. Once the application is signed release, only a few users are routed to it, it can reduce the maximum impact.

If no error occurs, the remaining V1 to V2 version upgrade all versions. If an error occurs, the direct fall back to the old version, failed to publish. The following figure illustrates the deployment canary:

In fact, the name comes from the Canary publish a story. In the 17th century, the British mine workers found that the canary is particularly sensitive to gas this gas in the air even if there is a very small amount of gas, the canary will stop singing. When the gas content exceeds a certain limit, humans unaware, but it will poison canary died. In the mining equipment was relatively primitive conditions, will bring the workers to go down every time a canary as a "gas detection targets" for emergency evacuation in case of danger. Here is the first published map to a small part to test whether whole to function properly, if the normal operation mode to publish fully deployed, is still the mainstream publishing a lot of growing technology organizations.

IngressRoute can be achieved by assigning the right to re-publish the canary, and blue-green deployment, first create a top of the root IngressRoute (known as root-blog), then the routing policy domain yangcs.net/blogs cascade to lower IngressRoute (known as blog). Traffic will be lower in IngressRoute different weights forwarded to a different back-end services.

apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
  name: blog
  namespace: marketing
spec:
  routes:
    - match: /blog
      services:
        - name: green
          port: 5
        - name: blue
          port: 95

If no error occurs, it will be green weight adjusted to 100, blue weight adjustment is 0. This completes the canary release.

This paper describes the use of IngressRoute cascade function, and discusses how to use cascading capabilities to achieve the deployment of blue-green and canary released later article will continue to explore other traffic management functions.

5. References

    Cyan deployment, canary release (release gray), A / B testing precise definition

Micro-channel public number

The following sweep the two-dimensional code micro-channel public concern number, reply ◉ ◉ plus group to join our cloud-native Exchange Group, and Sun Hongliang, Zhangguan Chang, Yang Ming and other native chiefs to discuss cloud technology in the public No.

Leave a Reply