The concept of service mesh emerged in response to the increasing popularity of cloud-native environments, microservices architecture, and Kubernetes. While Kubernetes addressed deployment challenges, communication between microservices remained a source of unreliability. This led to the rise of service mesh. However, existing service mesh solutions were often difficult to scale, configure, and manage. In response to this, Kong developed an open-source service mesh tool called Kuma.
Kuma is designed as an open-source service mesh for Kubernetes, VM, and bare metal environments. It offers horizontal scalability support and is compatible with multi-zone, multi-cluster, and multi-cloud setups. Kuma is enterprise-ready and supports multiple individual meshes, reducing the operating costs of supporting the entire organization.
The architecture of Kuma consists of two main components:
Data Plane: Each service in the mesh is deployed with a sidecar proxy to handle the traffic. Kuma is built on top of the Envoy proxy, and each replica of the service is configured with a data plane proxy (DPP). The DPP is composed of two main components: the Dataplane entity and the kuma-dp binary, which spawns two subprocesses: envoy and core-dns.
Control Plane: The control plane is responsible for managing multiple data plane proxies. It helps configure the data plane proxies and manages the traffic going through the mesh. Kuma acts as the control plane and is shipped as a kuma-cp binary in a mesh. It implements the Envoy xDS APIs to provide configurations to the data plane proxies. Kuma also offers a CLI tool called kumactl to interact with the control plane.
Kuma supports both Kubernetes-native and universal infrastructure modes. In Kubernetes mode, Kuma uses the Kubernetes API server as the data store to manage policies and configurations. In universal mode, PostgreSQL serves as the data store for the control plane.
To implement Kuma, you set up the control plane using the kumactl CLI tool. Kuma supports standalone and multizone deployment topologies.
Once the control plane is set up, the kuma-injector can be used to to inject sidecar to each service. Each pod initializes with kuma-init to set up default transparent proxying, and the kuma-dp executable runs on each sidecar to the service. The control plane then provides real-time configurations and policies to the data plane proxies, which enforce them on service-to-service communication in the network.
Once the setup is ready, you can make use of the Kuma GUI to view details of the mesh.
We can enable policies like mTLS, circuit breaker, rate limiting, traffic routing, fault injection and more using Kuma.
Kuma provides better observability of service mesh through integration with Prometheus, Grafana, Loki, and Jaeger. It exposes metrics in Prometheus format and allows monitoring of every proxy in the mesh and the application. It offers Grafana dashboards for visualization and Jaeger for tracing application response times.
Overall, Kuma simplifies service mesh deployment and management, provides observability, and supports various deployment topologies to accommodate different infrastructure setups.
Already interested? Enable service mesh using step-by-step guide to getting started with Kuma.
Top comments (0)