- How to bind Service and Upstream?
All resource objects are uniquely determined by the namespace / name / port combination Id. If the combined Id is the same, the
upstream will be considered as a binding relationship.
- When modifying a CRD, how do other binding objects perceive it?
This is a cascading update problem, see for details apisix-ingress-controller Design ideas
- Can I mix CRDs and admin api to define routing rules?
No, currently we are implementing one-way synchronization, that is, CRDs file -> Apache AIPSIX. If the configuration is modified separately through admin api, it will not be synchronized to CRDs in Kubernetes.
This is because CRDs are generally declared in the file system, and Apply to enter Kubernetes etcd, we follow the definition of CRDs and synchronize to Apache Apisix Data Plane, but the reverse will make the situation more complicated.
- Why there are some error logs like "list upstreams failed, err: http get failed, url: blahblahblah, err: status: 401"?
So far apisix-ingress-controller doesn't support set admin_key for Apache APISIX, so when you deploy your APISIX cluster, admin_key should be removed from config.
Note since APISIX have two configuration files, the first is config.yaml, which contains the user specified configs, the other is config-default.yaml, which has all default items, config items in these two files will be merged. So admin_key in both files should be removed. You can customize these two configuration files and mount them to APISIX deployment.
- Failed to create route with
apisix-ingress-controller creates a route with CRD, it checks the
Endpoint resources in Kubernetes (matched by namespace_name_port). If the corresponding endpoint information is not found, the route will not be created and wait for the next retry.
Tips: The failure caused by empty upstream nodes is a limitation of Apache APISIX, related issue
- What is the retry rule of
If an error occurs during the process of
apisix-ingress-controller parsing CRD and distributing the configuration to APISIX, a retry will be triggered.
The delayed retry method is adopted. After the first failure, it is retried once per second. After 5 retries are triggered, the slow retry strategy will be enabled, and the retry will be performed every 1 minute until it succeeds.