request help: Question about Composite Ingress feature maturity and GA plans
Issue description
Hi team,
I’ve been reviewing the Composite Ingress feature and I’m very interested in adopting it in our environment. However, I noticed that it is currently marked as experimental.
I have a few questions regarding its status:
Maturity: Could you share more about the current stability and real-world usage of the feature? Are there known limitations or caveats we should be aware of?
GA Timeline: Is there a roadmap or estimated timeline for when the Composite Ingress feature might be promoted to General Availability?
Technical Impact: I saw that this implementation removes the need for etcd. Does this change increase the load or pressure on the Kubernetes API server in any significant way? We’d like to understand the operational implications before moving forward.
Thank you!
Environment
- your apisix-ingress-controller version (output of apisix-ingress-controller version --long):
- your Kubernetes cluster version (output of kubectl version):
- if you run apisix-ingress-controller in Bare-metal environment, also show your OS version (uname -a):
Hi @vortegatorres , thank you for your interest. The core team is building the new ingress controller and will release the middle of June.
the new architecture doesn't need mock etcd and real etcd, so we can keep far away the issue that etcd is not stable in k8s.
if you are interested in the new design, let me know (juzhiyuan at apache.org) and we can setup a quick call as the documents are not public yet.
Hi @vortegatorres , thank you for your interest. The core team is building the new ingress controller and will release the middle of June.
the new architecture doesn't need mock etcd and real etcd, so we can keep far away the issue that etcd is not stable in k8s.
if you are interested in the new design, let me know (juzhiyuan at apache.org) and we can setup a quick call as the documents are not public yet.
@juzhiyuan Thanks so much for your response. I'm actually quite interested because we're using APISIX in our production environment and have experienced some instability issues related to etcd. That's why we're currently testing the Composite Architecture. However, if you're working with a different architecture that's more likely to be production-ready than Composite, I'd be very interested in learning more about it.
updates: https://lists.apache.org/thread/r8ydjz4nq35xokov2lc6sfhppybqwgrn
updates: https://lists.apache.org/thread/r8ydjz4nq35xokov2lc6sfhppybqwgrn
Thanks for the information! I have a question: From what I read in the link, it looks like you're refactoring the Ingress Controller to use the controller-runtime and Kubebuilder frameworks. However, I didn't see any mention of etcd being removed, is that part of the plan as well?
Also, I’ve sent you an email to coordinate the call in case you’re still available. Appreciate it!
Hi @vortegatorres, in the new design, instead of using ETCD or Mock ETCD, the new ingress controller workflow is as follows: The Ingress Controller will work with APISIX Standalone (https://docs.api7.ai/apisix/production/deployment-modes#standalone-mode and https://github.com/api7/apisix-standalone-sample/tree/main). Within the Controller implementation, it will convert the input (YAML) into ADC format (https://github.com/api7/adc). This format will then be transformed into Standalone configurations for APISIX to use, thus addressing the issue of reliance on ETCD.
Updates: APISIX Ingress Controller 2.0.0 RC1 has been published. Refer to https://github.com/apache/apisix-ingress-controller/tree/v2.0.0/docs
@juzhiyuan Is there an estimated timeline for the GA release?