Helm Charts Overview¶

What is Helm?¶

Helm is the package manager for Kubernetes, often described as the "apt/yum/homebrew for Kubernetes." It simplifies the deployment and management of applications on Kubernetes clusters by packaging complex applications into reusable, versioned charts.

Key Concepts¶

Helm Charts are packages of pre-configured Kubernetes resources that define, install, and upgrade even the most complex Kubernetes applications. Think of them as blueprints that contain:

Templates: Kubernetes manifest files with placeholders for dynamic values
Values: Configuration parameters that customize the deployment
Dependencies: Other charts that your application depends on
Metadata: Information about the chart version, description, and maintainers

Releases are running instances of a chart deployed to a Kubernetes cluster. Each release has a unique name and can be upgraded, rolled back, or deleted independently.

Why Use Helm Charts?¶

Simplified Deployment Management¶

Instead of managing dozens of individual Kubernetes YAML files, Helm charts package everything into a single, manageable unit. This reduces complexity and eliminates the risk of missing dependencies or configuration files.

Parameterization and Reusability¶

Helm charts use templating to make deployments configurable. The same chart can be deployed with different configurations for development, staging, and production environments, or customized for different customers.

Version Control and Rollbacks¶

Helm tracks deployment history, making it easy to upgrade applications or roll back to previous versions when issues arise. This provides confidence when deploying updates to production systems.

Ecosystem and Community¶

Helm has a rich ecosystem with thousands of pre-built charts available through repositories like Artifact Hub. Popular applications like PostgreSQL, Redis, Nginx, and Prometheus have well-maintained charts ready for use.

Dependency Management¶

Charts can declare dependencies on other charts, automatically handling complex multi-component applications. For example, a web application chart might depend on a database chart and a caching layer chart.

Common Use Cases for Helm Charts¶

Application Deployment¶

Deploy complex applications with multiple components, services, and configurations in a single command.

Environment Management¶

Use the same chart with different values files to deploy identical applications across development, staging, and production environments.

Multi-Tenancy¶

Deploy multiple instances of the same application for different customers or teams, each with their own configuration and resources.

CI/CD Integration¶

Integrate Helm into continuous deployment pipelines to automate application updates and rollouts.

Helm Integration with Omnistrate¶

Omnistrate provides native support for Helm charts, making it incredibly easy to transform your existing Kubernetes applications into fully-managed SaaS offerings. Here's how Helm charts integrate seamlessly with the Omnistrate platform:

Zero-Modification Deployment¶

Bring your existing Helm charts to Omnistrate without any modifications. Whether you're using charts from public repositories like Bitnami or custom charts developed in-house, Omnistrate can deploy them directly.

Automated Infrastructure Management¶

When you deploy a Helm chart through Omnistrate, the platform automatically handles:

Cloud Infrastructure: VPCs, subnets, security groups, and networking
Kubernetes Clusters: Fully managed, production-ready clusters
Load Balancing: Network load balancers with Nginx ingress controllers
DNS Management: Route53 hosted zones for custom endpoints
TLS Certificates: Automated ACME certificate provisioning and rotation
Monitoring: Kubernetes dashboard and observability tools
IAM/RBAC: Proper service accounts and role bindings

Multi-Cloud and Multi-Tenant Ready¶

Omnistrate deploys your Helm charts across AWS, Google Cloud, and Azure, handling the cloud-specific configurations automatically. Each customer deployment is isolated with proper multi-tenancy controls.

Dynamic Configuration¶

Leverage Omnistrate's system parameters and API parameters to make your Helm charts dynamically configurable:

# Example: Dynamic instance types and replica counts
replica:
  replicaCount: $var.replicas
compute:
  instanceTypes:
    - apiParam: instanceType
      cloudProvider: aws

Built-in SaaS Features¶

Omnistrate automatically adds enterprise SaaS capabilities to your Helm chart deployments:

Customer Portals: Self-service deployment interfaces
REST APIs: Programmatic access for customer integrations
Billing Integration: Usage metering and billing provider connections
Backup and Recovery: Automated backup strategies
Monitoring and Alerting: Customer-facing observability
Upgrade Management: Controlled rollouts and rollbacks

Simplified Operations¶

