Skip to main content

Architecture

Architecture Overview​

Cloud Orbiter — Platform ArchitectureUniversal Application Control Plane · Zero-Trust · Multi-CloudUSER INTERFACE & APIManagement DashboardREST API GatewayCLI / kubectl ProxyWebSocket NotificationsIDENTITY & ACCESS MANAGEMENTKeycloak · OpenID ConnectRBAC · Multi-TenantSSO: Okta · Google · MicrosoftSession ManagementCLUSTER ORCHESTRATIONCKP ClustersCoredge K8sAWS EKSPublic CloudAzure AKSPublic CloudGoogle GKEPublic CloudEdge ClustersRemote SitesBrownfieldPLATFORM SERVICESApp LifecycleHelm · GitOpsObservabilityPrometheus · LogsBackup & RestoreVelero · S3VM ManagementKubeVirtTest SuitesPre-packagedAdd-onsPrometheus · VeleroNotif-icationsCONNECTIVITY MODEL (OUTBOUND AGENT)Cloud Orbiter Control Plane←→NAT Gateway / Internet←→Orbiter Agent (Target Cluster)outbound onlyNo inbound firewall rules required · Supports private, edge, and public cloud clusters

Platform Component Model​

Cloud Orbiter is organized into four functional layers:

LayerComponentsTechnology
User Interface & APIManagement Dashboard, REST API, kubectl Proxy, WebSocket NotificationsReact, REST, WebSocket
Identity & AccessAuthentication, RBAC, SSO federation, session managementKeycloak, OpenID Connect, Okta, Google, Microsoft
Cluster OrchestrationCKP, EKS, AKS, GKE, Edge, Brownfield cluster managementKubernetes API, CKP, Cloud Provider SDKs
Platform ServicesApp Lifecycle, Observability, Backup, VMs, Test Suites, Add-onsHelm, Prometheus, Velero, KubeVirt

Connectivity Model​

Cloud Orbiter uses an outbound agent model for cluster connectivity:

ComponentRole
Cloud Orbiter Control PlaneCentral management engine — hosts all APIs, dashboards, and orchestration logic
Orbiter AgentLightweight agent deployed on each target cluster; initiates outbound connection to control plane
NAT GatewayTranslates private network addresses for internet-bound agent connections
kubectl ProxyControl plane acts as proxy for all Kubernetes CLI and API access to target clusters

This model means:

  • No inbound firewall rules are required on target clusters
  • Clusters behind strict enterprise firewalls, private networks, and edge sites can all be managed
  • Cluster access is always mediated through the control plane — enabling centralized audit logging

Tenant & Project Isolation​

Cloud Orbiter
└── Tenant (Organization)
    ├── Project A (Team / Application)
    │   ├── Clusters
    │   ├── Applications
    │   └── Users & Roles
    └── Project B
        ├── Clusters
        ├── Applications
        └── Users & Roles
  • Tenant — Top-level organizational boundary. Fully isolated identity realm per tenant.
  • Project — Logical grouping within a tenant. Resources, clusters, and applications are scoped to a project.
  • Users & Groups — Assigned to projects with explicit roles (Tenant Admin, Project Admin, Default User).

Add-On Architecture​

Cloud Orbiter extends cluster capabilities through pre-configured, tested Add-Ons:

Add-OnPurpose
PrometheusMetrics collection and alerting for cluster observability
VeleroNamespace backup, restore, disaster recovery, and cluster migration
KubeVirtVirtual machine lifecycle management on Kubernetes nodes

Add-Ons are installed and uninstalled directly from the cluster dashboard without manual Helm commands or YAML editing.