Pulumi Blog: Vivek Lakshmanan

Helm Release Resource for Kubernetes Generally Available

Vivek Lakshmanan — Fri, 04 Feb 2022 09:00:00 -0800

Back in September 2021 we announced public preview for the Helm Release resource in Pulumi’s Kubernetes provider. Over the last few months, we have had a very encouraging uptake in usage and several meaningful discussions with users in the community that have helped shape improvements to this resource. Thanks to this collaboration, we are now pleased to announce that the Helm Release resource is now GA (generally available) starting in v3.15.0 of the Pulumi Kubernetes Provider and SDK in all Pulumi supported languages. We are excited to offer yet another tool to Pulumi users to effectively manage their Kubernetes footprint.

The existing Helm Chart component resource will continue to be supported.

What is the Helm Release resource?

The Kubernetes provider has supported a means to deploy Helm Charts since 2018 through the Chart resource. This resource simulates Helm installation by resolving the templates for underlying resources from the chart and installing them on the target Kubernetes environment directly.

In contrast, the new Helm Release resource uses the Helm SDK natively to perform all Helm operations. This comes with some inherent advantages:

Support for the full spectrum of Helm features
Ability to import existing Helm releases into Pulumi state
Interact with the installed Helm Release through the Helm CLI

Which Helm Resource Should I Choose?

Both the Chart and Helm Release resource are complimentary with their own pros and cons. Depending on your use case, one might be a better fit than the other. We now have a guide to help you choose the right resource for your use case.

How Do I Get Started?

If you aren’t already familiar with using Pulumi with Kubernetes, head on over to Pulumi’s getting started guide for Kubernetes first.

In your chosen Kubernetes Pulumi project, make sure the referenced version of the Pulumi-Kubernetes SDK is at least v3.15.0.
Like other Kubernetes resources managed by Pulumi, the target cluster for Helm Release is configured with a Provider. The default options work for typical cases, and we also provide advanced configuration options for private registries, etc.
Refer to the instructions for your chosen language in the resource documentation to create a Helm Release resource.

Let’s look at a concrete example of Helm Release in action. In the following snippet we install Redis using the new Helm Release resource:

import * as random from "@pulumi/random";
import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

// Create a password
const pass = new random.RandomPassword("pass", {length:10});
const redisPassword = pass.result;

const namespace = new k8s.core.v1.Namespace("redis-ns");

const release = new k8s.helm.v3.Release("redis-helm", {
 chart: "redis",
 repositoryOpts: {
 repo: "https://charts.bitnami.com/bitnami",
 },
 version: "13.0.0",
 namespace: namespace.metadata.name,
 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters for reference.
 values: {
 cluster: {
 enabled: true,
 slaveCount: 3,
 },
 metrics: {
 enabled: true,
 service: {
 annotations: {
 "prometheus.io/port": "9127",
 }
 },
 },
 global: {
 redis: {
 password: redisPassword,
 }
 },
 rbac: {
 create: true,
 }
 },
 // By default Release resource will wait until all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 skipAwait: false,
});


// We can look up resources once the release is installed. The release's
// status field is set once the installation completes, so this, combined
// with `skipAwait: false` above, will wait to retrieve the Redis master
// ClusterIP until all resources in the Chart are available.
const srv = k8s.core.v1.Service.get("redis-master-svc",
 pulumi.interpolate`${release.status.namespace}/${release.status.name}-master`);
export const redisMasterClusterIP = srv.spec.clusterIP;

package main

