API configuration files

Hi,

I have a POC of tyk running in EKS with operator to load API config from k8’s manifests (ApiDefinition files). I’m finding that the as im running 2 nodes, the operator is only updating 1 node with the configuration.

From this is it possible to do either of:

  1. Use a DB to store the configuration making sharable
  2. Setup PV to share the apps folder. From what I can see this might not be built into the helm chart meaning that a forked version is required.

thanks

1 Like

We used option 2, that works fine, provided that you use a PVC using an EFS storage class. This allows a network mounted FS to share the apps folder. Tyk operator already uses the group reload, so all nodes will perform a hot reload.

We had to fork the helm chart, unfortunately…

Barry

Thank you Barry. I was hoping option 1 would be available as forking the helm chart and keeping it inline is going to be a pain with the additional mount into the deployment part.

I’m very surprised that the default helm built is a daemonset with this issue.

I like the option of tyk-sync, but ideally i want the developers to write a helm for their microservice with an ApiDefinition in meaning its a single deployment rather than pushing an ApiDefinition to a separate repo with makes updates less smooth.

PVC storage class feels like an acceptable workaround for the short term. But it’s exactly that - a workaround with complexities of its own.

For pure Open Source users - We are actively looking into the ability for Operator to natively discover deployed gateways in the cluster so that the Operator can manage them and the Gateways can then be ephemeral and scale. Although I can’t give any timelines for this to be available.

I’m very surprised that the default helm built is a daemonset with this issue.

I would recommend changing this to Deployment - and setting your pods to 1. It was a decision which was made many years ago, and to not break changes for users who use it as-is, we have not changed the default.

i want the developers to write a helm for their microservice with an ApiDefinition

This is exactly how many of our customers develop their microservices - they create helm charts per microservice, and bake in the Tyk ApiDefintion resource and potentially SecurityPolicy resource too.

2 Likes

Thank you. Yes, im testing now on a deployment rather than daemonset to ensure I can continue. With regards to Pro does this store them in the Portal Database to allow discovery by all gateways?

Yes - Paid Licensed customers (Pro) get a completely different experience.

The reason for this, is because the Dashboard and Developer portal are services which the Operator can speak to - and the Dashboard is the control plane responsible for orchestrating gateways. The Dashboard is a licensed product which is not offered to open source users.

Paid customers can also publish their microservice APIs along with documentation to a developer portal for easy discovery.

This was the initial PoC (for the value prop) Kubernetes native APIs as Products with Tyk Operator - YouTube

And here are tutorial docs: Publish an API with Tyk Operator

1 Like