This guide includes:
- Kubernetes V2 provider overview
- What to expect (and what not to) from the Kubernetes V2 provider
- Setting up the V2 provider
- Creating a Kubernetes V2 manifest based deployment pipeline
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.
- 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
configMapsfor binding to the deployed manifest.
secretsand 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 applyto 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
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
features: artifacts: enabled: true
And we’ll need to configure the Github artifact account in
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:
config-map.yml which are valid Kubernetes manifests. Make sure to select the source as
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
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
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
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