Use Kustomize for Manifests

Kustomize is a tool that lets you create customized Kubernetes deployments without modifying underlying YAML configuration files. Since the files remain unchanged, others are able to reuse the same files to build their own customizations. Your customizations are stored in a file called kustomization.yaml. If configuration changes are needed, the underlying YAML files and kustomization.yaml can be updated independently of each other.

To learn more about Kustomize and how to define a kustomization.yaml file, see the following links:

• Kubernetes SIG for Kustomize
• Documentation for Kustomize
• Example Kustomization

In the context of Spinnaker, Kustomize lets you generate a custom manifest, which can be deployed in a downstream Deploy (Manifest) stage. This manifest is tailored to your requirements and built on existing configurations.

Enabling Kustomize Prior to 1.20

Kustomize must be enabled by a feature flag in Spinnaker 1.16 - 1.19.

For Halyard, add the following line to ~/.hal/{DEPLOYMENT_NAME}/profiles/settings-local.js:

window.spinnakerSettings.feature.kustomizeEnabled = true;

Overview

Kustomize works by running kustomize build against a kustomization.yaml file located in a Git repository. This file defines all of the other files needed by Kustomize to render a fully hydrated manifest.

Kustomize support was added to Spinnaker in 1.16. However, the instructions for using Kustomize vary between Spinnaker 1.16 and 1.17+.

Configure the “Bake (Manifest)” stage

Using Spinnaker 1.17+

Note: Kustomize in 1.17+ requires the git/repo artifact type.**

Select Kustomize as the Render Engine and define the artifact for your kustomization.yaml.

You can specify the following:

• Account (required)

  The git/repo account to use.

• URL (required)

  The location of the Git repository.

• Branch (optional)

  The branch of the repository you want to use. [Defaults to master]

• Subpath (optional)

  By clicking Checkout subpath, you can optionally pass in a relative subpath within the repository. This provides the option to checkout only a portion of the repository, thereby reducing the size of the generated artifact.

• Kustomize File (required)

  The relative path to the kustomization.yaml file residing in the Git repository.

Using Spinnaker 1.16

Select Kustomize as the Render Engine and define the artifact for your kustomization.yaml:

Configuring the Produced Artifact

With the Bake (Manifest) Configuration completed, configure a Produced Artifact to use the result in a stage downstream. Add an artifact:

Define the artifact:

You can now run your pipeline and get a Kustomize rendered manifest!

Updating 1.16 “Bake (Manifest)” stage for 1.17

As of 1.17, git/repo is the only supported artifact type when configuring the Bake (Manifest) stage in the UI with Kustomize.

Pipelines configured to use Kustomize in 1.16 will continue to work in 1.17. However, editing a Bake (Manifest) stage in 1.17, which was originally created in 1.16, requires you to update the Bake (Manifest) Configuration to use the git/repo artifact type. To do so, use the following instructions:

1. Click on the Account dropdown and select a configured git/repo account. If none appear, make sure you have configured a git/repo account
   Note: You should click and select a git/repo account even if one already appears in the UI prior to your doing so. This will force the underlying JSON to be updated to use the new artifact.

2. Update the URL. This should be the location of the git repository.
   example: https://github.com/kubernetes-sigs/kustomize

3. Provide the Kustomize file path. This should be the relative path to the kustomization.yaml within the repository.
   example: examples/wordpress/mysql/kustomization.yaml

Other Templating Engines

In addition to Kustomize, Spinnaker also supports Helm (and Helmfile) as templating engines. For more information, see Deploy Helm Charts .