import (
 "fmt"

 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v3/go/kubernetes/core/v1"
 "github.com/pulumi/pulumi-kubernetes/sdk/v3/go/kubernetes/helm/v3"
 "github.com/pulumi/pulumi-random/sdk/v4/go/random"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 namespace, err := corev1.NewNamespace(ctx, "redis-ns", nil)
 if err != nil {
 return err
 }

 redisPassword, err := random.NewRandomPassword(ctx, "pass", &random.RandomPasswordArgs{
 Length: pulumi.Int(10),
 })
 if err != nil {
 return err
 }

 rel, err := helm.NewRelease(ctx, "redis-helm", &helm.ReleaseArgs{
 Chart: pulumi.String("redis"),
 RepositoryOpts: helm.RepositoryOptsArgs{
 Repo: pulumi.String("https://charts.bitnami.com/bitnami"),
 },
 Version: pulumi.String("13.0.0"),
 Namespace: namespace.Metadata.Name(),

 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters for reference.
 Values: pulumi.Map{
 "cluster": pulumi.Map{
 "enabled": pulumi.Bool(true),
 },
 "metrics": pulumi.Map{
 "enabled": pulumi.Bool(true),
 "service": pulumi.Map{
 "annotations": pulumi.StringMap{
 "prometheus.io/port": pulumi.String("9127"),
 },
 "type": pulumi.String("ClusterIP"),
 },
 },
 "global": pulumi.Map{
 "redis": pulumi.Map{
 "password": redisPassword.Result,
 },
 },
 "rbac": pulumi.BoolMap{
 "create": pulumi.Bool(true),
 },
 },

 // By default Release resource will wait until all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 SkipAwait: pulumi.BoolPtr(false),
 })
 if err != nil {
 return err
 }

 // We can look up resources once the release is installed. The release's
 // status field is set once the installation completes, so this, combined
 // with `skipAwait: pulumi.BoolPtr(false)` above, will wait to retrieve
 // the Redis master ClusterIP until all resources in the Chart are available.
 svc := pulumi.All(rel.Status.Namespace(), rel.Status.Name()).
 ApplyT(func(r interface{}) (interface{}, error) {
 arr := r.([]interface{})
 namespace := arr[0].(*string)
 name := arr[1].(*string)
 svc, err := corev1.GetService(ctx,
 "redis-master-svc",
 pulumi.ID(fmt.Sprintf("%s/%s-master", *namespace, *name)),
 nil,
 )
 if err != nil {
 return "", nil
 }
 return svc.Spec.ClusterIP(), nil
 })
 ctx.Export("redisMasterClusterIP", svc)

 return nil
 })
}

import pulumi
from pulumi import Output
from pulumi_random.random_password import RandomPassword
from pulumi_kubernetes.core.v1 import Namespace, Service
from pulumi_kubernetes.helm.v3 import Release, ReleaseArgs, RepositoryOptsArgs

namespace = Namespace("redis-ns")

redis_password = RandomPassword("pass", length=10)

release_args = ReleaseArgs(
 chart="redis",
 repository_opts=RepositoryOptsArgs(
 repo="https://charts.bitnami.com/bitnami"
 ),
 version="13.0.0",
 namespace=namespace.metadata["name"],

 # Values from Chart's parameters specified hierarchically,
 # see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters
 # for reference.
 values={
 "cluster": {
 "enabled": True,
 "slaveCount": 3,
 },
 "metrics": {
 "enabled": True,
 "service": {
 "annotations": {
 "prometheus.io/port": "9127",
 }
 },
 },
 "global": {
 "redis": {
 "password": redis_password.result,
 }
 },
 "rbac": {
 "create": True,
 },
 },
 # By default Release resource will wait until all created resources
 # are available. Set this to true to skip waiting on resources being
 # available.
 skip_await=False)

release = Release("redis-helm", args=release_args)

# We can look up resources once the release is installed. The release's
# status field is set once the installation completes, so this, combined
# with `skip_await=False` above, will wait to retrieve the Redis master
# ClusterIP until all resources in the Chart are available.
status = release.status
srv = Service.get("redis-master-svc",
 Output.concat(status.namespace, "/", status.name, "-master"))
pulumi.export("redisMasterClusterIP", srv.spec.cluster_ip)

using Pulumi;
using System.Collections.Generic;
using Pulumi.Random;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Helm.V3;

