Deploy Applications to Kubernetes

Overview of Spinnaker’s Kubernetes V2 Provider

The Kubernetes V2 provider is centered on delivering and promoting Kubernetes manifests to different Kubernetes environments. These manifests are delivered to Spinnaker using artifacts and applied to the target cluster using kubectl in the background. Currently, there is support to supply artifacts through Git, GCS and Google Pub/Sub. The V2 provider manages the version of the artifacts deployed to Kubernetes by appending a string such as v421 to the resource that was deployed to Kubernetes. This allows for easy rollbacks and management of resources.

Current limitations

• The only supported services for artifact delivery are Github, GCS, or Google Pub/Sub. S3, SQS, and SNS are currently not supported.
• Native Spinnaker deployment strategies such as blue/green, highlander, rolling blue/green deployment are not supported. If these strategies are desired consider using the deployment object in your manifests.
• While you’re able to deploy all Kubernetes resource types, the V2 provider only considers containers and configMaps for binding to the deployed manifest. secrets and other resource types are coming soon.
• You cannot manually trigger the pipeline, you have to use Github triggers.

Available manifest-based stages

There are 4 stages that are available:

1. Deploy Manifest - Uses kubectl apply to deploy a manifest. Spinnaker will wait until the manifest stabilizes in the Kubernetes cluster or reach the expected capacity on healthy pods.

2. Delete Manifests - Removes the manifests and their corresponding artifacts in kubernetes based on different types and labels.

3. Scale Manifests - Scales replica sets to a given static size.

4. Rollback Manifest - Allows rollback of a given Kubernetes artifact by a given number of versions. Helpful in cases of a failed deployment or failed manual QA.

Creating a Kubernetes V2 pipeline

Configuring the pipeline trigger

We’ll begin by creating a pipeline that is triggered from Kubernetes artifacts and delivered through Github. Below we’ll define two artifacts that will be deployed as Kubernetes manifests: deployment.yml and config-map.yml which are valid Kubernetes manifests. Make sure to select the source as Github.

After configuring the artifacts we’ll need to associate them with a Github trigger so the pipeline is triggered whenever there are modifications pushed to Github. For example, the pipeline below will only trigger when either deployment.yml or config-map.yml are modified and pushed to the repository. If the manifest isn’t modified it’ll use the latest version that was deployed.

Note: If you haven’t already, you’ll need to configure Github webhooks for your Spinnaker instance.

Configuring the config map manifest delivery

We’ll configure the configMap to be deployed first. Add a Deploy (Manifest) stage to your pipelines.

Once you’ve added the stage, select Artifact from the Manifest Source below and it will allow you to choose one of the expected artifacts that we configured in the previous section. Choose config-map.yml and hit save. Spinnaker will deploy the chosen artifact but append a version to the name of the artifact. For our example config map. So for the name k8-v2-config-map it will appear in the Kubernetes cluster with k8-v2-config-map-v001.

Configuring deployment manifest delivery

Next we’ll configure a new Deploy (Manifest) stage to deploy the deployment.yml manifest. This manifest references our config-map as a volume and it’s source will be replaced by the versioned artifact deployed in the previous step: k8-v2-config-map-v001. So if our deployment.yml contains the following:

volumes:
  - name: k8-config
    configMap:
      name: k8-v2-config-map

the name will be replaced with the properly versioned artifact:

volumes:
  - name: k8-config
    configMap:
      name: k8-v2-config-map-v000

Executing the pipeline

Your final pipeline should look similar to the one below.

In order to execute your pipeline the first time you’ll need to edit both the config-map.yml and deployment.yml, commit the changes to git and push the changes to Github. The pipeline should trigger and execute.