Careful!
You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
Standalone deployment
About
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).
Limitations
- 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.
Usage
In order to deploy Kuma in a standalone deployment, the kuma-cp control plane must be started in standalone mode:
This is the standard installation method as described in the installation page.
kumactl install control-plane | kubectl apply -f -
With zone egress:
It’s possible to run ZoneEgress for standalone deployment. In order to deploy Kuma with ZoneEgress run the install command with an additional parameter.
kumactl install control-plane --egress-enabled | kubectl apply -f -
Once Kuma is up and running, data plane proxies can now connect directly to it.
When the mode is not specified, Kuma will always start in standalone mode by default.
Failure modes
Control plane offline
- New data plane proxies won’t be able to join the mesh. This includes new instances (Pod/VM) that are newly created by automatic deployment mechanisms (for example, a rolling update process), meaning a control plane connection failure could block updates of applications and events that involves new instances to be created.
- On mTLS enabled meshes, a data plane proxy may fail to refresh its client certificate prior to expiry (defaults to 24 hours), thus causing traffic from/to this data plane to fail.
- 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.