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:

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.

Note that Spinnaker uses the latest non-kubectl version of Kustomize.

Enabling Kustomize in 1.16 and 1.17 (Beta)

Kustomize can be enabled by a feature flag in 1.16 and 1.17.

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:

  • The account (required)

    The git/repo account to use.

  • The URL (required)

    The location of the Git repository.

  • The branch (optional)

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

  • The 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.

  • The 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

Before updating. The fields highlighed in red should be updated as described above.
After updating.

Other Templating Engines

In addition to Kustomize, Spinnaker also supports Helm as a templating engine. For more information, see Deploy Helm Charts.