This is the simplest deployment mode for Kuma, and the default one.
- Control plane: There is one deployment of the control plane that can be scaled horizontally.
- Data plane proxies: The data plane proxies connect to the control plane regardless of where they are deployed.
- Service Connectivity: Every data plane proxy must be able to connect to every other data plane proxy regardless of where they are being deployed.
This mode implies that we can deploy Kuma and its data plane proxies in a standalone networking topology mode so that the service connectivity from every data plane proxy can be established directly to every other data plane proxy.
Standalone mode is usually a great choice within the context of one zone (ie: within one Kubernetes cluster or one AWS VPC).
- All data plane proxies need to be able to communicate with every other dataplane proxy.
- A standalone deployment cannot mix Universal and Kubernetes workloads.
- A deployment can connect to only one Kubernetes cluster at once.
If these limitations are problematic you should look at Multi-zone deployments .
Components of a standalone deployment
A standalone deployment includes:
- The control planes:
- Accept connections from data plane proxies.
- Accept creation and changes to policies that will be applied to the data plane proxies.
- Keep an inventory of all data plane proxies running.
- Compute and send configurations using XDS to the data plane proxies.
- The data plane proxies:
- Connect to the zone control plane.
- Receive configurations using XDS from the control plane.
- Connect to other data plane proxies.
Control plane offline
- New data planes proxis won’t be able to join the mesh.
- Data-plane proxy configuration will not be updated.
- Communication between data planes proxies will still work.
You can think of this failure case as “Freezing” the zone mesh configuration. Communication will still work but changes will not be reflected on existing data plane proxies.