Question about APISIX architecture: control-plane

[ligreman]

Hi! I have read all the documentation and have already tested and played with APISIX. I have a question regarding the control-plane.

Our production environment is very tight on resources, so I was thinking of deploying "decoupled mode" with only the etcd + dashboard + dataPlane. I don't need the ingress controller, and I won't use the control-api at all. Is the control-plane mandatory in an APISIX deployment?

Reading this (https://github.com/apache/apisix-control-plane) it seems to me that it is optional, to get the declarative definition and the relationships restrictions functionalities, but if we won't be using those I think we could just avoid deploying the control-plane, am I wrong?

In my tests I have seen that the dashboard integrates the admin-api itself, and you don't need the control-plane if you are going to manage the api gateway through the admin-api/dashboard.

Thanks.

[dosubot[bot]]

Hey @ligreman! 👋 I'm here to help you with any questions or issues you have while working with APISIX. I can assist with bugs, provide guidance, and even help you become a contributor.

The control plane in APISIX is indeed optional. If you are managing your API gateway using the Admin API and dashboard, and do not require the additional functionalities provided by the control plane, such as declarative configuration, incremental synchronization, and transaction processing, you can deploy APISIX without it. Your understanding is correct; the control plane is not mandatory if you are not utilizing its specific features.

To continue talking to Dosu, mention @dosu.

[ligreman]

@dosu for reference, could you describe in detail describe the functionality of each Apisix component? The components are: dashboard, data-plane, control-plane and ingress controller.

[dosubot[bot]]

Certainly! Here's a detailed description of each APISIX component:

1. Dashboard:

   • The APISIX Dashboard is a web-based interface that allows users to manage and configure the API Gateway. It provides a user-friendly way to interact with the Admin API, enabling tasks such as creating routes, managing plugins, and monitoring traffic. The dashboard simplifies the management of APISIX without needing to directly interact with the API through command-line tools or scripts.

2. Data-Plane:

   • The APISIX Data-Plane is responsible for handling user requests and applying configurations. It operates in different modes:
     • Decoupled Mode: Fetches configurations from the Control-Plane and handles requests. It performs health checks on Control-Plane addresses before starting.
     • Standalone Mode: Reads configurations from a local YAML file and operates independently without a Control-Plane.
     • Traditional Mode: Deployed together with the Control-Plane in a single instance, managing configurations via etcd.
   • The Data-Plane is crucial for processing incoming API requests and applying the necessary routing and plugin logic ^[1][2].

3. Control-Plane:

   • The APISIX Control-Plane enhances management capabilities, especially in complex environments. It supports features like service discovery, integration with Istio, and Kubernetes Ingress Controller. It allows for centralized management and configuration of Data-Plane instances, supporting declarative configuration and dynamic updates. The Control-Plane is optional and mainly used for advanced management scenarios ^[3][4].

4. Ingress Controller:

   • The APISIX Ingress Controller integrates with Kubernetes to manage traffic routing and API management. It converts Kubernetes resources into APISIX configurations, supporting service discovery, dynamic configuration, and a rich plugin ecosystem. It is particularly useful for complex routing, rate limiting, and other advanced API management needs within Kubernetes environments. The Ingress Controller can be deployed within a Kubernetes cluster or across multiple clusters, providing flexibility and scalability ^[4][5].

These components work together to provide a comprehensive API management solution, with each playing a specific role in the architecture.

To continue talking to Dosu, mention @dosu.

[ligreman]

@dosu is there any documentation describing the funcionatilites that the dashboard lacks compared to the admin API? I want to know what can be done through the admin api but cannot be done yet using the dashboard.
Thanks.

[dosubot[bot]]

There isn't specific documentation detailing the functionalities available in the Admin API that are not yet implemented in the APISIX Dashboard. However, the Admin API documentation provides a comprehensive overview of its features, including configuration details, request methods, and parameters for managing routes, services, and consumers. You can explore these features in the Admin API documentation to identify any functionalities that might not be available in the Dashboard ^[1].

To continue talking to Dosu, mention @dosu.

[moonming]

For API gateway, both data plane and control plane are necessary. Control plane may have various forms:

1. dashboard
2. admin API
3. ingress controller
4. ADC
   All of them store and manage data through etcd. Which one to choose depends on your deployment environment and dependencies.

You can also choose standalone mode. In this mode, there is no control plane and etcd, and the configuration is managed through local files. Of course, the synchronization and update of this file needs to be handled by yourself.

[ligreman]

Thanks @moonming.

In my kubernetes scenario I need etcd (can't manage configuration through files), and will use dashboard to manage the API Gateway. How do you recommend doing the deployment? decoupled or traditional?

I have tried decoupled deploying only the daashboard+etcd+dataplane. The dataplane pod didn't started because it raised an error "waiting for control plane".

I don't know if I made some error in the configuration, or the control-plane is mandatory in the decoupled mode. Or... thinking about it now... I first deployed it with the control-plane and then redeployed without it... is there any configuration in etcd saved related to the control-plane?

I must try to deploy with an empty etcd.