The first step is obviously to on the platform of your choice. Different distributions will present different installation instructions that follow the best practices for the platform you have selected.

Regardless of what platform you decide to use, the fundamental behavior of Kuma at runtime will not change across different distributions. These fundamentals are important to explore in order to understand what Kuma is and how it works.

Installing Kuma on Kubernetes is fully automated, while installing Kuma on Linux requires the user to run the Kuma executables. Both ways are very simple, and can be explored from the installation page.

There are two main components of Kuma that are very important to understand:

• Data-Plane: Kuma also bundles a data-plane implementation based on top of for convenience, in order to get up and running quickly. An instance of the data-plane will run alongside every instance of our services, and it will process both incoming and outgoing requests for the service.

Multi-Mesh: Kuma ships with multi-tenancy support since day one. This means you can create and configure multiple isolated Service Meshes from one control-plane. By doing so we lower the complexity and the operational cost of supporting multiple meshes. Explore Kuma's Policies.

• kuma-cp: this is the main Kuma executable that runs the control plane (CP).
• kuma-dp: this is the Kuma data-plane executable that - under the hood - invokes envoy.
• kumactl: this is the the user CLI to interact with Kuma () and its data.

• kuma-tcp-echo: this is a sample application that echos back the requests we are making, used for demo purposes.In addition to these binaries, there is another binary that will be executed when running on Kubernetes:

• kuma-injector: only for Kubernetes, this is a process that listens to events propagated by Kubernetes, and that automatically injects a kuma-dp sidecar container to our services.A minimal Kuma deployment involves one or more instances of the control-plane (kuma-cp), and one or more instances of the data-planes (kuma-dp) which will connect to the control-plane as soon as they startup. Kuma supports two modes:

• : when it's being deployed - well - on Kubernetes.

When running in Universal mode, Kuma will require a PostgreSQL database to store its state. The PostgreSQL database and schema will have to be initialized accordingly to the installation instructions.

Unlike kubernetes mode, Kuma won't require the kuma-injector executable to run:

When following the installation instructions, kuma-injector will be automatically started.

Full CRD support: When using Kuma in Kubernetes mode you can create with Kuma's CRDs applied via kubectl.

Once the process is started, it waits for data-planes to connect, while at the same time accepting user-defined configuration to start creating Service Meshes and configuring the behavior of those meshes via Kuma .

When we look at a typical Kuma installation, at a higher level it works like this:

xDS APIs: Kuma implements the xDS APIs of Envoy in the kuma-cp application so that the Envoy DPs can connect to it and retrieve their configuration.