Glossary
This page explains key terms and concepts to provide a clear understanding of the Klutch architecture and workflow.
API Binding
API Binding refers to the process of establishing a connection between an App Cluster and Klutch's APIs in the Control Plane cluster. This enables the App Clusters to interact with and leverage the resources and services managed by Klutch.
App Cluster
An App Cluster is a Kubernetes cluster that is used by application developers to consume Klutch Resources. For example, an App Cluster may host an application that utilizes a PostgreSQL database provisioned by Klutch. App Clusters are never the environment where the actual data services are provisioned.
Automation Backends
Automation backends are responsible for performing the actual resource provisioning, whether for virtual machines (VMs), containers, cloud infrastructure, or other resources, based on the configuration defined within Klutch. Automation backends in Klutch can include Service Brokers, Kubernetes Operators, and vendor-specific APIs (such as AWS, Azure, and GCP).
Control Plane Cluster
Klutch Control Plane Cluster is a Kubernetes cluster that oversees the entire multi-cluster ecosystem. It manages bidirectional synchronization of resource specifications, status, and additional information with App Clusters, while maintaining a catalog of available resources. This cluster provides system-wide observability and management capabilities.
Data Services
Data services refer to software or platform components responsible for managing, storing, processing, or transporting data, such as databases, message brokers, and similar technologies.
Konnector
Konnector is a lightweight Kubernetes deployment in the Application Cluster that acts as a bridge to the Control Plane Cluster. It creates the required Custom Resource Definitions (CRDs) locally and continuously synchronizes resource specifications and status updates between the two clusters.
Plan
A plan represents how a service can be consumed. Each service can have one or more plans. A plan defines the specific characteristics, limits, and configuration of the service, such as size and performance level. For example, a PostgreSQL service might offer a plan called single-nano, where single indicates a single-node deployment (not a cluster) and nano specifies a small allocation of CPU, memory, and storage.
Service
A high-level, abstract name for the data service resource being requested (e.g., a9s-postgresql15, aws-s3).
This field is used within the Service Instance Claim to identify the type of resource the developer intends to provision.
In some cases, this field, or a related field like serviceVersion, may include versioning or configuration variations
as part of the abstract request.
Service Binding
Service Bindings are based on the Open Service Broker API (OSBAPI), providing a standardized abstraction for connecting applications to services. When you create a service binding resource in your App Cluster, Klutch generates a secret containing all the necessary information for this connection. Your application can then use this secret to connect to the data service instance.
Klutch's Service Binding differs from the Service Binding Specification for Kubernetes. While both aim to streamline application connectivity to services, their approaches vary.