Skip to main content
The Control Plane Kubernetes Operator enables you to manage Control Plane resources directly from your Kubernetes cluster using Custom Resource Definitions (CRDs). It provides a bridge between Kubernetes-native workflows and Control Plane infrastructure, making it ideal for GitOps deployments with tools like ArgoCD.

​
Overview

With the operator installed, you can:
  • Define resources as YAML - Create GVCs, workloads, secrets, and other resources as CRD manifests
  • Enable GitOps - Store your infrastructure in Git and deploy automatically with ArgoCD
  • Maintain consistency - Keep your Kubernetes and Control Plane resources in sync

​
Supported resources

The operator manages the following Control Plane resource types through CRDs:
ResourceDescription
gvcGlobal Virtual Cloud - groups workloads and defines deployment locations
workloadApplication containers running on Control Plane
identityGrants workloads access to cloud resources and private networks
secretEncrypted storage for credentials and sensitive data
policyGrants permissions to principals on target resources
volumesetPersistent storage with snapshots and auto-scaling
domainCustom domain mapping with TLS and geo-routing
cloudaccountCloud provider integrations (AWS, GCP, Azure, NGS)
agentSecure connectivity to private networks
groupMembership collection of users and service accounts
serviceaccountMachine identity for headless API operations
ipsetReserved public IP addresses for workloads
mk8sManaged Kubernetes clusters across cloud providers
auditctxTamper-proof audit trail for tracking actions

​
Key concepts

Control Plane CRDs differ from standard Kubernetes resources. Fields like org, gvc, and description are at the top level, not inside spec:
apiVersion: cpln.io/v1
kind: workload
metadata:
  name: my-workload
  namespace: default
org: my-org          # Top level, not in spec
gvc: my-gvc          # Top level, not in spec
description: My app  # Top level, not in spec
spec:
  type: serverless
  # ...
Always use the export feature to generate accurate manifests.
Secrets use native Kubernetes Secret objects with a special label:
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  labels:
    app.kubernetes.io/managed-by: cpln-operator  # Required
  annotations:
    cpln.io/org: my-org  # Required
data:
  payload: <base64-encoded-value>
The app.kubernetes.io/managed-by: cpln-operator label is required for the operator to manage the secret.
Deleting a CRD removes the corresponding resource from Control Plane. To prevent this, add the cpln.io/resource-policy: keep annotation:
metadata:
  name: production
  annotations:
    cpln.io/resource-policy: keep
Resources with this annotation remain in Control Plane even when deleted from Kubernetes.

​
Get started

Ready to set up the operator? Follow our step-by-step installation guide:

Install the Kubernetes Operator

Complete guide covering cert-manager installation, Helm deployment, authentication setup, and deploying your first resources

​
Exporting resources as CRDs

You don’t have to write CRD manifests from scratch. Control Plane provides built-in tools to export any resource in Kubernetes CRD format.
Export existing resources:Select any resource and click the Export dropdown in the upper right corner, then choose K8s CRD to download the manifest.Preview before creating:When creating a new resource, configure it using the UI, then click Preview and select K8s CRD. This generates the manifest without deploying the resource—perfect for storing in Git and deploying via ArgoCD.
This workflow is ideal for transitioning to GitOps: configure resources in the console UI, export them as CRDs, commit to Git, and let ArgoCD manage deployments.

​
Additional resources

GitHub Repository

Source code, CRD schemas, and issue tracking

cpln apply

Alternative: Deploy resources from YAML using the CLI