|author||John Bampton <firstname.lastname@example.org>||Sun Feb 28 23:19:32 2021 +1000|
|committer||GitHub <email@example.com>||Sun Feb 28 21:19:32 2021 +0800|
chore: remove unneeded whitespace before commas (#40)
apisix-control-plane is an implementation of providing a control plane for DPs (Data Plane) like Apache APISIX or other gateways. with a
yaml configuration capability, We can use
yaml to define the behavior of any DP.
For now, we have a default implementation for Apache APISIX.
As we know, Apache APISIX is a high-performance gateway. When using APISIX we need to inform APISIX of some proxy rules, and distribute these rules to APISIX modules. We can call it control-plane, similar to pilot in istio. Of course, the distribution configuration is only the most basic function of the control plane.
We know that APISIX already has Admin API, so why do we need to implement a control-plane?
First of all, Apache APISIX Admin API is a way to define a single object, such as a single object such as route / service / upstream / consumer, although it is also possible to completely define a route through a huge route object, and the upstream object is embedded in the route, But any minor changes will trigger the reconstruction of the route. Rebuilding the route is definitely not a good idea and reduce performance.
In fact, leaving aside the Admin API, what we need is a description method that can completely define the rules while maintaining the legibility of the Admin API. Therefore, we have discussion here, and we have implemented a version of the basic functions according to this data structure, I hope everyone puts forward their views. We can also submit a PR to modify this document.
Secondly, Apache APISIX Admin API uses id associations to strongly bind objects to express the relationship between objects. For example, the route object uses
upstream_id to bind the relationship with service and upstream respectively.
This kind of representation, like the well-known relational database, is easier to understand and reduces redundant configurations. But it also brings some other problems. For example, rely on verification. When we want to bind an
upstream_id to a route, we must first create the upstream, and then bind the generated
upstream_id to the route. This process corresponds to two Admin APIs, and there is no transaction management.
We hope that the emergence of control-plane can solve the above two problems.
Of course, with control-plane we can do more.
For example, based on gitops configuration version management, it is also more convenient to use yaml to define APISIX in k8s.
Realize the prototype of cross-cluster synchronization configuration through the control panel. In the future, we can also enrich the functions of the control plane and simplify management under the cluster mode of multi-platform hybrid deployment (k8s/vm). We can also shield specific implementations of APISIX and provide configuration functions for more types of gateways.
We created apache/apisix-control-plane to provide the basic implementation of the above features.
We also plan to support the following features
Everyone is welcome to participate in discussions and contributions.