I am new to kubernetes just doing little R&D on k8s. was checking out different deployment strategies like rolling update, recreate, blue-green and canary. if am correct the idea behind canary deployment is rolling out new version to set of users. here my questions lets my team has developers and testing team. whenever testing team try to access the application it should redirect to new version of application, is it possible? or canary is only used for having 2 version applications running at same time with one service?
if am correct the idea behind canary deployment is rolling out new version to set of users. here my questions lets my team has developers and testing team.
The term Canary Deployment does not have a precise definition as what I know. But it usually means that you deploy a new version of your app and only let a small fraction of your traffic hit the new version, e.g. 5% or 15% - and then have a Canary Analyzer (e.g. Kayenta) to analyze the metrics for the new and the old version - and then do an automatic decision to route all your traffic to the new version or to rollback the deployment.
The good thing with this is the high degree of automation - humans does not have to monitor the metrics after the deployment. And if there was a bug in the new version, only a small fraction of your customers were affected. But this is also challenging since you need a certain amount of traffic for a good statistical ground.
whenever testing team try to access the application it should redirect to new version of application, is it possible?
What you want here is to route the traffic to a specific version, based on a property of the user, e.g. from the authentication token.
You need a service mesh like e.g. Istio and base your authentication on JWT e.g. OpenID Connect to do this in Kubernetes.
From the Istio documentation, you need to create a RequestAuthentication and an AuthorizationPolicy for your app.
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
jwtRules:
- issuer: "issuer-foo"
- issuer: "issuer-bar"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
rules:
- from:
- source:
requestPrincipals: ["issuer-foo/*"]
to:
hosts: ["example.com"]
- from:
- source:
requestPrincipals: ["issuer-bar/*"]
to:
hosts: ["another-host.com"]The JWT and list-typed claims part of the documentation describes how to specify rules for a specific user name (sub) or a property / group of users with claims. E.g.
when:
- key: request.auth.claims[groups]
values: ["test-group"]Yes, it is possible if you are using your Kubernetes cluster with isito you can manage the canary deployment move one specific user traffic to a specific version.
Based on the sticky session also you can manage specific users get each time a new version.
There are many ways to handle this scenario, for example, you can do it by injecting some headers.
For specific user pass some specific header and based on that route the traffic from isito to new version.