This is an automated email from the ASF dual-hosted git repository.
juzhiyuan pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-ingress-controller.git
The following commit(s) were added to refs/heads/master by this push:
new 866d0bf docs: modify the format of FAQ.md (#605)
866d0bf is described below
commit 866d0bfe38b1e7bfb3340c1f1a317f8d604673f5
Author: Baoyuan <[email protected]>
AuthorDate: Sun Jul 25 15:40:40 2021 +0800
docs: modify the format of FAQ.md (#605)
---
docs/en/latest/FAQ.md | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/docs/en/latest/FAQ.md b/docs/en/latest/FAQ.md
index 7c92f9a..46b80dc 100644
--- a/docs/en/latest/FAQ.md
+++ b/docs/en/latest/FAQ.md
@@ -21,39 +21,39 @@ title: FAQ
#
-->
-1. How to bind Service and Upstream?
+### 1. 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 `service` and `upstream`
will be considered as a binding relationship.
-2. When modifying a CRD, how do other binding objects perceive it?
+### 2. 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](./design.md)
-3. Can I mix CRDs and admin api to define routing rules?
+### 3. 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.
-4. Why there are some error logs like "list upstreams failed, err: http get
failed, url: blahblahblah, err: status: 401"?
+### 4. 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.
-5. Failed to create route with `ApisixRoute`?
+### 5. Failed to create route with `ApisixRoute`
When `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](https://github.com/apache/apisix/issues/3072)
-6. What is the retry rule of `apisix-ingress-controller`?
+### 6. What is the retry rule of `apisix-ingress-controller`
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.
-7. What if the CRDs need to be updated when you upgrading
apisix-ingress-controller?
+### 7. What if the CRDs need to be updated when you upgrading
apisix-ingress-controller
CRDs upgrading is special as helm chart will skip to apply these resources
when they already exist.
