RFC: Decoupled Containerization Strategy & Kubernetes Support
I am requesting a roadmap shift to release ApisCP as a Dockerfile/OCI Image to enable horizontal scaling and high availability via Kubernetes.
Currently, ApisCP explicitly does not support containers (like Docker) because it manages its own isolation via BoxFS and OverlayFS. To scale horizontally and maximize modern virtualization, we are proposing a transition to Kubernetes (k8s) orchestration.
1. Technical Justification: Beyond the Monolith
1.a. Horizontal Scalability: Moving from vertical scaling (adding RAM/CPU to one node) to horizontal scaling (spinning up multiple pod instances) to handle traffic spikes.
1.b. Infrastructure Portability: A containerized ApisCP can run identically across bare metal, multi-cloud (AWS/Azure/GCP), and hybrid environments without dependency hell.
1.c. Operational Resilience: Utilizing k8s self-healing to automatically replace failed panel or service components, reducing manual sysadmin intervention.
NOTE: Azure support is a requirement for many to target Enterprises and large Implementations with heavy regulations.
2. Proposed Architectural Evolution
2.a. Stateless Controller: Decouple the panel core from the persistent data. The ApisCP Pod should handle API requests, while customer data resides on Kubernetes Persistent Volumes (PVs) via CSI (Container Storage Interface).
2.b. Headless Mode for Micro-Services: Allow offloading specific roles (DNS, Mail, DB) to specialized containers or managed cloud services while ApisCP acts as the centralized orchestrator.
2.c. BoxFS over Container Storage: Explore using CSI-based OverlayFS so the panel’s superior security isolation can live within the k8s namespace.
3. Business Value
3.a. Cost Efficiency: “Pay-per-use” resource allocation where containers only consume what they need, rather than reserving massive VM overhead.
3.b. Future-Proofing: Adopting the Enterprise Standard (k8s) for infrastructure management, allowing ApisCP to compete with “cloud-native” hosting platforms.
3.c. Investment Analytics: Proving that if 1 site scales on k8s, $N$ sites will scale identically with zero performance degradation.
3.d. Optimization for Proof of Work: Defining the optimal sequence for containerizing the current monolithic services (e.g., migrating the Job Runner before the API).