This guide includes:
Kubernetes V2 Provider Overview
The new Kubernetes 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.
What To Expect From The V2 Provider
The new Kubernetes provider is very much a work in progress and is subject to changes in the UI and APIs. The user experience is still a work in progress and we’re interested in understanding real-world usage patterns as we iterate on the provider to optimize the experience.
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 red/black, highlander, rolling red/black 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
andconfigMaps
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:
-
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. -
Delete Manifests - Removes the manifests and their corresponding artifacts in kubernetes based on different types and labels.
-
Scale Manifests - Scales replica sets to a given static size.
-
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.
Setting Up The V2 Provider
Setting up the V2 provider is similar to the V1 Kubernetes configuration however we’ll need to change the provider flag in /opt/spinnaker/config/clouddriver-local.yml
to v2
. For example:
kubernetes:
enabled: true
accounts:
- name: k8s-v2
providerVersion: v2
kubeconfigFile: /opt/spinnaker/credentials/kubeconfig
We’ll also need to enable artifact handling in Spinnaker by setting a flag in /opt/spinnaker/config/spinnaker-local.yml
features:
artifacts:
enabled: true
And we’ll need to configure the Github artifact account in /opt/spinnaker/config/clouddriver-local.yml
artifacts:
github:
enabled: true
accounts:
- name: github
username: BOT_USERNAME
token: YOURTOKEN
Then restart Armory Spinnaker: service armory-spinnaker restart
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 flawlessly =)
but if it doesn’t, don’t hesitate to reach out: http://go.armory.io/chat