Kubernetes on Spinnaker

Annotation-Driven UI

Mon, 01 Jan 0001 00:00:00 +0000

This guide describes how to surface information about your Kubernetes resources in Deck’s details panel using Kubernetes annotations. These annotations can be text or HTML and can include templated values that are populated when the annotation is rendered by the browser.

Example Usage

Here’s a quick example of usage that will add a “Pod Info” section to the details panel for a pod:

kubectl annotate pod my-prod-pod-v000 \
  pod-info.details.html.spinnaker.io="<a href='https://internal-elk.net/{{"{{ name "}}}}'>Internal Logs Service</a>"

Here’s how this annotation will render in Spinnaker’s UI:

Configure Automated Rollbacks in the Kubernetes Provider

Mon, 01 Jan 0001 00:00:00 +0000

There are clear benefits to having your stored manifests (in Git, GCS, etc…) match as closely as possible to what’s running in your cluster: you have auditability, versioned changes, and a high confidence in what code you have running. However, in some cases, pushing changes from someplace like GitHub through your build system all the way to production can simply take too long, and an escape hatch is needed when something has gone seriously wrong. Automated rollback is that escape hatch.

Best Practices for the Kubernetes Provider

Mon, 01 Jan 0001 00:00:00 +0000

The Kubernetes provider enables a wide variety of ways to deploy your manifests into Kubernetes clusters. This page provides best-practices for doing so.

Deploy Docker images by digest

If your registry exposes image changes by digest , we recommend deploying images by their digest rather than tag, e.g. gcr.io/my-image@sha256:95ff090... rather than gcr.io/my-image:v1.

The digest is a content-addressable way to reference your image, because it’s derived from the hash of the image contents. If your manifest points to an image by its digest, you know that each time it’s deployed it points to the same contents (binary, dependencies, config, etc…). If you rely on the tag, deploying the same Manifest twice can have different results.

Deploy Helm Charts

Mon, 01 Jan 0001 00:00:00 +0000

Spinnaker surfaces a Bake (Manifest) stage to turn templates into manifests with the help of a templating engine. Helm relies on the helm template command. For more details, see helm template --help.

>This stage is intended to help you package and deploy applications that you own, one that are actively developing and redeploying frequently. It is not intended to serve as a one-time installation method for third-party packages. If that is your goal, it's better to call `helm install` once when bootstrapping your Kubernetes cluster. Make sure that you have configured [artifact support](/docs/setup/other_config/artifacts/) in Spinnaker first. All Helm charts are fetched/stored as artifacts in Spinnaker. Read more in the [reference pages](/docs/reference/artifacts).

Configure the Bake (Manifest) stage

When configuring the Bake (Manifest) stage using a Helm (Helm 2 or Helm 3) render engine, you can specify the following:

Deploy Kubernetes Manifests

Mon, 01 Jan 0001 00:00:00 +0000

This guide shows the basics of how to deploy a Kubernetes manifest using the Kubernetes provider .

There are two main steps:

Specify which manifest to deploy

This is required.
Override artifacts in the manifest

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

Specify your manifest

Depending on your needs, there is more than one way to specify the manifest that you want to deploy:

Manage Traffic Using Kubernetes Manifests

Mon, 01 Jan 0001 00:00:00 +0000

This guide shows the basics of how to manage traffic during deployments using the Kubernetes provider . This includes automatically attaching a Service to a workload during deployment, and defining pipelines to perform blue/green deployments.

Attach a Service to a Workload

Kubernetes manages the relationship between Pods and Services using Labels and Selectors . Spinnaker acknowledges this relationship with the blue load balancer icon on a workload as shown here:

You can also tell Spinnaker which Service objects a workload should be associated with for its lifetime using the traffic.spinnaker.io/load-balancers annotation. To try this out, do the following:

Parameterize Kubernetes Manifests

Mon, 01 Jan 0001 00:00:00 +0000

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):

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

Patch Kubernetes Manifests

Mon, 01 Jan 0001 00:00:00 +0000

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

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

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

Field	Value
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.

Rollout Strategies

Mon, 01 Jan 0001 00:00:00 +0000

This guide describes how to take advantage of the Kubernetes provider’s first-class support for common rollout strategies, including dark, highlander, and blue/green rollouts.

The implementation of these rollout strategies currently leverages Spinnaker’s existing traffic management strategy and is valid for ReplicaSets only. See traffic management for more information.

Rollout Strategy Options

As of version 1.14, you will notice a Rollout Strategy Options section in the Deploy (Manifest) stage. When enabled, these configuration options allow you to associate a workload with one or more services, decide whether the workload should receive traffic, and determine how Spinnaker should handle any previous versions of the workload in the same cluster and namespace.

Run Job (Manifest) Stage

Mon, 01 Jan 0001 00:00:00 +0000

The Run Job (Manifest) stage can be used to execute a Kubernetes Job as part of your pipeline. This stage will deploy a Job manifest and wait until it completes, allowing you to gate your pipeline’s continuation on the job’s success or failure.

For example use cases, check out this post on the Spinnaker blog!

Viewing execution logs

As with any job runner, logs are the primary form of feedback and it’s important that viewing them is a first-class experience within Spinnaker. Since users of Spinnaker are all at various stages of Kubernetes adoption we’ve provided 2 ways to view logs within Spinnaker.

Use Kustomize for Manifests

Mon, 01 Jan 0001 00:00:00 +0000

Kustomize is a tool that lets you create customized Kubernetes deployments without modifying underlying YAML configuration files. Since the files remain unchanged, others are able to reuse the same files to build their own customizations. Your customizations are stored in a file called kustomization.yaml. If configuration changes are needed, the underlying YAML files and kustomization.yaml can be updated independently of each other.

To learn more about Kustomize and how to define a kustomization.yaml file, see the following links: