Fleet Architecture

In Development (Q4 2026)

This feature is currently in development. Architecture described here is subject to change.

Purpose: For platform engineers and architects, explains the hub-spoke architecture that underpins openCenter fleet management.

Hub-Spoke Model

Component	Location	Role
Fleet Controller	Hub cluster	Orchestrates fleet operations, manages cluster inventory
Policy Distributor	Hub cluster	Pushes policies and configurations to spoke clusters
Fleet Agent	Each spoke cluster	Reports status, executes fleet operations locally
Fleet Dashboard	Hub cluster (Headlamp plugin)	Unified fleet visibility

Hub Cluster Requirements

The hub cluster runs the openCenter platform foundation plus fleet management services:

• Dedicated management cluster (recommended) or co-located with a workload cluster (small fleets)
• Minimum 3 control-plane nodes for HA
• Network connectivity to all spoke clusters (agent initiates outbound connection)

Agent Communication

Fleet agents run as a Deployment in each spoke cluster and:

• Initiate outbound HTTPS connections to the hub (no inbound ports required)
• Report cluster health, version, resource utilization, and drift status
• Pull policy updates and configuration changes from hub
• Execute fleet operations (upgrades, policy enforcement) locally

Cluster Grouping

Clusters are organized using labels and selectors:

apiVersion: fleet.opencenter.cloud/v1alpha1
kind: ClusterGroup
metadata:
  name: production-us-east
spec:
  selector:
    matchLabels:
      environment: production
      region: us-east

Groups enable targeted operations — upgrade production-us-east first, then production-eu-west.

Security Model

• Agent authentication via short-lived tokens (rotated every 24h)
• Hub-to-spoke communication encrypted with mTLS
• Fleet operations are GitOps-backed — hub commits to spoke GitOps repos
• No direct kubectl access from hub to spoke clusters