Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,9 +29,8 @@ KubeFlex implements a sophisticated multi-tenant architecture that separates con
### Supported Control Plane Types

- **k8s**: Lightweight Kubernetes API server (~350MB) with essential controllers, using shared Postgres via Kine
- **vcluster**: Full virtual clusters based on the vCluster project, sharing host cluster worker nodes
- **vcluster**: Full virtual clusters based on the vCluster project, sharing host cluster worker nodes. Note: OCM-style/multi-cluster federation workflows are supported via integrations running on vcluster when required.
- **host**: The hosting cluster itself exposed as a control plane for management scenarios
- **ocm**: Open Cluster Management control plane for multi-cluster federation scenarios
- **external**: Import existing external clusters under KubeFlex management (roadmap)

For detailed architecture information, see the [Architecture Guide](docs/architecture.md).
Expand Down
5 changes: 1 addition & 4 deletions docs/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,11 +32,8 @@ plane can run pods using worker nodes of the hosting cluster.
- *external*: an external cluster that is imported as a control plane (this
is in the roadmap but not yet implemented)

- *ocm*: a control plane that uses the
[multicluster-controlplane project](https://github.com/open-cluster-management-io/multicluster-controlplane)
for managing multiple clusters.
- (Deprecated in docs) Traditional OCM-specific control plane references have been removed from the primary supported list. OCM-style multi-cluster/federation workflows are supported via integrations running on `vcluster` instances when needed. See the `vcluster` type below for details.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The vcluster type is described above, not below.

Copy link
Contributor

@MikeSpreitzer MikeSpreitzer Dec 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The deprecation is not just in the documentation. This type is deprecated, period.


When using KubeFlex, users interact with the API server
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why delete this line?

of the hosting cluster to create or delete control planes.
KubeFlex defines a ControlPlane CRD that represents a Control Plane.

Expand Down
5 changes: 2 additions & 3 deletions docs/multi-tenancy.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,8 +28,7 @@ As organizations scale their Kubernetes adoption, they face a fundamental questi

**What KubeFlex Integrates With:**
- **KubeVirt**: For VM-based worker nodes providing complete tenant isolation
- **vCluster**: As a control plane type for lightweight virtual clusters
- **Open Cluster Management**: For multi-cluster scenarios and edge deployments
- **vCluster**: As a control plane type for lightweight virtual clusters; vcluster instances can host integrations for multi-cluster/federation workflows
- **Standard Kubernetes Storage**: CSI drivers, persistent volumes, and storage classes

**Integration Boundaries:**
Expand All @@ -54,7 +53,7 @@ KubeFlex focuses on control plane management and provides integration points rat

### 4. Edge and Multi-Cluster Management
- **Challenge**: Manage multiple edge locations with varying connectivity
- **Solution**: Use `ocm` type control planes for edge cluster federation
- **Solution**: Use `vcluster` instances (and integrations running on them) for edge cluster federation and OCM-style multi-cluster workflows
- **Benefit**: Centralized management with distributed execution

## Advanced Configuration
Expand Down
37 changes: 16 additions & 21 deletions docs/users.md
Original file line number Diff line number Diff line change
Expand Up @@ -341,27 +341,29 @@ the URL for the server as `https://kubeflex-control-plane:<nodeport>`


## Control Plane Types

At this time KubFlex supports the following control plane types:

- k8s: this is the stock Kube API server with a subset of controllers running in the controller manager.
- ocm: this is the [Open Cluster Management Multicluster Control Plane](https://github.com/open-cluster-management-io/multicluster-controlplane), which provides a basic set of capabilities such as
clusters registration and support for the [`ManifestWork` API](https://open-cluster-management.io/concepts/manifestwork/).
- vcluster: this is based on the [vcluster project](https://www.vcluster.com) and provides the ability to create pods in the hosting namespace of the hosting cluster.
- host: this control plane type exposes the underlying hosting cluster with the same control plane abstraction
used by the other control plane types.
- external: this control plane type represents an existing cluster that was not created by KubeFlex and is not the KubeFlex hosting cluster.
At this time KubeFlex focuses documentation on the following supported control plane types:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the existing wording ("At this time KubFlex supports the following control plane types") is just fine. We are removing support for the ocm type.


- k8s: the stock Kubernetes API server with a subset of controllers active in the controller manager.
- vcluster: virtual clusters based on the vCluster project that run on the hosting cluster; they can run pods and host integrations. Note: OCM-style multi-cluster/federation workflows (for example ManifestWork-like functionality) are supported by deploying integrations to `vcluster` instances when required.
- host: exposes the underlying hosting cluster as a control plane using the same abstraction as other types.
- external: represents an existing cluster that was not created by KubeFlex and is managed by adoption workflows.
- k8s: this is the stock Kube API server with a subset of controllers running in the controller manager.
- vcluster: this is based on the [vcluster project](https://www.vcluster.com) and provides the ability to create pods in the hosting namespace of the hosting cluster. Note: OCM-style multi-cluster federation and ManifestWork-like workflows are supported via integrations deployed to `vcluster` instances when needed.
- host: this control plane type exposes the underlying hosting cluster with the same control plane abstraction
used by the other control plane types.
- external: this control plane type represents an existing cluster that was not created by KubeFlex and is not the KubeFlex hosting cluster.
Comment on lines +350 to +354
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a copy of the material just above it.


## Control Plane Backends

KubeFlex roadmap aims to provide different types of backends: shared, dedicated, and for
each type the ability to choose if etcd or sql. At this time only the following
combinations are supported based on control plane type:
each type the ability to choose etcd or SQL backends. At this time the following
combinations are supported:

- k8s: shared postgresql
- ocm: dedicated etcd
- k8s: shared PostgreSQL
- vcluster: dedicated sqlite

Note: OCM-specific backends are no longer emphasized in the primary docs; OCM-style federation scenarios should be implemented via integrations running on `vcluster` instances.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"OCM-specific backends are no longer emphasized in the primary docs" is not strong enough. They are not just "no longer emphasized in the primary docs". This PR should be removing them from all the user-facing documentation, in anticipation of removing them from the implementation.


## Creating with a selected control plane type

If you are using the kflex CLI, you can use the flag `--type` or `-t` to select a particular
Expand All @@ -372,13 +374,6 @@ To create a control plane of type `vcluster` run the command:
```shell
kflex create cp2 --type vcluster
```

To create a control plane of type `ocm` run the command:

```shell
kflex create cp3 --type ocm
```

To create a control plane of type `host` run the command:

```shell
Expand Down