Instead of managing Kubernetes clusters, Helm releases, and infrastructure across multiple clouds, Omnistrate provides a unified control plane where you can:

Deploy and manage Helm chart-based services
Monitor customer deployments across all clouds
Handle upgrades and maintenance operations
Manage customer access and billing

Getting Started with Helm Charts on Omnistrate¶

The process of deploying Helm charts on Omnistrate is straightforward:

Define Your Service: Create a service specification that references your Helm chart
Configure Parameters: Set up API parameters for customer customization
Deploy and Test: Use the development environment to validate your deployment
Go Live: Release your Helm chart-based SaaS product to customers

Here's a simple example of a Redis service using a Helm chart:

name: Redis Server
services:
  - name: Redis Cluster
    helmChartConfiguration:
      chartName: redis
      chartVersion: 24.1.0
      chartRepoName: bitnami
      chartRepoURL: https://charts.bitnami.com/bitnami
      chartValues:
        master:
          persistence:
            enabled: false
          service:
            type: LoadBalancer
        replica:
          replicaCount: 1
          persistence:
            enabled: false

This specification automatically creates:

A customer portal for Redis deployments
REST APIs for programmatic access
Multi-cloud deployment capabilities
Monitoring and management interfaces

Error Handling and Stability¶

Omnistrate's Helm integration includes built-in error handling and stability features that ensure reliable deployments across your fleet.

Pre-install validation¶

Before executing a Helm install, Omnistrate validates the chart configuration, template rendering, and resource requirements. Errors such as invalid chart values, missing dependencies, or template rendering failures are reported immediately — before any Kubernetes resources are created. This fail-fast approach prevents partially deployed releases that are difficult to clean up.

First-install failure handling¶

For the initial installation of a Helm release, if the first install fails, Omnistrate immediately cleans up the release and does not leave it in a pending or failed state. This ensures a clean slate for retry and avoids issues with Helm releases stuck in an inconsistent state.

Improved error reporting¶

When a Helm operation fails, Omnistrate captures and surfaces detailed error information including:

Helm client logs — the full output from the Helm install or upgrade operation
Chart rendering errors — template syntax issues or missing values
Kubernetes resource errors — pod scheduling failures, image pull errors, and resource quota issues
Timeout details — which resources failed to become ready within the configured timeout

You can access these details through Debug Events in the instance details page, or by using the omctl instance debug command for direct access to Helm client logs and chart values.

Agent crash recovery¶

If the Omnistrate dataplane agent crashes during a Helm operation, the system automatically recovers the deployment state on restart. The agent reconciles the expected state with the actual Kubernetes state, resuming or retrying operations as needed without requiring manual intervention. You can control this behavior using the disableReconciliation flag in the runtime configuration.

Best practices for stable deployments¶

Practice	Configuration
Set appropriate timeouts	`timeoutNanos` in runtime configuration
Wait for resources to be ready	`wait: true` and `waitForJobs: true`
Disable problematic hooks	`disableHooks: true` for debugging
Use fail-fast mode (debugging only)	`disableReconciliation: true` to disable crash recovery and automatic retries; not recommended for normal production use
Manage CRDs separately	`skipCRDs: true` if CRDs are managed by an Operator

Next Steps¶

Ready to start building with Helm charts on Omnistrate? Here are the recommended next steps:

Build from Helm: Step-by-step guide to deploy your first Helm chart-based service
Helm Chart Customization: Learn how to customize charts for high availability and customer requirements
System Parameters: Understand how to use dynamic parameters in your Helm charts
Layered Chart Values: Advanced configuration techniques for complex deployments

Benefits Summary¶

By using Helm charts with Omnistrate, you get:

✅ Rapid SaaS Development: Transform existing applications into SaaS offerings in hours, not months

✅ Enterprise-Grade Infrastructure: Production-ready deployments with security, monitoring, and compliance built-in

✅ Multi-Cloud Flexibility: Deploy across AWS, GCP, and Azure without cloud-specific expertise

✅ Operational Simplicity: Unified management interface for all customer deployments

✅ Customer Self-Service: Automated portals and APIs for customer onboarding and management

✅ Scalable Architecture: Handle growth from single customers to thousands of deployments

The combination of Helm's packaging power and Omnistrate's SaaS platform capabilities provides the fastest path from Kubernetes application to production SaaS business.