> For the complete documentation index, see [llms.txt](https://docs.platform9.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.platform9.com/private-cloud-director/kubernetes-clusters/control-plane-types.md).

# Control Plane Types

The control plane is the part of a Kubernetes cluster that manages the cluster state and serves the Kubernetes API. When you create a Kubernetes cluster with <code class="expression">space.vars.product\_name</code>, you choose how the cluster's control plane runs. Your worker nodes, where your applications actually run, are the same either way and only where the control plane is provisioned is different.

This article explains the differences between two control plane types - **Managed** and **Colocated** - and helps you pick the right one for your use case.

## Overview

A Kubernetes cluster comprises of a control plane (API server, controller-manager, scheduler, and the etcd datastore) and a set of worker nodes. In <code class="expression">space.vars.product\_name</code> you decide, per cluster, where the control plane lives:

* A **Managed control plane** runs as a service operated for you. You do not provision or maintain control plane components.
* A **Colocated control plane** runs its own services on *your* infrastructure, alongside the cluster's worker nodes.

Both cluster types run standard Kubernetes and are managed through the same interface. You can use them both simultaneously and choose the type for each cluster, based on your needs. In this guide you will learn how the two types differ, how your deployment model affects them, and when to choose each.

If you are new to Kubernetes, please see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/overview/components/) for in-depth concepts.

## Managed Control Plane

With a Managed control plane, the cluster's control plane runs as a lightweight service that is operated for you - on the Platform9-managed cloud (SaaS) or on your <code class="expression">space.vars.product\_name</code> management plane (self-hosted). You never provision or manage control plane nodes; they are managed for you.

Where a Managed control plane lives depends on your deployment model:

* **SaaS:** your Kubernetes control planes run on the Platform9-managed cloud. Platform9 operates that infrastructure for you.
* **Self-hosted:** your Kubernetes control planes run on your own <code class="expression">space.vars.product\_name</code> management plane, inside your data center or private cloud. See [Self-Hosted Deployments](https://docs.platform9.com/private-cloud-director/getting-started/self-hosted).

{% hint style="warning" %}
**Note**

With the SaaS deployment model, since a Managed control plane runs on the Platform9-managed cloud, it depends on continued network connectivity from your environment. If that connectivity is lost or unstable, the control plane and the worker nodes cannot reach each other: applications already running on the worker nodes keep running, but you cannot manage the cluster - scheduling, scaling, and API operations - until connectivity is restored. If your cluster operations cannot tolerate any loss of connectivity to the Platform9 cloud, use a Colocated control plane.
{% endhint %}

* **Fast to create.** Because there are no dedicated control plane nodes to boot, a new cluster's control plane is ready relatively quickly. This suits development, testing, CI pipelines, and any workflow where you frequently create and tear down clusters.
* **Efficient.** Managed control planes share common infrastructure, so each cluster carries a small footprint. You can run more clusters for the same capacity.
* **Fully managed.** The control plane components are operated for you. There is less for your team to size, patch, and maintain.

Keep in mind:

* Managed control planes share the same underlying infrastructure. For most workloads this is invisible, but it means clusters are not completely independent of one another or of the platform.
* A Managed control plane depends on connectivity between the worker nodes and the platform that hosts it (see the note above, which applies to the SaaS model).
* The infrastructure hosting the control planes grows as you add more managed clusters. In SaaS that is Platform9's responsibility; in self-hosted, your platform team plans management plane capacity centrally.

## Colocated Control Plane

With a Colocated control plane, each cluster gets its own dedicated control plane nodes - running on your own infrastructure alongside its worker nodes - with its own dedicated datastore. A Colocated control plane always runs on your own infrastructure, in both deployment models.

* **Strong isolation.** Each cluster's control plane runs on its own dedicated nodes, so another cluster's activity does not affect it.
* **Independent of the platform.** The control plane does not depend on connectivity to the Platform9 cloud.
* **Built for high availability.** A Colocated control plane runs multiple control plane nodes, so the cluster keeps running normally even if one of them is lost.

Keep in mind:

* Creating a cluster takes longer, because dedicated control plane nodes have to be provisioned and joined - the same way virtual machines take time to boot.
* Each cluster consumes dedicated compute capacity on your infrastructure for its control plane, in addition to its worker nodes. More clusters means more control plane nodes to run.

## Comparison of the Two Types

| Attribute                                         | Managed Control Plane                                                 | Colocated Control Plane                                       |
| ------------------------------------------------- | --------------------------------------------------------------------- | ------------------------------------------------------------- |
| Where the control plane runs                      | Platform9-managed cloud (SaaS) or your management plane (self-hosted) | Dedicated nodes on your infrastructure, with the worker nodes |
| Time to create a cluster                          | Fast - no control plane nodes to boot                                 | Longer - control plane nodes are provisioned and joined       |
| Per-cluster footprint                             | Small; shares common infrastructure                                   | Dedicated control plane nodes per cluster                     |
| Isolation between clusters                        | Shares underlying infrastructure                                      | Dedicated control plane per cluster                           |
| Dependence on Platform9 cloud connectivity (SaaS) | Yes - control plane is unreachable if connectivity is lost            | No - control plane runs locally                               |

## How to Decide

Ask these questions about the cluster you are about to create:

1. **Will I create and destroy this cluster often?** Fast-iteration and short-lived clusters lean toward a **Managed** control plane.
2. **Do you want to manage control plane capacity yourself, or leave it to the platform?** If you'd rather not provision or size control plane nodes, choose **Managed**.
3. **On the SaaS deployment model, connectivity to the Platform9 cloud may be lost.** If the control plane must stay accessible regardless, choose a **Colocated** control plane. This is not a consideration on self-hosted.
4. **Must this cluster survive platform maintenance untouched?** If yes, choose **Colocated**.

## Frequently Asked Questions

**Do my applications run differently on the two types?** No. Your workloads run on worker nodes, which behave the same regardless of control plane type. The choice affects how the control plane is hosted, not how your applications run.

**Can I change a cluster's control plane type later?** The control plane type is chosen when the cluster is created. To switch, create a new cluster of the desired type and migrate workloads to it.

**Is one type more reliable or faster than the other?** Both are designed for reliability. A Colocated control plane runs on dedicated nodes, so its responsiveness is consistent and not affected by other clusters. A Managed control plane shares infrastructure, which is efficient, though a busy neighboring cluster can have an effect on its responsiveness. The right choice depends on your isolation, predictability, and connectivity requirements.

**Which should I use if I am not sure?** Start with a **Managed** control plane - it gets you moving fastest and works for production too. Move to a **Colocated** control plane if you need dedicated control plane isolation or independence from Platform9 cloud connectivity.

## Next Steps

* [Kubernetes Overview](/private-cloud-director/kubernetes-clusters/k8s-overview.md)
* [Architecture and Technical Overview](/private-cloud-director/kubernetes-clusters/architecture-and-technical-overview.md)
* [Getting Started with Kubernetes in PCD](/private-cloud-director/kubernetes-clusters/getting-started-with-kubernetes-in-pcd.md)
* [Pre-requisites](/private-cloud-director/kubernetes-clusters/k8s-pre-requisites.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.platform9.com/private-cloud-director/kubernetes-clusters/control-plane-types.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.