GitOps with MCP Connector

Upbound’s Managed Control Plane Connector (MCP Connector) connects application clusters running outside of Upbound to your managed control planes running in Upbound. You can do GitOps flows and use Git to drive interactions with your MCPs.

When you install Crossplane in your Kubernetes cluster, all claim APIs you define via CompositeResourceDefinitions are available alongside workload APIs like Pod. With Upbound, Crossplane doesn’t run in your Kubernetes app clusters. Crossplane runs inside Upbound. The MCP Connector allows you to make all the claim APIs available in as many Kubernetes clusters as you want. This provides the same experience as locally installed Crossplane.

Illustration of MCP Connector

Managed control plane connector operations

The MCP Connector creates an APIService resource in your Kubernetes cluster for every claim API in your control plane. Your Kubernetes cluster sends every request for the claim API to the MCP Connector. The MCP Connector makes the request to the Upbound control plane it’s connected to.

The claim APIs are available in your Kubernetes cluster just like all native Kubernetes API.

Connecting to managed control planes

Log in with the up CLI

1up login

Connect your cluster to a namespace in an Upbound Control Plane with up controlplane connect <control plane name> <namespace>. This command creates a user token and installs the MCP Connector to your cluster.

Note
Note that you need to supply your organization name with --account if it wasn’t specified during login.
1up controlplane connect my-control-plane my-app-ns-1 --account my-org-name

The Claim APIs are now visible in the cluster with kubectl api-resources.

1kubectl api-resources

Example usage

This example creates a control plane using Configuration EKS. KubernetesCluster is available as a claim API in your control plane. The following is an example object you can create in your control plane.

 1apiVersion: k8s.starter.org/v1alpha1
 2kind: KubernetesCluster
 3metadata:
 4  name: my-cluster
 5  namespace: default
 6spec:
 7  id: my-cluster
 8  parameters:
 9    nodes:
10      count: 3
11      size: small
12    services:
13      operators:
14        prometheus:
15          version: "34.5.1"
16  writeConnectionSecretToRef:
17    name: my-cluster-kubeconfig

After connecting your Kubernetes cluster to the MCP, you can create the KubernetesCluster object in your Kubernetes cluster. Although your local cluster has an Object, the actual resources is in your control plane inside Upbound.

1# Applying the claim YAML above.
2# kubectl is set up to talk with your Kubernetes cluster.
3kubectl apply -f claim.yaml
Claim in cluster

Once Kubernetes creates the object, view the console to see your object.

Claim by connector in console

You can interact with the object through your cluster just as if it lives in your cluster.

Note
Upbound uses the Kubernetes API Aggregation Layer to allow tools to interact with the remote object as if it was local.

Multi-cluster architectures

Claims are store in a unique namespace in the Upbound Managed Control Plane. Every cluster creates a new MCP namespace.

Multi-cluster architecture with managed control plane connector

There’s no limit on the number of clusters connected to a single control plane. Control plane operators can see all their infrastructure in a central control plane.

Without using Managed Control Planes and MCP Connector, users have to install Crossplane and providers for cluster. Each cluster requires configuration for providers with necessary credentials. With a single control plane where multiple clusters connected through Upbound tokens, you don’t need to give out any cloud credentials to the clusters.