[discuss] do we need to support parsing native ingress yaml? about apisix-ingress-controller

[Miss-you]

我的建议如下
1、apisix入口支持标准的种类：ingress，不支持注解部分
2、apisix扩展功能通过apisixRoute支持
3、提供一个转换器，将标准ingress转换成apisixRoute

My suggestions are as follows

1. The types of apisix entry support standards ingress, no need to support the annotation part
2. Apache APISIX extension function supporting via apisixRoute
3. Provide a converter to convert standard ingress to apisixRoute

[Miss-you]

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

[gxthrj]

我的建议如下
1、apisix入口支持标准的种类：ingress，不支持注解部分
2、apisix扩展功能通过apisixRoute支持
3、提供一个转换器，将标准ingress转换成apisixRoute

My suggestions are as follows

1. The types of apisix entry support standards ingress, no need to support the annotation part
2. Apache APISIX extension function supporting via apisixRoute
3. Provide a converter to convert standard ingress to apisixRoute

Yes, this is an idea, but it will cause other problems. For example, the definition of a route will be in multiple files. You need to combine ingress and apisixRoute to determine the configuration of a route, which will cause troubles for operation and maintenance personnel.

[gxthrj]

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

We can refer to how the Kong ingress controller does it. Does it define a new CRD object or is it compatible with the original ingress configuration?

We did learn a lot from kong ingress. We still have some ideas of our own, because apisix and kong still have many differences, such as the implementation of route or plugins.

Well, let's continue to explore the definition of inress.
Kong ingress uses kongIngress CRD to extend the definition of inress, uses kongPlugin to define plugins, and then binds ingress and service through annotation.

I don't think the way of using annotation is very intuitive. For example, in order to successfully define a route, we need to define kongIngress and kongPlugin. At the same time, we need to modify the annotation of service and service. This involves the creation and modification of 2-4 files.

Another problem, we can know which kongIngress is associated from the annotation of ingress, but we don't know how many ingress are referenced by kongIngress. So you have to be very careful to modify kongIngress, and be aware of the scope of this change, or strictly regulate the behavior of users.
So, kong provides konga.

However, we distinguish CRD according to the domain boundary, uniformly define the route-related configuration in apisixRoute, and take into account both ingress and extension on the data structure to facilitate rapid migration.
I believe this migration cost is worth it, and the benefit is that it no longer needs to define routes in multiple files.

[tokers]

We have already supported it.