Patch Kubernetes Manifests

Update a Kubernetes resource in place using the Patch Manifest stage.

This guide shows the basics of how to update a Kubernetes resource in place using the patch manifest stage for the Kubernetes provider provider.

There are a few steps:

• Specify which manifest to patch

• Specify the patch content

• (Optional) Override artifacts in the patch content

  Optionally, you can override some artifacts (as fields) at run time (for example, which Docker image to use.)

• (Optional) Override patch specific options

Specify the resource to patch

1. Start by selecting the Patch (Manifest) stage from the stage selector:

1. To identify the Kubernetes resource to patch, specify the following required fields:

Specify your patch content

The patch content is similar to a manifest in the Deploy (Manifest) stage. However, unlike the deploy manifest, this does not have to be the full resource manifest but only the portion you want to patch.

Depending on your needs, there is more than one way to specify the patch content:

• Statically: directly in the pipeline
• Dynamically: bound at runtime using an artifact

Specify patch content statically

You can enter the patch content YAML by hand. For instance, if you want to patch your manifest to add a new label, you will specify the following:

metadata:
  labels:
    foo: bar

Notice that by selecting Text as the Manifest Source, we get to enter the manifest YAML by hand.

Specify patch content dynamically

Like the Deploy (Manifest) stage , you can also reference an artifact as the source if you are storing your patch content externally. The artifact must be a text file containing the patch content.

You can also set up the pipeline to trigger based on changes to the patch content:

• Consuming GitHub Artifacts
• Consuming GCS Artifacts

Assuming you have declared an expected artifact upstream to your Patch (Manifest) stage, you can reference it in the Patch configuration:

Notice that by selecting Artifact as the Manifest Source, we get to pick which upstream artifact to deploy.

Note: Make sure that the Artifact Account field matches an account with permission to download the manifest.

Override artifacts

When patching with a strategic or merge strategy, the Patch (Manifest) stage also allows you to override artifacts like in the deploy manifest stage.

For instance, say you have a pipeline with a Patch (Manifest) stage with the following patch content:

spec:
  template:
    spec:
      containers:
        - name: my-container
          image: gcr.io/my-project/my-image

If your pipeline was triggered due to a new Docker image tag being pushed to your Docker registry (say my-image:2.0), Spinnaker will override the version of the container image with the new version:

#...rest of manifest
containers:
  - name: my-container
    image: gcr.io/my-project/my-image:2.0

For more information on how this works, check out the binding artifacts docs .

Specify Patch Options

You can also specify the following options:

• Record Patch Annotation

  Defaults to true. When selected, the patch operation including the patch content will be recorded on the patched resource as the kubernetes.io/change-cause annotation. If the annotation already exists, the contents are replaced.

• Merge Strategy

  • strategic: This is the default. It is a customized version of JSON merge patch specific to Kubernetes that allows Kubernetes objects to be either replaced or merged based on the object struct tags. It is particularly useful when you want to add a new item to a list (e.g. a new annotation, label, or even a new container to a pod spec) instead of replacing the list.

  • json: This will patch the manifest using a standard RFC 6902 JSON patch .

  • merge: This will patch the manifest using RFC 7386 JSON Merge Patch .

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