About Kuma in Production
After you’ve completed your initial test and assessment of Kuma, it’s time to deploy Kuma in your production environment. Before doing so, it’s important to understand the overall steps in the deployment process as well as the different options you have when deploying Kuma. This guide walks you through the big picture steps and options so you can make the right decisions when it comes to deployment time.
Overview of deployment steps
Deploying Kuma to a production environment involves the following steps:
- Decide which deployment topology you plan to use.
- Deploy the control plane.
- Configure the data plane.
- Configure security features for Kuma.
There are two deployment models that can be adopted with Kuma: standalone and multi-zone. You can use these modes to address any service mesh use case, including:
- A simple model with the service mesh running in one zone
- A more complex model where multiple Kubernetes or VM zones are involved
- A hybrid universal model where Kuma runs simultaneously on Kubernetes and VMs
The following table describes some common use cases and the deployment modes you can use for them:
|Use case||Recommended deployment mode|
|You want to migrate from on-premise or virtual machines to the cloud in a brownfield project.||Multi-zone|
|You only intend to deploy Kuma in one zone, like one Kubernetes cluster or Amazon VPC.||Standalone|
|You want to run a mix of Kubernetes and Universal zones.||Multi-zone|
|You want to run workloads in different regions, clouds, and/or datacenters.||Multi-zone|
The first step after you pick your deployment mode is to install
kumactl is a CLI tool that you can use to access Kuma. It can do the following:
- Perform read-only operations on Kuma resources on Kubernetes.
- Read and create resources in Kuma in Universal mode.
kumactl binary is a client to the Kuma HTTP API.
Control plane and data plane architecture
kumactl is installed, you can use it to configure the control plane and deploy the data plane. The control plane (CP) is never on the execution path of the requests that the services exchange with each other. It’s used as a source of truth to dynamically configure the underlying data plane proxies that are deployed alongside every instance of every service that is part of the service mesh.
Kuma offers many security features that you can use to ensure your service mesh is safe.
Here are a few of the main features:
- Secure the access to your Kuma deployment
- Store sensitive data with secrets
- Manage access control to administrative actions executed on the Kuma API Server
- Required data plane proxy authentication to obtain a configuration from the control plane
- Required zone proxy authentication to obtain a configuration from the control plane
- Configure data plane proxy membership constraints when joining a mesh