0

I have two deployment files 1. deployment-1.yaml apiVersion: apps/v1 kind: Deployment metadata: name: process labels: app: process spec: replicas: 3 selector: matchLabels: app: process template: metadata: labels: app: process version: v1 spec: containers: - name: pull image: parma/k8s-php:red ports: - containerPort: 80

2. deployment-2.yaml apiVersion: apps/v1 kind: Deployment metadata: name: process labels: app: process spec: replicas: 3 selector: matchLabels: app: process template: metadata: labels: app: process version: v2 spec: containers: - name: pull image: parma/k8s-php:green ports: - containerPort: 80

As i have specified two different versions in spec.template.metadata, it does not keep running 6 pods for both replica set, it only enables latest replicaset up and running.

Is there any way to achieve canary deployment by keeping both the replicaset in single deployment up and running with 3 pods from v1 and 3 pods from v2

2 Answers2

4
  1. You can't have multiple deployments with the same name. Rename them to process-v1 and process-v2.
  2. You need to have different selectors for each of them. First one should have matchLabels: {app: process, version: v1}, the second one matchLabels: {app: process, version: v2}.

So technically that will be two completely separate deployments. What makes them "baseline" and "canary" is how you send traffic to them. If you specify common selector (just {app: process}) in your service, then both of the deployments will see a fraction of traffic.

Alex Lurye
  • 571
  • 2
  • 5
  • 1
    I want that two replicaset to be running parallel for both versions in a single deplyoment, will it be possible? – Paramanand Dhuri May 15 '18 at 10:06
  • No. One deployment = one version. Why would you need that? – Alex Lurye May 15 '18 at 13:44
  • So that both the versions can be managed by the kubernetes single deployment and after some time the load will be shifted to single version deprecating the older version based on health check – Paramanand Dhuri May 29 '18 at 08:22
  • Deployment can be in intermediate states when it runs old and new versions, but it tries hard to resolve it as quickly as possible and move the system to the target state. Target state for the deployment can be one specific version only. If you want to run canary for a while (minutes, hours, days?), your target state can't be described with one version - it must be two different versions, i.e. two deployments. – Alex Lurye May 29 '18 at 18:48
2

The name of what you want to implement is Canary Deployment. It is a great feature for A / B testing and assists in continuous delivery and production testing, it does not have to be in the same deploy the secret this in the load balancer and at the gateway. There are options in the market for this (Spring Zuul or Istio Envoy) that can provide a solution that filters content from one deploy to a certain percentage and the other to the rest ...