class MyStack : Stack
{
 public MyStack()
 {
 var ns = new Pulumi.Kubernetes.Core.V1.Namespace("redis-ns");
 var redisPassword = new RandomPassword("pass", new RandomPasswordArgs
 {
 Length = 10,
 });

 var releaseArgs = new ReleaseArgs
 {
 Chart = "redis",
 RepositoryOpts = new RepositoryOptsArgs
 {
 Repo = "https://charts.bitnami.com/bitnami",
 },
 Version = "13.0.0",
 Namespace = ns.Metadata.Apply(metadata => metadata.Name),
 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters
 // for reference.
 Values = new InputMap<object>
 {
 ["cluster"] = new Dictionary<string,object>
 {
 ["enabled"] = true,
 ["slaveCount"] = 3,
 },
 ["metrics"] = new Dictionary<string,object>
 {
 ["enabled"] = true,
 ["service"] = new Dictionary<string, object>
 {
 ["annotations"] = new Dictionary<string, string>
 {
 ["prometheus.io/port"] = "9127",
 },
 }
 },
 ["global"] = new Dictionary<string,object>
 {
 ["redis"] = new Dictionary<string, object>
 {
 ["password"] = redisPassword.Result,
 },
 },
 ["rbac"] = new Dictionary<string,object>
 {
 ["create"] = true,
 }
 },
 // By default Release resource will wait until all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 SkipAwait = false,
 };

 var release = new Release("redis-helm", releaseArgs);

 // We can look up resources once the release is installed. The release's
 // status field is set once the installation completes, so this, combined
 // with `skip_await=False` above, will wait to retrieve the Redis master
 // ClusterIP until all resources in the Chart are available.
 var status = release.Status;
 var service = Service.Get("redist-master-svc", Output.All(status).Apply(
 s => $"{s[0].Namespace}/{s[0].Name}-master"));
 this.RedisMasterClusterIP = service.Spec.Apply(spec => spec.ClusterIP);
 }

 [Output]
 public Output<string> RedisMasterClusterIP { get; set; }
}

Users of the existing Helm Chart resource will notice that we retained the hierarchical values specification experience and a similar means to configure the repository. The above example also highlights the await and resource lookup experience.

Rollout of the above program is shown in the slightly sped up gif below:

What’s New Since the Preview Announcement?

Thanks to our community of early adopters, we received excellent feedback on the new resource which helped us make significant improvements since our initial preview. Apart from several robustness improvements, some major callouts include:

