Codesphere Installation Options
Codesphere provides several installation options to meet different requirements for security, connectivity, and management preferences. The following scenarios outline the different deployment models available.
Scenario 1: Air-Gapped Installation
Key Characteristics: Fully disconnected. All Codesphere components, including K8s control plane, Codesphere Services, Codesphere Database, and Codesphere Management Console, run on customer-owned infrastructure within a single Kubernetes cluster. Ceph storage is local.
loading...Scenario 2A: Federated Installation (Shared DB)
Key Characteristics: Runs on customer-owned infrastructure across one or potentially multiple data centers. Each DC has its local K8s control plane. Codesphere Services run locally within each DC's K8s cluster. A Centralized Management Console and a Shared Codesphere Database (hosted by customer or in a trusted zone) enable unified user management and visibility across these federated installations. Ceph storage is always local to each DC.
loading...Scenario 2B: Federated Installation (Individual DBs)
Key Characteristics: Runs on customer-owned infrastructure across multiple data centers. Each DC has its local K8s control plane, local Codesphere Services (in "codesphere" namespace), and its own individual Codesphere Database. A Centralized Management Console provides a unified view by communicating with the K8s API and/or Codesphere Services in each DC. Ceph storage is always local to each DC. This provides more data isolation between DCs compared to a shared global database.
loading...Scenario 3A: Central Control Plane (Shared DB)
Key Characteristics:
- Customer provides K8s worker nodes and local Ceph storage in their Data Center(s).
- For each customer DC, Codesphere manages its K8s control plane (e.g., using k0smotron/Gardener).
- Codesphere Services run in the "codesphere" namespace on the customer's worker nodes, deployed and managed by the Codesphere-managed K8s control plane.
- A Centralized Management Console and a Shared Codesphere Database reside in a central location, providing unified management for the tenant.
Scenario 3B: Central Control Plane (Individual DBs)
Key Characteristics:
- Customer provides K8s worker nodes and local Ceph storage in their Data Center(s).
- For each customer DC, Codesphere manages its K8s control plane in the Codesphere Cloud.
- Codesphere Services run in the "codesphere" namespace on the customer's worker nodes, managed by the Codesphere-managed K8s control plane.
- Each DC has its own logical Codesphere Database instance (infrastructure may be managed by Codesphere, but data is siloed per DC).
- A Centralized Management Console in the Codesphere Cloud aggregates views by communicating with each managed K8s control plane and the respective Codesphere Services/DBs.
Codesphere Installation Scenarios: Pros & Cons
| Scenario | Pros | Cons |
|---|---|---|
| 1. Air-Gapped Installation | - Maximum Security & Data Sovereignty: Complete isolation from external networks. - Full Control: Customer manages all components and infrastructure. - No External Dependencies (Post-Deployment): Operates fully offline. | - High Operational Overhead (Relative): Customer responsible for all updates, patches, and K8s/DB/Codesphere management (though Codesphere's installer simplifies initial setup compared to DIY). - Manual Updates: New features/patches require manual import and deployment. |
| 2A. Federated Installation (Shared Global DB) | - Unified Management: Single console and shared DB for users, teams, and workspace metadata across multiple DCs (Console/DB customer-hosted). - Customer Control over K8s: Local K8s control planes and workers in each DC. - Data Locality (Ceph): Distributed file system (Ceph) is always local to each DC. - Centralized View: Easier to get an overview of all federated deployments. | - Shared DB Complexity: Can be a single point of failure or bottleneck if not architected for HA/DR by customer (Codesphere installer provides a streamlined setup). - Data Aggregation: Global user/team/workspace metadata in one customer-managed place might not suit all sovereignty needs if not properly secured. - WAN Dependency: Requires reliable connectivity between DCs and the customer-hosted central Management Console/DB for unified features. |
| 2B. Federated Installation (Individual DC DBs) | - Enhanced Data Isolation: Each DC has its own customer-managed Codesphere database, siloing user/team/workspace metadata per DC. - Customer Control over K8s & DBs: Local K8s control planes, workers, and databases. - Data Locality (Ceph): Local Ceph storage per DC. - Aggregated View (Optional Console): Customer-hosted Centralized Management Console can provide an overview by querying individual DCs. - Reduced WAN Dependency for Core DC Ops: DCs can operate independently; WAN needed primarily for optional central console view. | - Higher Management Complexity (Relative): More databases for customer to manage (though Codesphere installer simplifies setup). - Siloed User Management (Potentially): Cross-DC user/team operations might be more complex unless the Central Console handles synchronization effectively. - WAN Dependency (for Console): Customer-hosted Central Console needs to connect to each DC if used. |
| 3A. Managed Control Plane (Shared Global DB) | - Simplified K8s Operations: Codesphere manages K8s control planes for each customer DC. - Unified Management (Tenant): Centralized Management Console and shared DB for the tenant (hosted by Codesphere). - Customer Control over Workers: Customer manages K8s worker nodes and local Ceph storage. - Faster Onboarding: Potentially quicker setup of new K8s control planes. | - Dependency on Codesphere: K8s CP and Central Console/DB availability relies on Codesphere. - Shared DB Concerns (Tenant-Level): Similar to 2A but for tenant's global metadata (SPOF, potential bottleneck, managed by Codesphere). - Internet Connectivity: Robust connection required between customer DCs and Codesphere-hosted services. - Data Transfer (Metadata): Tenant's workspace metadata, user/team info resides in Codesphere-hosted DB. |
| 3B. Managed Control Plane (Individual DC DBs - Customer Local) | - Simplified K8s Operations: Codesphere manages K8s control planes. - Maximum Data Isolation (Metadata): Individual Codesphere DBs are local and customer-managed within each DC. - Customer Control over Workers & DBs: Customer manages K8s worker nodes, local Ceph storage, and local Codesphere DBs. - Aggregated View: Centralized Management Console (hosted by Codesphere) provides overview. | - Dependency on Codesphere for K8s CP: K8s CP availability relies on Codesphere. - Customer DB Responsibility (Relative): Customer responsible for management, HA/DR of local Codesphere DBs in each DC (Codesphere installer simplifies setup). - Internet Connectivity: Robust connection required for managed CPs and Central Console. - Data Transfer (For Console View): Aggregated view in Codesphere-hosted console requires data/API access to local services. |
Key Considerations for the Customer:
- Security & Sovereignty Needs: How strict are the requirements for data isolation and control, especially for metadata vs. workload data?
- Operational Capacity: What level of infrastructure and platform (K8s, DBs, Console) management can the customer's team handle, keeping in mind Codesphere's streamlined installer simplifies initial setup?
- Scalability & Multi-DC Requirements: Is there a need to manage workloads across multiple data centers with unified or isolated user bases/metadata?
- Connectivity: What are the constraints and reliability of WAN / internet connections, especially concerning optional vs. required components?
- Budget: Different models will have different implications for infrastructure, licensing, and operational costs.
- Ease of Use vs. Control: Where does the customer want to strike the balance for different components (K8s CP, Database, Management Console)?