Helm Chart

The Chart.yaml file is the mandatory manifest containing the chart's metadata. It defines the chart's identity, version, and dependencies, which are critical for version control and lifecycle management in edge deployments.

• apiVersion: Specifies the Helm API version (e.g., v2 or v3).
• name & version: The chart's name and version, following Semantic Versioning (SemVer).
• appVersion: The version of the application (e.g., the ML model or inference server) being packaged.
• dependencies: Lists other charts this chart requires, such as a database or message queue for an edge AI pipeline.
• keywords & maintainers: Metadata for discovery and ownership.

The values.yaml file provides the default configuration parameters for the chart. It acts as the central point for customizing deployments without modifying the core templates, which is essential for adapting to diverse edge hardware profiles.

• Declarative Configuration: Defines variables like replica counts, resource limits (CPU/memory), and model artifact locations.
• Environment-Specific Overrides: Different values files (e.g., values-prod.yaml, values-dev.yaml) or command-line overrides allow the same chart to deploy to development clusters and resource-constrained edge nodes.
• Edge AI Example: Configures the inference server image tag, GPU acceleration flags, and telemetry endpoint URLs specific to an edge location.

The templates/ directory contains template files written in the Go template language. These files generate valid Kubernetes manifest YAML when combined with values from values.yaml and the Helm runtime.

• Dynamic Generation: Templates inject configuration values, enabling a single chart to generate manifests for Deployments, Services, ConfigMaps, and DaemonSets tailored for edge nodes.
• Conditionals and Loops: Logic can be embedded to, for example, deploy a GPU-accelerated DaemonSet only on nodes with specific hardware labels.
• Core for Edge AI: This is where the Pod specification for the model container, its resource requests/limits, and volumes for persistent model storage are defined.

The charts/ directory is where dependent subcharts are stored. Subcharts allow complex applications to be composed from modular, reusable components, which is valuable for building sophisticated edge AI stacks.

• Dependency Management: When a chart lists dependencies in Chart.yaml, Helm can fetch and place them here. They can also be manually included.
• Composition Pattern: An edge AI orchestration chart might include subcharts for a model serving component, a drift detection service, and a local vector database.
• Encapsulation: Subcharts manage their own templates and values, promoting separation of concerns. Parent charts can override subchart values, enabling centralized control of a fleet deployment.

Helm Hooks are special template files annotated to run at specific points in a release's lifecycle (e.g., pre-install, post-upgrade). They manage jobs that execute outside the primary application deployment sequence.

• Lifecycle Points: Hooks can run before/after install, upgrade, rollback, or delete operations.
• Edge AI Use Cases:
  • Pre-upgrade Hook: Run a validation job to test a new model version in a shadow deployment before switching live traffic.
  • Post-install Hook: Initialize a local database or register the device with a central model monitoring service.
  • Pre-delete Hook: Safely archive inference logs from the edge device before removing the application.
• Managed Execution: Hooks are implemented as Kubernetes Job or Pod manifests with special annotations like helm.sh/hook: pre-upgrade.

The values.yaml file is the primary configuration interface for a Helm chart. It contains default parameters that populate the chart's Go templates, allowing users to customize the deployment (e.g., number of replicas, resource limits, image tags) without modifying the chart's core templates.

• Overrides: Values can be overridden via command-line flags (--set) or external YAML files (-f custom-values.yaml).
• Structure: Typically organizes configuration by component (e.g., service, deployment, ingress).
• Type Safety: Helm 3 supports schema validation for values.yaml using a values.schema.json file.