macmiranda commented on issue #610: URL: https://github.com/apache/apisix-ingress-controller/issues/610#issuecomment-1322045388
I'm new to APISIX so I started reviewing the [Architecture](https://apisix.apache.org/docs/apisix/architecture-design/apisix/) and the [Deployment modes](https://apisix.apache.org/docs/apisix/deployment-modes/), alongside the documentation of the [Ingress Controller](https://apisix.apache.org/docs/ingress-controller/tutorials/the-hard-way/) itself (since my goal is to manage APISIX via Kubernetes CRDs and use it as an alternative Ingress Class for K8s Ingresses) If my understanding is correct, the APISIX Ingress Controller makes the APISIX Control Plane (and the Admin API for that matter) almost entirely obsolete (at least in the context being discussed here). If the actual configuration of APISIX is now done via Custom Resources (which are ultimately persisted in the `etcd` of the cluster itself) why would we need another `etcd` cluster to persist configuration data? I'm guessing that the current architecture of the Ingress Controller was meant to be a functional adapter for the APISIX Admin API without having to introduce any significant changes to the latter whilst still making it possible to use APISIX in the context of a Kubernetes Cluster (and its resources). While it does what it's meant to do, it also introduces certain problems, some of which deserve serious consideration: - the `etcd` cluster installed with APISIX in the Traditional mode does not get backed up through regular cluster backups - in order to be able to talk to the Admin API and configure routes, upstreams, etc. the Ingress Controller needs to store the admin user key in a Config Map which is essentially insecure and makes it harder for credentials to be rotated. Setting those keys in Helm values also isn't a good solution since we store all the values in our SCM. The best would be if we could get those values from Vault. - the Ingress Controllers' IP addresses need to be hard-coded in the APISIX Control Plane configuration if we want to take advantage of the `admin.allow.ipList`. It can be quite challenging to get those values when installing both charts via Helm (without hard-coding them and they are essentially dynamic) so you end up having to allow the whole Cluster Network range or `0.0.0.0/0` - maintaining an extra Control Plane and an extra `etcd` cluster means more overhead for the Platform teams and introduces more points of failure. It would be great if the Ingress Controller could talk directly to the Data Plane in standalone mode. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
