Open rauanmayemir opened 1 year ago
From my understanding, the separation of concern for ingress controller is because APISIX supports plain Docker runtime, or purely on barebone server, replacing NGINX with a nicer wrapper. I had same thought and I really wanted to set up a production-grade ETCD out of the K8s scope. Then you keep the original K8s stateless. However, you have the fallback option which is the standalone mode, the routes are maintained under ConfigMap. The best thing is the data structures are very similar between different modes. So first thing to consider is, do you need Admin API or just plain static routes? One of the best practices is to keep routes a part of IaC.
@xgenvn Yeah, I've seen the standalone mode, but I do need to be able to update the routes and probably even do canary deployments. Neither using static config, nor calling API from CI feels like a solid approach. Ideally, xDS with hot-reloading would be the best option.
@rauanmayemir have you solved your problem now?
This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the dev@apisix.apache.org list. Thank you for your contributions.
Description
I was evaluating apisix as a 'level two' proxy for my systems and bottom line is apisix is really amazing.
By level two I meant that there would be something handling the 'level one' traffic, in my case it's cilium (envoy, to be precise). And then it proxies the traffic to apisix-gateway service which then would handle my services.
Basically, apisix-gateway would be API Gateway for my specific services, whereas ingress would be handled by cilium via kubernetes gateway api. (as if we needed more confusing terminology :|)
The only thing that bothered be is the rather 'stateful' nature of apisix.
Currently, I have 3 components: apisix dashboard, apisix gateway, etcd cluster. If not for having to provision upstreams and routes via api calls, I would be very happy with this setup.
Thinking I would not need apisix's ingress controller, I was very surprised to discover it's not just a wrapper for ingress, but that it also provides declarativeness via CRDs.
I'm curious why CRDs are part of ingress-controller instead of apisix itself? Or some child project, so that it could be used for general management of apisix resources (without needing to be tied to ingress).
I've seen that there are plans and even merged PRs that will lead to getting rid of the separate ETCD cluster and admin api in general, which could be even better. I wonder which way should I go exploring so that it's future-proof?
Environment