Architecture
Architecture Overview
Platform Component Map
CCP is a microservices-based Cloud Management Platform deployed on Kubernetes, organized into layered tiers from the user-facing portal down to the physical infrastructure it orchestrates.
| Layer | Components | Technology |
|---|---|---|
| Portal & API | Self-Service Console, Admin Console, REST API Gateway, WebSocket notifications | Microservices, Kafka, Redis, SocketIO |
| Identity & Access | Authentication, authorization, multi-tenant IAM, federation | Keycloak v24.0.5, OpenFGA, SAML 2.0 |
| Orchestration | Cluster lifecycle, workflow engine, provisioning logic | Cloud Orbiter (K8s), CCP (OpenStack), MaaS v3.4.9 |
| Storage | Block, object, file, archival storage management | NetApp v11.9.0, storage-plugin microservice |
| Networking | VPC, LB, VPN, firewall, NAT, DNS, public IP | OpenStack Neutron, Zscaler VPN, CheckPoint / Palo Alto, TCPWare |
| Monitoring | Operational metrics, dashboards, alarms, log analysis | Zabbix v7.4.3, Prometheus & Grafana v9.4.3 |
| Metering & Billing | Showback, quota management, usage tracking, licensing | orbiter-metering microservice |
| Database | Platform state storage, session management, caching | PostgreSQL 15.7, MongoDB 5.0.3, Redis 7.2.5/6.2.5 |
| Backup | Incremental and full backup, geo-replication | Veritas NetBackup v10.11.2 |
Core Microservices
CCP is composed of purpose-built microservices communicating through well-defined REST APIs, internal routing, and Kafka message queues.
| Microservice | Functional Description |
|---|---|
| console | Self-Service Portal UI — primary user-facing interface for cloud resource provisioning |
| admin-console | Admin Portal UI — platform operator interface for tenant, quota, and infrastructure management |
| platform | Core platform APIs — compute, volume, network, core-mgmt functionalities |
| admin-platform | Admin platform APIs — manage flavors, images, AZs, regions, and virtual resource constructs |
| auth | Keycloak authentication service — identity and multi-tenant IAM |
| orbiter-api | API server for Cloud Orbiter — exposes Kubernetes cluster management APIs |
| orbiter-controller | Backend engine for orbiter-api — runtime controller for Kubernetes orchestration |
| orbiter-auth | Authorization gateway for the Orbiter subsystem |
| orbiter-metering | Metering, showback, quota management, and licensing |
| orbiter-term | Terminal access — Kubernetes-based shell for clusters |
| core-mgmt | Project manager service — organizations, cells, user mappings |
| onboarding | User and organization onboarding workflows |
| workflow-controller | Workflow provider for internal CCP provisioning and lifecycle workflows |
| notification | Sends notifications to external platforms — SMS, email (SMTP), webhooks |
| socketio | Pushes real-time events and notifications to the console UI |
| storage-plugin | Storage capabilities integration — NetApp backend |
| baremetal-plugin | Bare metal server management — MaaS backend integration |
| observability-ui | Cluster observability UI — exposes CPU, RAM, and cluster metrics |
| frontend | Cluster management UI — K8s cluster registration, app deployment, container registry |
| ordr_mgmt | Pushes CRUD events externally for integration and audit purposes |
| OpenFGA | Authorization database — fine-grained RBAC enforcement |
| kafka | Internal messaging queue for inter-component communication |
| client-plugin | Client-specific custom flows and integration hooks |
| platform-celery / celery | Asynchronous task processing — multiple Celery workers for different task domains |
High Availability Architecture
CCP implements a multi-AZ high availability model designed for zero-downtime failover and continuous service delivery.
HA Design
- Active-Passive Dual Cluster Per Region: Cluster 1 (primary) in AZ1, Cluster 2 (standby) in AZ2. Automated GSLB-based failover with 2N+1 quorum cluster detection
- Kubernetes Control Plane Per AZ: Each availability zone hosts an independent Kubernetes control plane, ensuring cluster-level resilience
- Database HA:
- PostgreSQL: Logical and Streaming Replication between AZs
- MongoDB: Active-Active with change-stream replication
- Redis: Clustered session and cache replication
Backup Strategy
| Backup Type | Frequency | Retention |
|---|---|---|
| Incremental Backup | Every 30 minutes | 3 months, geo-replicated |
| Full Backup | Every 24 hours | 3 months, geo-replicated |
| Audit Logs | Continuous | Long-term retention per compliance requirement |
Backup operations are managed through Veritas NetBackup v10.11.2.
Resource Hierarchy
CCP organizes all resources in a three-level governance hierarchy:
- Tenant — Top-level boundary. One per customer account. All users, cells, and resources are scoped within a tenant. Quota enforced at this level.
- Cell — An isolated project or environment within a Tenant. Represents a department, workload environment, or service tier. Quota enforced independently.
- Resources — The cloud services consumed within a Cell: VMs, volumes, clusters, load balancers, databases, and more.
The BSS Portal is the primary identity store for tenant and user creation. CCP creates a unique Keycloak realm per tenant to ensure complete identity isolation.
Portal Architecture
CCP is accessed through two complementary portals with distinct personas:
| Portal | Audience | Primary Functions |
|---|---|---|
| Self-Service Console | End users, tenant administrators | Provision VMs, storage, networking, containers, databases; manage cells and users |
| Admin Console | Cloud administrators, platform operators | Manage tenants, quotas, catalogs, providers, infrastructure health, OpenStack environment |
Both portals share the same underlying CCP platform, ensuring consistent governance, RBAC enforcement, and resource management across all interactions.
Kubernetes Cluster Management — Cluster Controller and Agent
CCP manages Kubernetes clusters through a controller-agent architecture:
- Cluster Controller: Central entity connecting and orchestrating all customer Kubernetes clusters. Communicates with agents over port 8030/8040. Centralizes Kubernetes API and CLI access.
- Cluster Agent: Deployed on each target Kubernetes cluster. Initiates outbound connection to the Cluster Controller. Once the handshake completes, the Controller can issue commands and act as proxy for Kubernetes CLI and APIs.
This model allows CCP to manage Kubernetes clusters across multiple AZs and regions without requiring inbound firewall rules into each cluster.
Infrastructure Pre-Requisites
| Requirement | Detail |
|---|---|
| SSL Certificates | Wildcard SSL certificates for CCP hosting domain |
| Load Balancer | Load balancer with Virtual IPs (VIPs) per endpoint |
| DNS | DNS server with dynamic domain support |
| Storage | Kubernetes-compliant high IOPS storage for control plane |
| Connectivity | SMTP, NTP, and DNS server connectivity |
| Container Registry | Container registry access for platform image deployment |