Author: Alesksey Kadetov, Certified Rancher Operator: Level One

In the past, poor canaries were used as test objects to test the content of methane in coal mines. Put the cage containing the canary into the mine with a rope for a period of time, and then pull it up. If the canary is still alive, the mine can be mined safely; If the Canary dies, it cannot be mined. Now, this method has long been abandoned because it is too inhumane to animals.

The Canary always hovers around the miner. If it stops chirping, it means that the miner must leave the mine.

Canary deployment refers to the coexistence of two versions of applications. The new version has a small scale at the beginning and handles less load traffic. With the analysis of the new deployment, all requests are gradually switched to the new version, while the old version application is removed.

It is generally believed that a Service Mesh is required to manage the traffic of these deployments. However, to manage the inbound traffic, you only need to set annotations on nginx ingress controller:

nginx.ingress.kubernetes.io/canary: "true" 
nginx.ingress.kubernetes.io/canary-weight: <num>

The disadvantage of this method is that it must be managed manually. For automation, we can use Argo Rollouts.

Run Argo Rollouts

Add helm repo: https://argoproj.github.io/ar...

argo-rollouts chart:

Helm-values:

installCRDs: true

Modify the Deployment and run Rollouts CRD

ScaleDown deployment, setting Replicas 0:

Run service

apiVersion: v1
kind: Service
metadata:
  annotations:
    argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregap
  name: rollouts-pregap-canary
  namespace: pregap
spec:
  clusterIP: 10.43.139.197
  ports:
  - name: http
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: test2-pregap
  sessionAffinity: None
  type: ClusterIP

apiVersion: v1
kind: Service
metadata:
  annotations:
    argo-rollouts.argoproj.io/managed-by-rollouts: rollout-pregap
spec:
  clusterIP: 10.43.61.221
  ports:
  - name: http
    port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: test2-pregap
  sessionAffinity: None
  type: ClusterIP

Run Rollouts CRD

Since we don't want to change the deployment, we refer to it in the Rollout manifest: workload Ref kind: Deployment, workloadRef. name

Running manifest will create additional ingress:

Argo Rollouts dashboard

Other steps in CD pipeline

Yes drone. Add lifting steps to YML:

 name: promote-release-dr
  image: plugins/docker
  settings:
    repo: 172.16.77.115:5000/pregap
    registry: 172.16.77.115:5000
    insecure: true
    dockerfile: Dockerfile.multistage
    tags:
    - latest
    - ${DRONE_TAG##v}
  when:
    event:
    - promote
    target:
    - production

- name: promote-release-prod
  image: plugins/webhook
  settings:
    username: admin
    password: admin
    urls: http://172.16.77.118:9300/v1/webhooks/native
    debug: true
    content_type: application/json
    template: |
      {        "name": "172.16.77.115:5000/pregap",
        "tag": "${DRONE_TAG##v}"      }
        when:
    event:
    - promote
    target:
    - production

Plus Keel approval:

conclusion

Canary deployment or green / Blue deployment is not difficult at all - it will improve the reliability of the production environment and reduce the affected areas in the event of any design errors. In the future, I will add RAM to the server, and it is possible to enable Prometheus monitoring and Istio, and try to perform the analysis and experiment phases to realize Argo Rollouts.