Skip to main content

Getting started with Klutch: Key terms and commands for developers

· 5 min read
by the Klutch community

Getting started with Klutch: Key terms and commands for developers

If you're building applications in Kubernetes and using Klutch to provision and connect to data services, this post will help you get oriented fast. Whether you're debugging a service binding or deploying a new proxy resource, it pays to understand the terminology, and to know the kubectl commands that'll save you time.

Here's a quick glossary of Klutch-specific concepts followed by some practical commands that developers can use in their day-to-day workflow.

Core concepts in Klutch​

Application Cluster (App Cluster)​

This is where your applications live. It's the Kubernetes cluster used by app developers to consume resources provisioned by Klutch. For example, your app cluster might house a microservice that connects to a PostgreSQL database and an S3-compatible bucket; both set up via Klutch.

Important: App clusters are not where data services are actually running. They're consumers, not hosts.

Control Plane Cluster​

Think of this as the brains of the operation. The Control Plane Cluster manages:

  • Resource definitions
  • System-wide status and metadata
  • Cross-cluster synchronization

It runs Crossplane and its providers, enabling Klutch to work across multiple clouds or on-prem environments. This is where Klutch keeps the catalog of available resources and manages the lifecycle of services across app clusters.

Proxy Claim​

A Proxy Claim is a Kubernetes Custom Resource (CR) you create in your app cluster. It acts as a stand-in for a real resource request, like asking for a PostgreSQL instance without having to know all the details.

The Control Plane sees that request, provisions the actual service through an Automation Backend, and syncs everything back to your app cluster.

Service Binding​

Once your resource (e.g., a database) is provisioned, your application needs to connect to it. A Service Binding resource automates that connection by:

  • Creating a Kubernetes Secret with the necessary credentials
  • Making it available to your app

Note: While Klutch uses the term Service Binding, it's different from the Service Binding Specification for Kubernetes. The goal is similar, but the implementation differs.

API Binding​

This is what lets your App Cluster talk to Klutch. An API Binding connects your cluster to the Klutch APIs running in the Control Plane. Without it, no resources can be provisioned or managed.

Data Services​

These are the actual systems your app needs—like PostgreSQL, RabbitMQ, MinIO, or Redis. Klutch makes it easy to provision and manage them across clouds or on-prem, no matter whether they run in VMs or containers.

Automation Backends​

These do the heavy lifting. Once a Proxy Claim is made, an Automation Backend actually provisions the resource. Backends can include:

  • Service Brokers
  • Kubernetes Operators
  • Vendor APIs (e.g., AWS RDS, Azure Blob Storage, etc.)

Klutch abstracts this complexity so you can focus on writing apps.

Essential Kubernetes + Klutch commands for developers​

These kubectl commands help you interact with Klutch-managed resources in your App Cluster. Most are standard Kubernetes operations (nothing custom), but knowing what to look for makes all the difference.

1. Check if Klutch Is Configured in Your App Cluster (Optional)​

kubectl get deployments -n <namespace>

Look for a deployment called konnector. If it's there, your App Cluster is connected to the Control Plane and ready to use Klutch.

2. List Available Custom Resource Definitions (Optional)​

kubectl get crds

This shows all CRDs in the cluster. You should see the CRDs for Klutch Proxy Resources if everything is set up.

3. View the Schema of a Specific CRD (Optional)​

To inspect what fields are available for a given CRD:

Quick summary:

kubectl explain <crd-name>

Full structure:

kubectl get crd <crd-name> -o yaml

4. Deploy a Proxy Resource with YAML​

Once you have a manifest ready:

kubectl apply -f <manifest>.yaml

This creates the resource in your App Cluster and triggers provisioning in the Control Plane.

5. Inspect Proxy Resource Status​

To list all Proxy Resources of a certain type:

kubectl get <proxy-resource-type>

For details on a specific resource:

kubectl describe <proxy-resource-type> <resource-name>

6. Update a Proxy Resource​

Change the YAML and re-apply:

kubectl apply -f updated-proxy-resource.yaml

7. Delete a Proxy Resource​

To delete the resource and clean up associated infrastructure:

kubectl delete <proxy-resource-type> <resource-name>

This will trigger deletion in the backend (e.g., cloud provider, service broker).

8. Enable Klutch in the App Cluster (Optional)​

If Klutch isn't set up in your App Cluster yet, reach out to your Platform Team or follow the setup guide.

Final thoughts​

Klutch was built to remove friction between Kubernetes developers and the infrastructure they need to ship features faster. With a few key concepts and kubectl commands under your belt, you can easily request, connect, and manage the data services your app depends on without needing to know how the infrastructure magic happens behind the scenes.

Have questions or want to learn more? Reach out or check out our docs for deeper technical walkthroughs.