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 process as well as the different options you have. 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:

1. Decide which deployment topology you plan to use.
2. Install kumactl.
3. Deploy the control plane.
4. Configure the data plane.
5. Configure security features for Kuma.

Deployment topologies

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 data centers.	Multi-zone

kumactl

The first step after you pick your deployment mode is to install kumactl. 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.

The kumactl binary is a client to the Kuma HTTP API.

Control plane and data plane architecture

Once 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.

You can either configure a multi-zone or standalone control plane, depending on your organization’s needs. You can deploy either a Kubernetes or Universal data plane.

Security

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
• Require data plane proxy authentication to obtain a configuration from the control plane
• Require zone proxy authentication to obtain a configuration from the control plane
• Configure data plane proxy membership constraints when joining a mesh