Orbit Plane and Related Components
By Raj Marni. March 23, 2025. Revised. Version: 0.1.02
This document presents Layer 1 expanded explanation of the Orbit Plane and some of its key components, providing details about each component (C4, C8, C12, C16, C20, C24, C28, and C32). This is Layer One technical documentation and explains how each of these components fits into the bigger architectural picture.
The Orbit Plane is the backbone of this architecture, ensuring that image building (C4), portal-driven uploads (C8), chart generation (C12, C24), data storage (C16, C20, C32), and Kustomize-based manifest creation (C28) all happen in a cohesive, consistent manner. By centralizing these long-lived services in a static plane, the system can manage and monitor ephemeral clusters (in the Cluster Plane) with minimal disruption and maximum flexibility.
1. k8or Orbit Plane
The Orbit Plane is a persistent, central management layer that remains operational at all times. It orchestrates, manages, and monitors the lifecycle of ephemeral Kubernetes clusters (in the Cluster Plane) and houses critical, long-lived services. Below we describe few Orbit Plane component in detail, referencing to their IDs (C4, C8, etc.).
2. Component Overviews
2.1 C4 – Docker Image Build Process
Purpose: Represents the process through which a developer builds Docker images.
Typical Flow:
Developer writes code locally or in a CI system.
Code is compiled, tested, and packaged into a Docker image.
The resulting image is tagged and pushed to a container registry such as Docker Hub.
Orbit Plane Role:
While the actual build may happen in a CI tool, C4 is the logical place that coordinates the build pipeline and can be intergrated into Developer build process.
This is part of the overall pipeline that eventually leads to uploading images and generating Helm charts.
2.2 C8 – k8or Portal
Purpose: A front-end UI ( an Angular web application) where developers interact with Orbit Plane.
Functionality:
Accepts user-uploaded images (or references to images built in C4) along with metadata (e.g., environment, version, user information, configuration).
Triggers backend workflows—like chart generation or storing metadata—by calling other components (C12, C16, etc.).
Orbit Plane Role:
Serves as the gateway for user actions, centralizing how developers push images and define the parameters for subsequent steps (chart creation, environment deployment, etc.).
2.3 C12 – Manifestor
Purpose: Responsible for creating Helm chart manifest files for the uploaded images.
Typical Flow:
Receives a request from C8 (Portal) indicating a new image and any relevant config or deployment requirements.
Generates a Helm chart that defines how this image should be deployed (services, deployments, config maps, etc.).
Passes the resulting chart or references to other components (e.g., storing it in C20 or referencing C24).
Orbit Plane Role:
Ensures each new image can be cleanly deployed as a Helm release, standardizing how deployments are packaged.
2.4 C16 – Image Harbor
Purpose: An S3 bucket storage system for saving uploaded images.
Typical Flow:
C8 (Portal) instructs C16 to store the new image.
Stores the binary data (images, archives, or other related assets).
Orbit Plane Role:
Acts as central object storage in the architecture, providing a persistent, reliable location for images, large files, or backups that must remain available.
2.5 C20 – Chart Store
Purpose: A NoSQL (DynamoDB) database used to store:
Generated Helm charts from C12.
Metadata supplied by the user (via C8) about the images, environment, or configuration.
Typical Flow:
After C12 (Manifestor) creates the Helm chart, it is stored and indexed in C20.
The system references C20 to retrieve chart information when deploying to ephemeral K8s clusters in the Cluster Plane.
Recording event and audit logs and historical data (e.g., who uploaded which image, when it was deployed).
Linking user metadata with system events.
Orbit Plane Role:
Serves as the authoritative data store for chart artifacts and user-defined parameters.
Provides a fast, scalable way to retrieve or update chart metadata across many ephemeral clusters.
2.6 C24 – The Actual Helm Chart Artifact
Purpose: Represents the actual Helm chart artifact that the system generates and stores.
Relationship to C20:
C24 is the chart artifact itself, while C20 is the store that holds and indexes it.
When the system references “C24”, it’s pointing to the packaged Helm chart. When referencing “C20”, it’s the NoSQL DB containing references, metadata, or additional data about that chart.
Orbit Plane Role:
Provides a tangible package for deployment, used by ephemeral K8s clusters (via Helm) to install or upgrade services.
2.7 C28 – Kubernetes Kustomize
Purpose: Used for generating various deployment manifest files for different environments.
Kustomize allows layering, patching, or overriding base manifests for distinct environments (dev, test, staging, prod).
Typical Flow:
The system takes the base Helm chart or existing manifests.
Kustomize (C28) applies environment-specific overrides (e.g., scaling factors, resource limits, config maps).
Outputs the final YAML files that the ephemeral clusters will consume.
Orbit Plane Role:
Ensures a clean separation between the base deployment definitions and environment-specific customizations.
Helps standardize how multiple ephemeral clusters are configured differently but still from a common baseline.
2.8 C32 – Viewport (MySQL DB)
Purpose: A MySQL database for storing extended information about images, their lifecycle stages, and other system details.
Typical Use Cases:
Tracking the progress of an image from development to production.
Linking user metadata with system events.
Orbit Plane Role:
Acts as a relational store for more complex queries or joins related to k8or Portal.
Provides robust, structured data handling for advanced reporting, analytics, or cross-referencing of different artifacts.
3. How These Components Work Together
Here’s a simplified end-to-end narrative illustrating how these components interact:
Developer Builds Image (C4)
The developer uses a CI pipeline or local tools to build a Docker image.
The image is tagged and prepared for upload.
Portal Upload & Metadata (C8)
The developer logs into the k8or Portal (C8) and uploads the newly built image, providing metadata (environment info, version, etc.).
Image Storage (C16)
The portal sends the image (or artifact) to Image Harbor (C16), which stores it in an S3 bucket.
Helm Chart Creation (C12 → C20 → C24)
Manifestor (C12) generates a Helm chart describing how to deploy that image.
The chart artifact itself is labeled C24, while the chart’s metadata is stored in the Chart Store (C20) (DynamoDB).
Now the system has a “package” (the Helm chart) ready for deployment.
Kustomize Overlays (C28)
If environment-specific variations are needed, the system uses Kubernetes Kustomize (C28) to generate or patch the final manifests for each ephemeral cluster.
Data Tracking (C32)
The MySQL database (C32) keeps track of each image’s lifecycle: who uploaded it, which environment(s) it has been deployed to, and any relevant metadata or logs.
Deployment to K8s Ephemeral Clusters
Finally, the ephemeral K8s clusters in the Cluster Plane fetch the Helm charts (C24), via other components, and apply the Kustomize overlays (C28) as needed.
The Orbit Plane (C8, C12, etc.) remains in control, monitoring the deployment and storing logs or updates back into C32.
4. Why This Matters in the Orbit Plane
Persistence & Control: Because ephemeral clusters can come and go, the Orbit Plane (with these components) retains all critical data and management logic.
Separation of Concerns: Each component focuses on a specific function—image building, storing, chart generation, metadata, or environment customization.
Scalability & Flexibility: Storing Helm charts in C20 (DynamoDB) and image artifacts in C16 (S3) allows the system to scale independently of ephemeral cluster lifecycles.
Traceability: MySQL (C32) gives the ability to query and track images or deployments across multiple ephemeral clusters over time.
5. Presenting This Architecture
When presenting or explaining the Orbit Plane:
Start with C8 (Portal)
Emphasize how developers interact with the system through a friendly UI.
This is the easiest entry point for stakeholders to understand.
Show the Flow from building an image (C4) to storing it (C16) and generating Helm charts (C12/C24)
Highlight how each step is automated and tracked.
Explain the Storage (C20 for charts/metadata, C16 for images, C32 for relational data)
This clarifies how data is kept safe, consistent, and queryable over time.
Discuss Kustomize (C28) for environment-specific overrides
Illustrates how you can seamlessly adapt one set of manifests to multiple ephemeral clusters.
Tie it back to ephemeral clusters in the Cluster Plane
The Orbit Plane controls all these operations while ephemeral clusters come and go.
6. Conclusion
The Orbit Plane is the backbone of this architecture, ensuring that image building (C4), portal-driven uploads (C8), chart generation (C12, C24), data storage (C16, C20, C32), and Kustomize-based manifest creation (C28) all happen in a cohesive, consistent manner. By centralizing these long-lived services in a static plane, the system can manage and monitor ephemeral clusters (in the Cluster Plane) with minimal disruption and maximum flexibility.
Last updated