tyk-operator icon indicating copy to clipboard operation
tyk-operator copied to clipboard

Published 20 hours ago • verified publisher icon TykTechnologies

[TT-5183] - Operator support with multiple replicas of GW

Open brahama opened this issue 3 years ago • 10 comments

Hi!

I've been playing a bit with the K8s deployment and Operator and its amazing. One thing that i noticed is that it is not straightforward to run the operator with N replicas in the deployment. APis are only created at one random pod behind the service and not in all.

My first question is how much work and difficulty it owuld entail to make it work across all PODs behind a service? to see if we can contribute.

Second question is if ther eis a workaround for a Production implementation with multiple replicas of the GW using the operator. I've seen a Sync tool but seems like it would make the operator "useless"..

Thanks a lot!

brahama avatar Apr 26 '22 14:04 brahama

Hi fellows! any inputs regarding this? Cheers

brahama avatar May 15 '22 23:05 brahama

Hi @brahama, This is indeed a problem we want to solve for our OSS users. Operator shall be able to discover all the gateway PODs in the cluster and push changes to all of them.

Please keep this issue open - we'll update it with a timeline when we have more solid plan.

caroltyk avatar May 16 '22 14:05 caroltyk

Thanks @caroltyk ! any way i can help i will do my best. Cheers!

brahama avatar May 17 '22 16:05 brahama

Hi @brahama, before we work on the feature, maybe you can check out some workarounds from the community and see if it helps: https://community.tyk.io/t/api-configuration-files/5664/3

caroltyk avatar Sep 01 '22 13:09 caroltyk

Appreciate it @caroltyk :) will take a look. 😸

brahama avatar Sep 01 '22 14:09 brahama

@caroltyk would be very interested to know if this has made it on to a plan yet? The Operator looks great and aligns with how we would like services to manage their associated API definitions (basically as another resource synced via ArgoCD).

The shared storage workaround, when on on Google Cloud Platform, means picking between provisioning a 1TB (that's the minimum!) Filestore volume or self managed NFS. Both possible but not sensible when used only for the gateway config.

For now it looks like we wont be able to use the Operator and will instead mount the files via configmaps.

andywirv avatar Nov 25 '22 09:11 andywirv

Hi @andywirv, we have it planned for Q2 next year. Please stay tuned!

caroltyk avatar Nov 30 '22 12:11 caroltyk

Hi @andywirv, we have it planned for Q2 next year. Please stay tuned!

Is this still in the pipeline?

lou-stagwell avatar Jun 28 '23 16:06 lou-stagwell

Sorry @lou-stagwell I missed the notification for this. We have gone ahead with Tyk without the operator. I am going to look at v5 upgrade soon. Would be interested to know if the operator has moved forward. We are using GraphQL and supergraph with k8s configmaps and I expect we will hit size limitations with that at some point

andywirv avatar Aug 30 '23 19:08 andywirv

An update on the timeline.. Regrettably we have dropped this from the roadmap and are focusing on supporting the new OAS API type in Tyk.

@andywirv I'm also interested to learn about your experience in upgrading and using GraphQL and supergraph. Are you using Operator for that?

caroltyk avatar May 17 '24 15:05 caroltyk