Using Kustomize for Manifests

Note that Kustomize is currently in Beta. The feature is working and installable but is not meant for production use. ​ ​

​ ​ 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: ​

Kustomize in 2.16 (Beta)

​

Enabling Kustomize in 2.16 (Beta)

​ Kustomize can be enabled by a feature flag in 2.16.

  • Operator

    Add the following settings to the SpinnakerService manifest:

      apiVersion: spinnaker.armory.io/v1alpha2
  kind: SpinnakerService
  metadata:
    name: spinnaker
  spec:
    spinnakerConfig:    
      profiles:
        deck:
          settings-local.js: |
            window.spinnakerSettings.feature.kustomizeEnabled = true;

    ​

  • Halyard

    Add the following line to ~/.hal/{DEPLOYMENT_NAME}/profiles/settings-local.js: ​

      window.spinnakerSettings.feature.kustomizeEnabled = true;

    ​

    Using Kustomize

    ​ 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. ​ Select Kustomize as the Render Engine and define the artifact for your kustomization.yaml: ​ ​ ​ With the Kustomize file defined, 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! ​

    Kustomize in 2.17 (Beta)

    ​

    Requirements

    Kustomize in 2.17+ requires the git/repo artifact type. ​

    Enable Kustomize

    ​ Kustomize can be enabled by a feature flag in Armory Spinnaker 2.16 and later.

  • Operator

    Add the following settings to the SpinnakerService manifest and apply the changes:

      apiVersion: spinnaker.armory.io/v1alpha2
  kind: SpinnakerService
  metadata:
    name: spinnaker
  spec:
    spinnakerConfig:    
      profiles:
        deck:
          settings-local.js: |
            window.spinnakerSettings.feature.kustomizeEnabled = true;

  • Halyard

    Add the following line to ~/.hal/{DEPLOYMENT_NAME}/profiles/settings-local.js: ​

      window.spinnakerSettings.feature.kustomizeEnabled = true;

    Apply your changes to your Spinnaker deployment: hal deploy apply. Wait until the pods are in a RUNNING state before proceeding. ​

You can now use the KUSTOMIZE option on a Bake (Manifest) stage. ​ ​

Note: Sometimes you will need to clear the cache in your browser in order to see the new KUSTOMIZE option available on a Bake (Manifest) stage.

​

Build the Pipeline

​ For this example, we are going to use this kustomize public repository, specifically the helloWorld example.

Step 1 - Add an Expected Artifact

​ Add a git/repo Expected Artifact in the Configuration section: ​

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

​

Note: In order to execute the pipeline mannualy, it is necesary to check the Use Default Artifact and also fill the fields (same information above). ​

Step 2 - Add a Bake (Manifest) Stage

​ Add a Bake (Manifest) stage and choose the Render Engine KUSTOMIZE. Then, select the Expected Artifact you created in step 1 and specify the path for the kustomization.yaml file. ​ ​

Step 3 - Produce the Artifact

​ Spinnaker returns the manifest in a Base64 encoded file, so it is necessary to Produce a single Base64 Artifact in this Bake (Manifest) stage: ​ ​

Step 4 - Deploy

​ Finally, add a Deploy (Manifest) stage. Make sure to select the Manifest Source: Artifact and select the Base64 Artifact produced by the Bake (Manifest) stage. ​ ​

Note: Due we are deploying a manifest without a specified namespace we need to override the namespace checking the “Override Namespace” option in the deployment stage.

Run the Pipeline

​ After you execute the pipeline, you can see the manifest generated in YAML format by clicking on the Baked Manifest YAML link: ​ ​ Also in the Deploy stage you can see the Kubernetes objects as result of the manifest deployment.