Parameterize Kubernetes Manifests

The contents of this page refer to alpha features in Spinnaker 1.6.

This means we are working on their stability and usability, as well as possibly adding or changing features. Expect rough edges, and file issues as needed.

Spinnaker can inject context from the currently executing pipeline into your manifests as they are deployed, whether they are deployed statically or dynamically.

This can be applied to a wide-range of use-cases, but we will focus on using a pipeline parameter to specify the target namespace.

Configure your pipeline parameters

First we will register a pipeline parameter in the “configuration” tab of the pipeline editor (only the Name is required):

See more details on how to provide parameters to piplines programatically in the wehbooks page.

Configure your manifest

In this scenario, we’re using a parameter to specify the manifest’s namespace. Edit your manifest so the metadata section contains:

# ... other keys
  namespace: '${ parameters.namespace }'
# other keys ...

Keep in mind this manifest can be stored in the pipeline, or in an external store such as GitHub.

When you go to run the pipeline by hand, you will see the following:

Parameterizing non-string keys

When parameterizing a YAML value that’s not a string (such as the replica count), you will need to explicitly convert the evaluated expression to the correct type.

If you were expecting the replica count to arrive in parameter replicas, you would write:

# ... other keys
  replicas: '${ #toInt( parameters.replicas ) }'
# other keys ...

More advanced parameterization

Please read the pipeline expressions guide.