Forem: Sonali

Demystifying Kuma: A getting started guide

Sonali — Thu, 03 Aug 2023 12:38:11 +0000

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.

The ABC's of a Service Mesh

Sonali — Wed, 28 Jun 2023 06:33:46 +0000

When building software, code can be structured as a single large program (monolith) or multiple smaller programs (microservices). While it is true that many organizations are migrating from monolith to microservices to leverage the flexibility and scalability microservices offer, it gets difficult to manage them as their number grows. Challenges arise in tracking, latency control, optimizing load between replicas of a service, service-to-service communication security, and maintaining resilience. All these features can be encoded with the service giving an opportunity for vulnerabilities & mixing of business logic with management logic.

Implementing a reliable service discovery mechanism and maintaining an up-to-date service registry becomes difficult. Adopting Kubernetes resolves some deployment issues, but runtime issues persist due to tight coupling with the application. Testing new features and making changes while maintaining infrastructure security becomes challenging.

Service mesh fills this gap and helps build a secure infrastructure with the optimized usage of the service by adding reliability, observability, and security features across all services uniformly without any application code change. Read more in this blog post where we will understand the concept of the service mesh, its components, its functionality, real-world problems that service mesh solves and how it can be helpful in Kubernetes and on bare metals.

Error-proof Kubernetes deployment with Monokle

Sonali — Mon, 17 Apr 2023 10:28:41 +0000

Have you ever wished you could error-proof your Kubernetes application before deployment, without the hassle of using multiple tools? Monokle might just be the solution you've been looking for. In a recent blog post, the Monokle team demonstrates how their tool can help you deploy a modern, highly available, scalable, and reliable e-commerce application while keeping it secure. With Monokle's built-in validation support, resource preview, and real-time visibility of resource utilization, you can ensure that your application's desired state is maintained at all times. By shifting left, you can reduce the time it takes to deploy a new application and minimize the need for multiple tries. Don't let complexity and maintainability hold you back from deploying a top-quality application.

Pre-deployment error-proofing with Monokle

Monokle is a lifecycle manager for Kubernetes manifests, designed to help cloud-native developers create, validate, version control, preview, and understand the behavior of their applications and infrastructure before deployment. The tool sits between traditional developer IDEs and operational cluster dashboards and provides a holistic view of the cluster, including built-in validation support to ensure application security. Monokle also allows for resource preview pre-deployment for Helm or Kustomize deployments, real-time visibility of resource utilization post-deployment, and maintenance of the desired state of the application at all times. Overall, Monokle aims to simplify the Kubernetes management process for developers and reduce the chances of errors.

Monokle Features

Monokle helps in many steps of the process of managing the application configuration and thus has a lot of features. We have designed them to improve productivity & ease of working with Kubernetes. We will provide an overview of these features along with how developers can use them to error-proof Kubernetes deployments. All the YAML files and charts used in this blog post can be found in this repository.

Validation: Standardised codebase

The first step to error-proof a Kubernetes application before deployment is to validate your resources. Traditionally, that would imply separate plugins and integrations into an IDE. However, the restrictions included in the IDE limit what is available in many cases, and the workflow is far from perfect.

YAML uses indentation with white spaces for the structuring and nesting. A single syntax issue will fail YAML parsing. Spotting these errors can be a painful activity when your codebase grows in size. Monokle helps with highlighting these syntax errors before deployment.

Let’s see how you can validate YAML:

YAML syntax validation: A detailed view of validation errors corresponding to YAML syntax for each resource is displayed in the navigator. Hover over to the error sign to view the list. Select a resource from the list to view the complete error message. Make use of the form editor to apply a fix.

Developers are aware that the manifests need to adhere to the Kubernetes schema. Using the kubectl dry-run flag developers can validate resources but it is complex to understand. Any misconfiguration causes vulnerability leading to the application being open for attacks. Monokle helps identify Kubernetes schema errors before deployment as shown below.

Kubernetes schema validation: A warning sign includes Kubernetes schema errors and broken links. It validates that your manifests have the correct properties/value defined in the schema for their resource type.

To ensure security and standard infrastructure development, developers enforce policies. This helps in defining the behavior of the application. Instead of hard-coding these policies in the code, it is preferred to query Open Policy Agent(OPA) and verify the adherence.

To do that, traditionally you would need to use a separate tool but with Monokle’s built-in support to enable OPA policies, you can validate resources during development.

OPA: Monokle displays the list of pre-defined, standardized OPA policies that can be enabled. This ensures that your infrastructure code follows standard practices to secure from vulnerabilities. Leverage OPA security practices with Monokle.

In case you require custom rules to be enforced, Monokle has extremely powerful functionality to write custom rules in Monokle CLI and Monokle Cloud ecosystem. It supports typescript and allows you to create/debug and share custom validators.

Monokle’s built-in validation support helps in checking YAML syntax, adhering to Kubernetes schema, and applying Open Policy Agent(OPA) policies in real-time. In this way, developers can validate the complete infrastructure, get rid of vulnerabilities, and follow Kubernetes' best practices. The chances of a failed deployment due to misconfiguration will be reduced drastically.

Read Error-proof Kubernetes deployment with Monokle blog post to learn how using Monokle will help teams to shift left and focus on pre-deployment workflows instead of picking up the pieces (and bugs!) after deployment.