Spinnaker on Minikube using Helm v2

Get Spinnaker up and running quickly

I have been using Spinnaker for about 3 years now, from when the components where installed via scripts, to Halyard, and now Helm. I ran into some issues while trying to provision Spinnaker to Minikube and I’ve got a working example here that I’d like to share with all of you.

This post assumes your tiller service account has full admin rights at the cluster level. Here’s an example of how you would set that up.

kubectl apply -f   https://github.com/airwavetechio/helm/blob/master/rbac-clusterrole-airwave-tiller.yml

Next thing, I created a repo.

airwavetechio/helm-spinnaker

My repo has been copied from the original here:

helm/charts/stable/spinnaker

In my repo, I’ve made version updates to redis, minio and haylyard while providing a default set of different values depending on what I wanted to test. My goal was to get Spinnaker up and running on minikube v1.5.2 as quickly as possible without any hiccups.

helm install --name spinnaker -f values-airwave-persistence.yml --namespace airwave-deploy --tiller-namespace airwave-tiller . --timeout 1200

This command says hey Helm, install “spinnaker” using the values from the file values-airwave-persistence.yml to the airwave-deploy namespace. The tiller service is in the namespace airwave-tiller and use . because we are in the local directory. Set the timeout to 20 minutes.

Octant view of the installation job

After a few minutes, you will see your command line move.

A lot more text will be shown

Connection information at the end

After about 10 minutes, you will see everything is up.

Referencing the connection information, you will need to connect to the deck.

kubectl get pods --namespace airwave-deploy -l "cluster=spin-deck" -o jsonpath="{.items[0].metadata.name}"

kubectl port-forward --namespace airwave-deploy <deck podname> 9000

Open your browser to http://127.0.0.1:9000

And boom, Spinnaker!

Persistence on

Aside from Spinnaker deploying to the airwave-deploy namespace, we have a bunch of Persistent Volume Claims here. Under the hood, these will mount to your VM at /tmp/hostpath-provisioner/pvc-*/

PVC view in Octant

So what’s up with Persistence on? Let’s test it. Go back to the Spinnaker web UI and create an application. Put any text you’d like.

Applications > Actions > Create Application

After you have created an Application, go back into your command line, and restart minikube.

minikube stop

minikube start

What’s that error???

After numerous attempts at this, I waited an average about 10 minutes before everything came back up. Once it does, set up the port forward again and see if your Application is still there. That’s persistence.

Under the covers, it’s because minikube persists all dynamically provision volume claims.

If you really want to see for yourself, delete spinnaker, remove the mount to host, and reinstall it with this command and try this all over again.

helm install --name spinnaker -f values-airwave-no-persistence.yml --namespace airwave-deploy --tiller-namespace airwave-tiller . --timeout 1200

Uninstall

helm delete spinnaker --tiller-namespace airwave-tiller --purge

Troubleshooting Tips

• Sometimes I noticed that after waiting 10 minutes, some pods don’t start. The step that has helped (even in production) is to just delete the pod. It should restart normally. If it doesn’t look at the logs. After some investigative work, you should be able to figure out what’s wrong.
• Patience is your best friend. Sometimes things look like they aren’t working, just wait a little long, no joke!

Hope you were able to learn a thing or 2 and thanks again for reading!