Patch Kubernetes Manifests

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

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.

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

There are a few steps:

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:
  • Account

    The Spinnaker account that manages the Kubernetes cluster

  • Namespace

    The Kubernetes namespace that your resource is located in

  • Kind

    The Kubernetes Kind of your resource e.g. deployment, service etc

  • Name

    The name of your Kubernetes resource

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:

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:

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

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

Now, 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.