Clusternet

Overview

Clusternet is an open-source add-on for managing Kubernetes clusters across public cloud, private cloud, hybrid infrastructure, on-premises sites, and edge locations. It is aimed at teams already running Kubernetes that want a parent-cluster control point for a distributed fleet. The main reason to choose it is centralized multi-cluster operation without a paid plan; release-specific Kubernetes compatibility and operational setup requirements deserve attention before adoption.

Key features

From a parent cluster, operators can access managed clusters as though they were local. That can make fleet-wide administration more coherent, but it presumes familiarity with Kubernetes and with running a control cluster. Clusternet supports clusters from AWS, Google Cloud, Tencent Cloud, Alibaba Cloud, on-premises environments, certified distributions such as k3s, and edge deployments.

Application delivery covers Kubernetes-native resources, custom resource definitions, and Helm charts, including OCI-based charts. Cluster-specific configuration allows one application definition to be adapted for different members instead of copied into separate workflows. Automatic discovery and registration of clusters created by Cluster API is useful for environments where cluster provisioning is already automated.

Scheduling offers replication, static distribution based on cluster weight, and dynamic distribution based on cluster capacity. Replication suits consistent placement, weighted distribution gives deliberate control over allocation, and capacity-based scheduling is the better fit when available resources vary between clusters.

Network tunnels can be configured for clusters in VPC networks, at the edge, or behind a firewall. Submariner integration provides a documented route for securely connecting workloads across member clusters. Dynamic RBAC governs access to managed clusters, while the AppPusher feature gate can be disabled on an agent when child-cluster security concerns require a more restrictive deployment.

A kubectl plugin is installable through Krew or as a downloadable binary, and a client-go wrapper supports programmatic integration. Installation paths include Helm and manual deployment, with additional instructions for k3s. Linux builds cover amd64, arm64, ppc64le, s390x, 386, and arm.

Pricing

Clusternet (open source): free. This customer-managed plan is an open-source project with no paid plans or stated usage limits. It fits teams able to operate the control plane themselves and absorb infrastructure, upgrade, security, and support responsibilities. There is no lower-cost tier that trades away features, but there is also no vendor-managed option or published commercial support package in the plan.

Platforms

Clusternet is delivered as an API-oriented, Linux, self-hosted system. Supported environments include public cloud, private cloud, hybrid cloud, on-premises, and edge infrastructure. The introduction covers Kubernetes versions above v1.17.x, with compatibility tied to the specific Clusternet release. Versions below v0.13.0 have no guaranteed support for Kubernetes versions above v1.24.0, so version pairing should be part of deployment planning. A quick-start caveat is that several kind clusters with many pods can hit inotify resource limits and prevent pods from starting.

Who it's for

Clusternet fits platform teams and Kubernetes operators managing multiple clusters across mixed infrastructure, especially when centralized deployment, placement, and access controls matter. It is a strong match for organizations that want to keep control-plane management in-house and need Helm, CRD, and native-resource delivery across a fleet. It is less suitable for teams seeking a hosted management service, a graphical-first product, or an abstraction that removes day-to-day Kubernetes operations.

Pros and cons

Pros

• Broad fleet coverage: one model spans cloud, on-premises, hybrid, and edge clusters.
• Flexible placement: replication, weighted static distribution, and capacity-aware scheduling cover different deployment policies.
• Strong Kubernetes integration: native resources, CRDs, Helm, OCI charts, Cluster API discovery, kubectl, and client-go support established workflows.
• No license charge: the open-source plan costs nothing and states no usage limits.

Cons

• Self-hosted responsibility: customers operate the control plane and supporting infrastructure themselves.
• Compatibility requires care: support depends on the Clusternet release, with an explicit limitation for older versions and newer Kubernetes releases.
• Setup can expose host limits: large kind-based quick starts may encounter inotify resource exhaustion.
• Kubernetes expertise is essential: the parent-and-member-cluster model is powerful but not a simplified alternative to cluster operations.

Alternatives

Cluster API is a free, open-source Kubernetes project focused on cluster lifecycle management; choose it when provisioning and upgrading clusters is the priority rather than centralized application scheduling.

Kubermatic Kubernetes Platform offers a free Apache 2.0 Community Edition and a consumption-based Enterprise Edition; choose it when you want a broader platform with a commercial tier.

vCluster Platform has a free tier with unlimited virtual clusters up to 64 CPUs or 32 GPUs and one HA vCluster; choose it when virtualized clusters and its free-tier boundaries fit better than managing member clusters directly.

kOps is a free Kubernetes operations project; choose it for cluster creation and management rather than Clusternet's fleet-level application distribution.

Portainer provides a free Business Edition tier for up to three nodes and a paid Home & Student plan at $155 a year; choose it when a web-oriented management experience and a small free node allowance are more important.

Karmada is a free open-source Kubernetes management system; choose it when its multi-cluster orchestration approach better matches your architecture.

KubeSphere offers a free Community Edition as an enterprise-grade open-source Kubernetes container platform; choose it when you want that platform scope and interface.

openCenter has a free Community plan for builders and proofs of concept; choose it for that self-supported starting point.

Verdict

Choose Clusternet if your team already operates Kubernetes and needs no-cost, self-managed control over deployments, scheduling, networking, and access across a mixed cluster fleet. Its parent-cluster model and flexible placement policies are the central advantages. Look elsewhere if you need hosted operations, a simpler interface, or a Kubernetes compatibility path that does not require matching each Clusternet release to your cluster versions.