Baoyuantop commented on issue #2709: URL: https://github.com/apache/apisix-ingress-controller/issues/2709#issuecomment-3889491224
Let me explain why the CRD types (v2) don't directly reuse the APISIX Admin API types (adc): 1. They serve different audiences and abstraction levels CRD types are the Kubernetes-facing declarative API, designed for K8s users. They use Kubernetes-native concepts and conventions (camelCase naming, serviceName/servicePort referencing K8s Services, metav1.Duration for timeouts, SecretRef for sensitive data, etc.). ADC types are the APISIX data-plane configuration, mirroring the APISIX Admin API structure (snake_case naming like remote_addrs, filter_func, integer-based timeouts, Upstream.Nodes with IP/Port/Weight, etc.). 2. The mapping is not 1:1 A single ApisixRouteHTTP rule in the CRD gets translated into multiple ADC objects (Service + Route + Upstream). The CRD references Kubernetes Services by name, but APISIX needs resolved endpoint IPs. Features like ResolveGranularity (endpoint vs. service level), Subset, injecting plugin config from K8s Secrets (SecretRef), and match expressions (Subject/Scope/Op/Value → APISIX vars nested arrays) all require non-trivial transformation that wouldn't be possible with shared structs. -- 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]
