Another tool to help you release software
Skaffold is a command line tool that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application. It also provides building blocks and describe customizations for a CI/CD pipeline.
Having deployed software for many years, I figured I’d give it a spin and see what it has to offer and how it is different from other tools/solutions.
Some back story…
I have been deploying software for a long time. I remember taking a floppy disk (3.5" not the 5.25" kind) and running a small program at over 1,000 PCs to get our PCs Y2K ready, by hand. That was almost 20 years ago if you can believe it. Now, you can deploy entire environments with the latest version of your production releases all with one button without even touching anything other than a keyboard.
I’ve been catching up on the latest tools by applying them to my projects, and one of those catch ups has been to find easier ways to deploy software. At my last place, this was our development flow:
We had manual intervention in between some of the steps but we automated what we could. This worked for us because we had a smaller team but there was quite a bit of management overhead running Spinnaker a huge learning curve with Travis and Docker contexts. Here comes Skaffold.
Skaffold handles most of the steps shown above. The main features are:
Fast local Kubernetes Development — You don’t have to deal with build queues or cloud systems spinning up VMs for your build environment.
Skaffold projects work everywhere — As long as others have Skaffold installed, all one needs to do is clone a repo and run a
skaffold.yaml — a single pluggable, declarative configuration for your project
Lightweight — No server-side components, minimal management overhead. Things are opinionated (strict) so deviating from the plan.
Like with other posts, we have some sample code to look at but first, let’s get set up.
- Install skaffold
- Have a working minikube / kubectl setup
Official Installation docs are at skaffold.dev
choco install skaffold
Here is our sample code:
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
If you have your pipelines and configuration all set up, all you need to run is either:
skaffold dev = for continuous hot reloading while you work
skaffold run = a one time build and deployment job
The reason this works is because of a few things. Let’s first look at the skaffold.yml file.
We are telling Skaffold to use the
_k8s/deployment.yml file to deploy the artifact
If we look at the DockerHub repo, there wasn’t an image pushed there. What happened? I thought it worked before? This is because by default skaffold won’t push to a repo if the current Kubernetes context connects to a remote cluster. Since we are using minikube, I made some changes to the .yml file
skaffold run again
So there you have it, skaffold not only builds locally but pushes to your artifact repo and deploys the artifact to your cluster. You can templatize your build tags to suit your needs so you don’t have to continuously keep track of versions, and who authored them.
skaffold dev you can continuously work, build and deploy so you can have the latest efforts in your target environment.
Would I run this with my team? With the right tagging and infrastructure monitoring in place, I would. As long as there was a way to know which version did what, and how to roll back (which would be taken care of with other monitoring utilities that you should have in Prod). In the past, we didn’t have frequent releases so we tagged everything manually. When there were bugs, it was a pain to re-release everything again. This process takes care of a lot of the building and deploying wait and lag that comes with a centralized cloud-based build system while treating every deploy equally.