Honor namespace specification for all resources installed by Helm Release [#1747]
Make values optional [#1761]
Make RepositoryOpts optional [#1806]
Support local charts [#1809]
Add import support [#1818]
Support loading values from yaml files [#1828]

Where Can I Learn More?

You can learn more about Helm Release from the following sources:

The Helm Release API Reference docs are an excellent starting point to learn more about the API in each of the supported languages along with code samples.
Our guide on choosing between the Chart and Release resource for your use case
One of our sample projects where you can see the Helm Release resource in action in any one of Pulumi’s supported languages:
- TypeScript
- Python
- C#
- Go

If you have questions or run into issues, please don’t hesitate to reach out by filing issues on Github or asking questions on Community Slack. Happy charting!

Pulumi Kubernetes Operator 1.0

Luke Hoban — Tue, 12 Oct 2021 00:00:00 +0000

Check out version 2.0 of the Pulumi Kubernetes Operator.

Last year we released the Pulumi Kubernetes Operator, a new cloud-native way to manage and deploy cloud infrastructure using Pulumi from within your Kubernetes environment. Since then, we’ve worked with many Pulumi users who have adopted the Pulumi Kubernetes Operator at increasingly larger scales and for a wide variety of use cases. Today, we’re excited to make the 1.0 release of the Pulumi Kubernetes Operator available.

The Pulumi Kubernetes Operator defines a Kubernetes Custom Resource called pulumi.com/v1/Stack, which represents a Pulumi stack. The Pulumi stack can be authored in any supported Pulumi language (TypeScript, Python, Go, .NET) and can deploy and manage cloud infrastructure in any supported cloud (AWS, Azure, GCP, Kubernetes and 60+ additional cloud and SaaS providers). The Pulumi Kubernetes Operator triggers cloud deployments based on changes to the Stack Custom Resource or the resources it tracks.

As a result, the Pulumi Kubernetes Operator enables users to specify the desired state of their cloud infrastructure using resources managed directly in their Kubernetes cluster, which trigger creation, update and deletion of the detailed cloud infrastructure they need.

For example, the following Kubernetes resource can be created to deploy a Pulumi program which provisions cloud infrastructure to manage NGINX provided in the target Git repo and commit, and future updates to the commit or config settings will deploy updates to the infrastructure.

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: nginx-k8s-stack-production
spec:
 stack: acmecorp/nginx/production
 projectRepo: https://github.com/acmecorp/pulumi-nginx
 commit: 2b0889718d3e63feeb6079ccd5e4488d8601e353

The Pulumi Kubernetes Operator can also be used along with Pulumi’s Kubernetes provider, which allows Pulumi programs to deploy resources to Kubernetes, either in the same cluster as the operator, or in another cluster. This can be used to package up complex Kubernetes infrastructure into more abstracted units, to mix Kubernetes and cloud infrastructure into a single unit of deployment, to define how application workloads are deployed into a cluster, or for a wide variety of additional use cases. The Pulumi Kubernetes provider has full support for the Kubernetes API available in every Pulumi language, along with newly improved support for Helm.

We’re at KubeCon North America 2021 this week - come meet us at booth SU8 if you are there! We also have two Kuberentes-focused webinars coming up where you can learn more about working with Pulumi and Kubernetes: Provision, Manage and Scale Kubernetes on Any Cloud (Oct 14th) and From Zero to Production in Kubernetes (Oct 21st).

What’s New in Pulumi Kubernetes Operator 1.0?

The 1.0 release includes many significant enhancements since the initial launch, as well as scalability, performance and quality improvements.

GitOps workflows with branch tracking and private Git repos

The operator now supports specifying a branch instead of a commit in a target Git repo. When a branch is specified, the operator will track any changes to what that branch is tracking, and trigger deployments automatically when new code is pushed. This is a “pull-based” model, where the operator watches the Git repo for changes. This ensures that the operator can be run in a private network environment that is not reachable from the internet (or via GitHub webhooks), and that the operator is fully in control of how these updates are discovered and processed.

This opens up a ton of new use cases for the Pulumi Kubernetes Operator, allowing the declarative model to be pushed from being purely within the Kubernetes resource, to allowing the exact commit to deploy to be specified in a Git repo branch. This allows infrastructure configuration to be defined once for a given environment, and then actively updated via git push. In this mode, the Pulumi Kubernetes Operator can be used in place of traditional CI/CD integrations or other cloud infrastructure deployment workflows.

The same stack as above can be changed to track a branch by using the branch option:

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: nginx-k8s-stack-production
spec:
 stack: acmecorp/nginx/production
 projectRepo: https://github.com/acmecorp/pulumi-nginx
 branch: refs/heads/production

This will watch the production branch of the repo for Git pushes, and then trigger updates to the production stack of the NGINX deployment based on the new code pushed to that branch.

To help identify what commit was last deployed when tracking a branch, the Operator publishes information about the last update under .status.lastUpdate, including the lastAttemptedCommit property and lastSuccessfulCommit property.

Along with support for branch tracking, the Operator also now supports access to private Git repositories, critical for deploying your production infrastructure via the Pulumi Kubernetes Operator.

Building on the Pulumi Automation API

A couple months after we released the Pulumi Kubernetes Operator, we also released the initial version of the Pulumi Automation API. The Automation API provides an SDK for embedding Pulumi deployments inside your own software and systems, allowing you to build your own interfaces for managing cloud infrastructure. The design of the Automation API was heavily influenced by our experience building the Pulumi Kubernetes Operator, which was a perfect example of one of these custom interfaces - the Pulumi Kubernetes Operator embeds Pulumi deployments inside Kubernetes, offering a new interface (Kubernetes Stack resources) for managing cloud infrastructure.

Since then, we’ve moved the Pulumi Kubernetes Operator over to use the Pulumi Automation API, significantly reducing the size of the operator implementation, building on a robust foundation shared with dozens of other projects in the Pulumi ecosystem, and benefiting from many improvements and features added to the Pulumi Automation API. Earlier this year, the Pulumi Automation API also reached GA as part of the Pulumi 3.0 release.

Support for any state and secrets management backend

Pulumi supports a wide variety of state management and secrets management backends. Since the initial release of the Pulumi kubernetes Operator, we have added support for using not just the Pulumi Service backends, but also all of the other open source backend options, such as S3, Azure Blob and GCS for state storage, and KMS, KeyVault and Vault for secrets management.

apiVersion: pulumi.com/v1
kind: Stack
metadata:
 name: s3-bucket-stack
spec:
 backend: s3://my-s3-backend
 stack: acmecorp/operator-dev
 projectRepo: https://github.com/acmecorp/pytest1
 initOnCreate: true
 branch: refs/head/master
 config:
 aws:region: us-west-2

Worry-free Upgrades

The Pulumi Kubernetes Operator manages cloud infrastructure deployments which can take seconds to tens of minutes to complete. Although Pulumi ensures these deployments can be continued if interrupted, we want to ensure as little disruption to critical cloud infrastructure deployments as possible via the Operator. As a result, we have added a few key features to ensure that the Pulumi Kubernetes Operator can be safely upgraded to new versions without disrupting any deployments that are in-flight.

This includes capabilities like Leader Election, Graceful Shutdown and more.

Prometheus Metrics

The Pulumi Kubernetes Operator automatically manages a lot of details of Pulumi deployments, and as a result, it’s critical to be able to get insight into the operation of the Operator. Previously, this was available either via operator logs, or via the Pulumi Service. As part of the 1.0 release, the Operator is also now exporting Prometheus-compatible metrics for stacks_active and stacks_failing. These can be used to drive reporting and other workflows inside the Kubernetes cluster.

$ kubectl port-forward service/pulumi-kubernetes-operator-metrics 8383:8383 &
$ curl -s localhost:8383/metrics | grep "stacks_active\|stacks_failing"
# HELP stacks_active Number of stacks currently tracked by the Pulumi Kubernetes Operator
# TYPE stacks_active gauge
stacks_active 2
# HELP stacks_failing Number of stacks currently registered where the last reconcile failed
# TYPE stacks_failing gauge
stacks_failing{name="stack-test-aws-s3-commit-change-5wuczx",namespace="default"} 1

Documentation

We’ve added new documentation and enhanced existing documentation to ensure it’s easy to get started with the Pulumi Kubernetes Operator.

Full Stack Custom Resource API documentation is now available. And guides for deploying the Pulumi Kubernetes Operator and creating Stack resources are available for use either from kubectl/YAML or using the Pulumi Kubernetes Provider.

What’s Next

The 1.0 release of the Pulumi Kubernetes Operator is an important milestone, but there is still lots more planned to further expand the capabilities and scalability of the Operator. Some upcoming areas we’ll be investing:

Conclusion

The Pulumi Kubernetes Operator is a great way to deploy and manage cloud infrastructure from within your Kubernetes environment. With the 1.0 release, we’ve added many significant enhancements, as well as scalability, performance and quality improvements. You can get started with the Pulumi Kubernetes Operator today. Enjoy!

Full Access to Helm Features for Kubernetes

Vivek Lakshmanan — Tue, 14 Sep 2021 00:00:00 +0000

Kubernetes has been a significant focus of Pulumi since its very beginnings. Pulumi added support for installing Helm charts way back in 2018 and it has seen significant adoption by users since. However, Pulumi’s current Chart integration lacks support for some increasingly common advanced features in Helm charts, e.g.:

Support for Helm lifecycle hooks
Handling sub-charts and Helm chart dependencies

As Helm and its usage evolved over the years, Pulumi users using the Chart resource have often had to get very creative in order to get the desired functionality in their deployments.

Today we are excited to announce the public preview of a new Helm Release resource starting with v3.7.0 of the Pulumi Kubernetes Provider and SDK in all Pulumi supported languages. This new resource provides Pulumi users more options to choose the right tool for their use-case. The rest of this blog post will highlight how this resource differs from the existing Helm Chart component resource and describe how and when to use the new resource.

The existing Helm Chart component resource, which extracts and converts Kubernetes resources into individual resources in the Pulumi program, will continue to be supported.

How is Helm Release resource different?

Pulumi’s Helm Chart integration was implemented as a Component Resource which effectively extracts the corresponding Kubernetes resources’ manifests from the chart and installs them as if they were individually specified in the Pulumi user program. This allowed users to install community developed Helm charts, while providing fine-grained control over the respective Kubernetes resources installed in the process. For instance, the installed resources are subject to all policies specified through Policy-as-Code policy packs registered with Pulumi. Other users have used Pulumi’s powerful transformation support to manipulate Helm charts to fit their desired needs before installing them in their environment.

In contrast, the new Helm Release resource uses the Helm SDK, bringing the full feature set of Helm directly to Pulumi users. This provides the following advantages:

Helm Controls Lifecycle

Unlike the existing Chart component resource, Helm Release directly offloads all responsibility of orchestration and lifecycle management to Helm itself. This means Helm can invoke all necessary lifecycle hooks for the release as it would through the CLI. It also updates chart dependencies and correctly handles sub-chart values.

Configurable Await Support

By default, Pulumi’s Helm Release resource waits for all resources installed by the release to be available, up to a configurable timeout that defaults to 5 minutes. With a sufficient timeout, the resource can be reliably passed to dependsOn clauses in subsequent resources to encode ordering requirements. In addition, users can also require waiting on all Helm hooks to complete by setting jobAwait to true. However, if desired, all await behavior can be disabled by setting skipAwait option to true. See the SDK documentation for details for each of the above options.

Helm State Management

The release’s state is serialized and stored by Helm on the cluster. As a result, users can interact with the installed resource outside of Pulumi through the Helm CLI.

While there are many positives, there are some significant limitations to highlight with this approach as well:

Limited Transforms Support

Helm Release doesn’t support the ability to write transformations for Helm-installed manifests inline in the Pulumi program as supported in Helm Charts. Instead, users can leverage Helm’s post-renderer specified through the postRender option for the Release resource to manipulate manifests.

Limited Visibility

Secondly, only the Release resource and the relevant Kubernetes resources read back in the user program are part of Pulumi state. Other items installed by the chart are only controlled by Helm and are not visible and thus cannot be managed through Pulumi. However, the underlying rendered manifests and resource names will be accessible to users of the resource through the manifest and resourceNames fields as part of the deployment preview.

How do I use it?

If you aren’t already familiar with using Pulumi with Kubernetes, head on over to Pulumi’s getting started guide for Kubernetes first.

In your chosen Kubernetes Pulumi project, make sure the referenced version of the Pulumi-Kubernetes SDK is at least v3.7.0.
Helm Release support is configured to target the relevant cluster pointed to by the Kubernetes provider associated with it and no additional configuration is required by default. However, more advanced configuration options are supported, see the provider configuration documentation for more details.
Refer to the instructions for your chosen language in the resource documentation to create a Helm Release resource.

Lets look at a concrete example of Helm Release in action. In the following snippet we install Redis through a Helm Chart in each of the supported Pulumi languages using the new Helm Release resource:

import * as random from "@pulumi/random";
import * as pulumi from "@pulumi/pulumi";
import * as k8s from "@pulumi/kubernetes";

// Create a password
const pass = new random.RandomPassword("pass", {length:10});
const redisPassword = pass.result;

const namespace = new k8s.core.v1.Namespace("redis-ns");

const release = new k8s.helm.v3.Release("redis-helm", {
 chart: "redis",
 repositoryOpts: {
 repo: "https://charts.bitnami.com/bitnami",
 },
 version: "13.0.0",
 namespace: namespace.metadata.name,
 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters for reference.
 values: {
 cluster: {
 enabled: true,
 slaveCount: 3,
 },
 metrics: {
 enabled: true,
 service: {
 annotations: {
 "prometheus.io/port": "9127",
 }
 },
 },
 global: {
 redis: {
 password: redisPassword,
 }
 },
 rbac: {
 create: true,
 }
 },
 // By default Release resource will wait till all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 skipAwait: false,
});


// We can lookup resources once the release is installed. The release's
// status field is set once the installation completes, so this, combined
// with `skipAwait: false` above, will wait to retrieve the Redis master
// ClusterIP till all resources in the Chart are available.
const srv = k8s.core.v1.Service.get("redis-master-svc",
 pulumi.interpolate`${release.status.namespace}/${release.status.name}-master`);
export const redisMasterClusterIP = srv.spec.clusterIP;

package main

import (
 "fmt"

 corev1 "github.com/pulumi/pulumi-kubernetes/sdk/v3/go/kubernetes/core/v1"
 "github.com/pulumi/pulumi-kubernetes/sdk/v3/go/kubernetes/helm/v3"
 "github.com/pulumi/pulumi-random/sdk/v4/go/random"
 "github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
 pulumi.Run(func(ctx *pulumi.Context) error {

 namespace, err := corev1.NewNamespace(ctx, "redis-ns", nil)
 if err != nil {
 return err
 }

 redisPassword, err := random.NewRandomPassword(ctx, "pass", &random.RandomPasswordArgs{
 Length: pulumi.Int(10),
 })
 if err != nil {
 return err
 }

 rel, err := helm.NewRelease(ctx, "redis-helm", &helm.ReleaseArgs{
 Chart: pulumi.String("redis"),
 RepositoryOpts: helm.RepositoryOptsArgs{
 Repo: pulumi.String("https://charts.bitnami.com/bitnami"),
 },
 Version: pulumi.String("13.0.0"),
 Namespace: namespace.Metadata.Name(),

 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters for reference.
 Values: pulumi.Map{
 "cluster": pulumi.Map{
 "enabled": pulumi.Bool(true),
 },
 "metrics": pulumi.Map{
 "enabled": pulumi.Bool(true),
 "service": pulumi.Map{
 "annotations": pulumi.StringMap{
 "prometheus.io/port": pulumi.String("9127"),
 },
 "type": pulumi.String("ClusterIP"),
 },
 },
 "global": pulumi.Map{
 "redis": pulumi.Map{
 "password": redisPassword.Result,
 },
 },
 "rbac": pulumi.BoolMap{
 "create": pulumi.Bool(true),
 },
 },

 // By default Release resource will wait till all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 SkipAwait: pulumi.BoolPtr(false),
 })
 if err != nil {
 return err
 }

 // We can lookup resources once the release is installed. The release's
 // status field is set once the installation completes, so this, combined
 // with `skipAwait: pulumi.BoolPtr(false)` above, will wait to retrieve
 // the Redis master ClusterIP till all resources in the Chart are available.
 svc := pulumi.All(rel.Status.Namespace(), rel.Status.Name()).
 ApplyT(func(r interface{}) (interface{}, error) {
 arr := r.([]interface{})
 namespace := arr[0].(*string)
 name := arr[1].(*string)
 svc, err := corev1.GetService(ctx,
 "redis-master-svc",
 pulumi.ID(fmt.Sprintf("%s/%s-master", *namespace, *name)),
 nil,
 )
 if err != nil {
 return "", nil
 }
 return svc.Spec.ClusterIP(), nil
 })
 ctx.Export("redisMasterClusterIP", svc)

 return nil
 })
}

import pulumi
from pulumi import Output
from pulumi_random.random_password import RandomPassword
from pulumi_kubernetes.core.v1 import Namespace, Service
from pulumi_kubernetes.helm.v3 import Release, ReleaseArgs, RepositoryOptsArgs

namespace = Namespace("redis-ns")

redis_password = RandomPassword("pass", length=10)

release_args = ReleaseArgs(
 chart="redis",
 repository_opts=RepositoryOptsArgs(
 repo="https://charts.bitnami.com/bitnami"
 ),
 version="13.0.0",
 namespace=namespace.metadata["name"],

 # Values from Chart's parameters specified hierarchically,
 # see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters
 # for reference.
 values={
 "cluster": {
 "enabled": True,
 "slaveCount": 3,
 },
 "metrics": {
 "enabled": True,
 "service": {
 "annotations": {
 "prometheus.io/port": "9127",
 }
 },
 },
 "global": {
 "redis": {
 "password": redis_password.result,
 }
 },
 "rbac": {
 "create": True,
 },
 },
 # By default Release resource will wait till all created resources
 # are available. Set this to true to skip waiting on resources being
 # available.
 skip_await=False)

release = Release("redis-helm", args=release_args)

# We can lookup resources once the release is installed. The release's
# status field is set once the installation completes, so this, combined
# with `skip_await=False` above, will wait to retrieve the Redis master
# ClusterIP till all resources in the Chart are available.
status = release.status
srv = Service.get("redis-master-svc",
 Output.concat(status.namespace, "/", status.name, "-master"))
pulumi.export("redisMasterClusterIP", srv.spec.cluster_ip)

using Pulumi;
using System.Collections.Generic;
using Pulumi.Random;
using Pulumi.Kubernetes.Core.V1;
using Pulumi.Kubernetes.Types.Inputs.Helm.V3;
using Pulumi.Kubernetes.Helm.V3;

class MyStack : Stack
{
 public MyStack()
 {
 var ns = new Pulumi.Kubernetes.Core.V1.Namespace("redis-ns");
 var redisPassword = new RandomPassword("pass", new RandomPasswordArgs
 {
 Length = 10,
 });

 var releaseArgs = new ReleaseArgs
 {
 Chart = "redis",
 RepositoryOpts = new RepositoryOptsArgs
 {
 Repo = "https://charts.bitnami.com/bitnami",
 },
 Version = "13.0.0",
 Namespace = ns.Metadata.Apply(metadata => metadata.Name),
 // Values from Chart's parameters specified hierarchically,
 // see https://artifacthub.io/packages/helm/bitnami/redis/13.0.0#parameters
 // for reference.
 Values = new InputMap<object>
 {
 ["cluster"] = new Dictionary<string,object>
 {
 ["enabled"] = true,
 ["slaveCount"] = 3,
 },
 ["metrics"] = new Dictionary<string,object>
 {
 ["enabled"] = true,
 ["service"] = new Dictionary<string, object>
 {
 ["annotations"] = new Dictionary<string, string>
 {
 ["prometheus.io/port"] = "9127",
 },
 }
 },
 ["global"] = new Dictionary<string,object>
 {
 ["redis"] = new Dictionary<string, object>
 {
 ["password"] = redisPassword.Result,
 },
 },
 ["rbac"] = new Dictionary<string,object>
 {
 ["create"] = true,
 }
 },
 // By default Release resource will wait till all created resources
 // are available. Set this to true to skip waiting on resources being
 // available.
 SkipAwait = false,
 };

 var release = new Release("redis-helm", releaseArgs);

 // We can lookup resources once the release is installed. The release's
 // status field is set once the installation completes, so this, combined
 // with `skip_await=False` above, will wait to retrieve the Redis master
 // ClusterIP till all resources in the Chart are available.
 var status = release.Status;
 var service = Service.Get("redist-master-svc", Output.All(status).Apply(
 s => $"{s[0].Namespace}/{s[0].Name}-master"));
 this.RedisMasterClusterIP = service.Spec.Apply(spec => spec.ClusterIP);
 }

 [Output]
 public Output<string> RedisMasterClusterIP { get; set; }
}

Rollout of the above program is shown in the slightly sped up gif below:

Which Helm resource to use and when?

In summary, if your primary goal is to install Helm charts with configuration options natively supported by the chart, then Helm Release should be a good fit. If on the other hand you intend to manipulate Helm Charts through transformations (due to bugs in the charts or restrictions in your environment), then the experience is much richer with the Helm Chart resource.

If you intend to use Policy-as-Code to enforce resource policies at a Kubernetes resource granularity, then the Helm Chart component resource would be the preferred model to use.

Note that both resources can co-exist safely in the same program.

What’s next?

The new Helm Release resource is available in preview now. During the preview the resource may evolve rapidly and users are requested to not use it for critical infrastructure. We have already received valuable feedback to shape this resource and we look forward to hearing more from our users. Please reach out by filing or commenting on issues on Github or asking questions on Community Slack. Happy charting!