Parameterize Kubernetes Manifests

Inject parameters into your Kubernetes manifest as it is deployed.

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, register a pipeline parameter in the “configuration” tab of the pipeline editor (only the Name is required):

Parameterize Kubernetes Manifests - 图1

See more details on how to provide parameters to pipelines programmatically in the webhooks page.

Warning: there are several reserved parameter keys (names) that cause unexpected behavior and failures if overwritten by a pipeline parameter definition. See the list of reserved parameter and evaluate variable key names .

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:

  1. # ... other keys
  2. metadata:
  3.   namespace: '${ parameters.namespace }'
  4. # 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:

Parameterize Kubernetes Manifests - 图2

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:

  1. # ... other keys
  2. spec:
  3.   replicas: '${ #toInt( parameters.replicas ) }'
  4. # other keys ...

More advanced parameterization

Please read the pipeline expressions guide .

Last modified May 13, 2021: docs(migrate): add remaining Extending Spinnaker pages (3835a79)