I currently have a Tyk production installation running in GCP. This was installed using the helm chart with MongoDB Atlas and Redis in memorystore in GCP (both are DB as a service).
I’m looking for instructions on how I can adapt this installation to a blue/green deployment strategy.
Do I install a new Tyk instance into the same Kubernetes cluster but with a different namespace to differentiate blue from green deployments, then configure Istio’s virtual service to set traffic weights between the two instances?
I assume I will need to configure virtual services for both the Tyk gateway and Tyk dashboard? So it’s 4 virtual services (2 for: old Tyk dashboard + gateway, 2 for: new Tyk dashboard + gateway)? Will there be any issues if I point both instances to the same database?
Hi Jesum - as you’re a paying client now you can access support at [email protected] for a faster turnaround.
For this issue, I’d recommend meeting up with the Consulting Engineer assigned to your account who should be able to help with these technical recommendations (and post a summary here after). If you reach out to support, or your account manager we can set that up. CC @Jonathan_Bernal @rahmat.latif
I eventually figured it out myself. Just deploy the following Istio components:
- Gateway (1 instance handling all ingress traffic)
- VirtualService (2 of these - one for the dashboard GKE service, one for the gateway GKE service).
For egress traffic, I decided to skip Istio and continue to use a google cloud NAT. Much simpler (don’t need an Istio egress gateway instance) and fits my needs.
I have gone ahead and made those changes in my production deployment of Tyk and everything works as expected.
My next step is to figure out the best way to deploy a parallel instance of Tyk (albeit a different version - just so I can conclusively test the traffic routing). I believe this should be in a different K8 namespace and I need to ensure the Istio VirtualService can reference both Tyk instances across the namespaces. From all indications, this appears to be possible. I will deploy and test this out. The only pre-requisite to this approach is that both Tyk versions must have database compatibility.
If there is no database compatibility, then I have to use a Tyk Operator to export configuration, create new Redis + MongoDB instances, import the config back in, configure new database connection strings for new-versioned Tyk, etc. This part isn’t terribly difficult.