Component C24 – Helm Chart Artifact
By Raj Marni. March 23, 2025. Revised. Version: 0.1.12
1. Overview
C24 – Helm Chart Artifact is the meta-component responsible for packaging Kubernetes manifests (in the form of Helm charts) into deployable artifacts. These artifacts represent the final, deployable configuration that integrates user-defined metadata and image configurations, providing a templated solution for Kubernetes clusters. In Layer 3, we will examine how Helm chart generation works within k8or Orbit, how it interacts with other components, and the internal systems that power it.
2. Internal Architecture
2.1 Core Modules
Helm Chart Packaging Engine
Function: Converts configuration data (e.g., images, metadata, deployment parameters) into a standardized Helm chart format, including Kubernetes manifests such as deployments, services, config maps, etc.
Process:
Receives inputs from C12 (Manifestor), which provides the raw data and metadata.
Transforms this data into a templated Helm chart, incorporating environment-specific variables, user settings, and dependency requirements.
Outputs a versioned Helm chart as a final artifact for deployment.
Template Engine
Function: Uses templates (Go templates) to generate Kubernetes resource definitions.
Process:
Templating engine takes the user-defined variables (such as resource limits, replicas, environment variables) and applies them to predefined Kubernetes resource templates.
The output is a customized deployment configuration that can be applied to any Kubernetes cluster, ensuring flexibility and scalability.
Chart Metadata Manager
Function: Maintains metadata associated with each Helm chart (e.g., version, environment, image references, build number).
Process:
Tracks versioning information and updates metadata as charts are generated or modified.
Ensures that each Helm chart is uniquely identified and referenced in downstream components, like C20 (Chart Store).
Chart Validation Module
Function: Ensures that the generated Helm chart adheres to Kubernetes and Helm standards.
Process:
Lints the Helm chart to detect any errors in the configuration or structure.
Verifies that dependencies are correctly resolved and the chart meets best practices for Kubernetes deployments.
Issues alerts or logs when issues are detected.
Artifact Storage Interface
Function: Facilitates the storage of generated Helm chart artifacts in a centralized location.
Process:
Interacts with C20 (Chart Store) to push the final Helm chart artifacts into a persistent storage layer.
Supports versioning and ensures that chart artifacts are retrievable for future use or deployment.
3. External Interactions
3.1 Interactions with k8or Orbit Components
From C12 – Manifestor
Purpose:
The Manifestor (C12) provides image data and metadata to C24 to create the corresponding Helm charts.
The Helm chart creation process uses the image configurations and deployment settings provided by C12 as input for generating manifests.
Mechanism:
Synchronous API calls or data exchanges between C12 and C24, where C12 sends a structured payload (containing metadata, image references, environment configurations) for chart generation.
To C20 – Chart Store
Purpose:
Once the Helm chart is generated, C24 pushes the chart into the Chart Store (C20) for versioned storage.
C20 acts as the repository for storing all generated Helm charts, ensuring that they can be retrieved for future deployment or modifications.
Mechanism:
A RESTful API call or direct database interaction that stores the finalized Helm chart and its associated metadata in C20.
To C28 – Kubernetes Kustomize
Purpose:
C28 (Kustomize) can apply additional environment-specific customizations to the base Helm chart generated by C24.
Kustomize takes the base Helm chart as input and adds overlays or modifications that suit the specific needs of the deployment environment.
Mechanism:
Asynchronous or direct integration between C24 and C28, where C28 pulls the Helm chart from C24, applies customizations, and outputs the environment-specific manifest.
To C8 – K8or Portal
Purpose:
The K8or Portal (C8) serves as the user interface where users can upload images and define deployment parameters. This information is used to generate Helm charts via C24.
Mechanism:
C8 sends user inputs to C12, which in turn interacts with C24 to generate Helm charts.
3.2 External Integrations
CI/CD Pipelines
Purpose:
Automated pipelines (Jenkins, GitLab CI, Argo CD) can integrate with C24 to automatically generate Helm charts as part of the deployment process.
For instance, a CI pipeline can trigger the generation of a Helm chart each time a new Docker image is pushed to the registry.
Mechanism:
The CI/CD pipeline triggers a process to send the necessary data to C24, which then generates and stores the corresponding Helm chart.
External Helm Repositories
Purpose:
In some cases, Helm charts generated by C24 can be stored or published to external Helm chart repositories for easier access across different Kubernetes clusters or environments.
Mechanism:
Integration with external Helm chart repositories, such as Artifact Hub, can be achieved by syncing the chart storage from C20 to public or private Helm registries.
4. Technology & Protocols
Helm:
Uses Helm 3 to package Kubernetes manifests and templates into charts, which are stored and applied as versioned packages.
Kubernetes Manifests:
Standard Kubernetes resource definitions (e.g., Deployments, Services, ConfigMaps, Secrets) are used within the Helm charts.
RESTful APIs:
REST APIs are used for communication between C24, C12, C20, and other orchestration components (like C28).
Version Control:
Helm charts are stored in C20 with versioning and metadata management to keep track of different chart revisions.
CI/CD Integration:
Webhooks, Jenkins pipelines, or GitOps tools like Argo CD can trigger Helm chart generation as part of the continuous deployment process.
5. Benefits & Impact
Standardized & Scalable Deployments
By generating Helm charts that follow standard Kubernetes practices, C24 ensures that deployments are consistent, repeatable, and easy to scale.
Reduced Manual Configuration
The automated Helm chart generation reduces the need for manual intervention in creating and maintaining Kubernetes resource definitions.
Version Control
Helm chart versioning stored in C20 allows teams to manage deployments efficiently and roll back to previous configurations when needed.
Integration with CI/CD Pipelines
C24 integrates seamlessly into CI/CD pipelines, streamlining the process of generating deployable artifacts and speeding up the time to production.
Customization and Flexibility
C24 allows for customization and adaptation of Helm charts to different environments, while C28 (Kustomize) enables even more granular adjustments as per deployment requirements.
Last updated