Patch Kubernetes Manifests
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:
(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.)
Specify the resource to patch
- Start by selecting the Patch (Manifest) stage from the stage selector:
- 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
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:
Note: Make sure that the Artifact Account field matches an account with permission to download the manifest.
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-causeannotation. If the annotation already exists, the contents are replaced.
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 .