Upgrading Kubernetes applications using Helm releases

Question

Pulumi · Accepted Answer

Upgrading a Kubernetes application using Helm releases with Pulumi involves several steps. The main resource we'll be working with is `kubernetes.helm.v3.Release`, which allows you to deploy applications packaged as Helm charts. You can also upgrade, rollback, and manage the lifecycle of these Helm chart releases within a Kubernetes cluster.

Here is an overview of the steps involved:

1. **Importing Dependencies**: We'll need to import the required Pulumi and Kubernetes packages.
2. **Configuration**: Setting up any configuration that may be required for the release, such as release name, chart information, and values to override.
3. **Creating/Updating the Release**: Defining the Helm release with the `kubernetes.helm.v3.Release` resource. Pulumi will ensure that the release is created if it doesn't exist, or it will upgrade the release if it already exists with the specified chart and version.
4. **Upgrading**: To upgrade a release, you would modify the chart version or values in your Pulumi code and then run `pulumi up`. Pulumi's declarative approach will recognize the changes and perform an upgrade on the Helm release.
5. **Outputs**: Optionally, you can export any outputs you might need, such as the deployed application endpoint.

Here's a complete TypeScript program demonstrating how to define a Helm release and upgrade an application:

```typescript
import * as pulumi from "@pulumi/pulumi";
import * as kubernetes from "@pulumi/kubernetes";

// Step 1: Importing Dependencies
// Here we import Pulumi and the Kubernetes package to interact with Kubernetes resources

// Step 2: Configuration
// Replace the 'chart', 'version', and 'values' with the appropriate details for your application.

const appName = "nginx"; // The name of your application/release
const appNamespace = "default"; // The namespace where the application will reside
const chart = "nginx"; // Name of the Helm chart
const chartVersion = "1.17.1"; // Version of the chart you want to deploy/upgrade to

// Values to override defaults from the Helm chart
const customValues = {
  service: {
    type: "LoadBalancer",
  },
};

// If upgrading, modify chartVersion or customValues as necessary.
// Pulumi will handle the upgrade when you run `pulumi up`.

// Step 3: Creating/Updating the Release
// A Helm release is created if it does not exist; if it does, it may be upgraded by modifying the inputs.

const nginxRelease = new kubernetes.helm.v3.Release(appName, {
  chart: chart,
  version: chartVersion,
  namespace: appNamespace,
  valueYamlFiles: [], // You can specify additional YAML files for custom values
  values: customValues,
}, { apply: (release) => console.log(`Applying: ${release.id}`) });

// Step 4: Upgrading
// Any changes made to the chart version or values in the Pulumi program will 
// be applied when you run `pulumi up`, effectively upgrading your Helm release.

// Step 5: Outputs
// Export any necessary outputs, such as the endpoint of the deployed application.

// For LoadBalancer services, you can find out the allocated IP like this:
const frontend = nginxRelease.getResourceProperty("v1/Service", `${appName}-nginx`, "status");
export const frontendIp = frontend.apply(status => status.loadBalancer.ingress[0].ip);

// When you're ready to perform an upgrade, modify `chartVersion` or `customValues` 
// and run `pulumi up`. Pulumi will detect the changes and apply them accordingly.
```

This program will manage a Helm release for an Nginx application. You'll need to replace `chart`, `version`, and `values` with your application's details. When you make changes to the chart version or the custom values and then run `pulumi up`, Pulumi knows it needs to perform an update, which could be an upgrade if the chart version has changed.

Remember, comprehensive API documentation for `kubernetes.helm.v3.Release` can be found [here](https://www.pulumi.com/registry/packages/kubernetes/api-docs/helm/v3/release/).

By using Pulumi's declarative approach you can version-control your infrastructure alongside your application code. This ensures that updates to infrastructure such as Kubernetes Helm releases are traceable, repeatable, and less prone to manual error.