I’m excited to announce a new open source Kubernetes CLI plugin for building container (OCI) images. This CLI is optimized for developers and implements a familiar UX within kubectl. It utilizes a powerful open source component called BuildKit to build Dockerfiles into images directly inside your Kubernetes cluster. Let’s take a closer look at how it works.
Get to the source: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
The Inner-Loop
As a developer, a large part of your time spent developing software is in the “tight” loop where you write some code, test it and iterate. This takes place before you submit a finished piece of work for peer code review and begin the CI automation process. It is essential this loop be fast and frictionless. If the loop takes 30 minutes to complete, you only get 10-12 times a day to write code, compile it and test it. By reducing that time to three minutes, you can potentially test out your code more than 100 times a day. That’s a huge productivity boost not spent doing “context switches” while you’re waiting for your code to compile.
This inner-loop part of the development process tends to be very “personal.” Different developers will approach this with different perspectives. Some love IDEs, some debate vim vs. emacs and so on. I don’t think there will ever be a one-size-fits-all solution in this space, so ultimately the key is to provide choice and elegant tools for developers. Most developers working on cloud native projects will at some point during their inner loop, build a container (OCI) image so they can test with Kubernetes. Wouldn’t it be nice if you could do this entirely within a Kubernetes-centric workflow?
A key feature of this new tool is that it strives to make the images you build immediately available in the container runtime of your Kubernetes cluster so that you can “bounce” your pod(s) to pick up a freshly built image with virtually no overhead.
How This CLI Works
When you run the “build” verb, the CLI checks to see if you have an existing builder pod running in your Kubernetes cluster, and if not, creates a new one with default values. You can create the builder explicitly for more advanced use cases. The builder supports the two most popular container runtimes–containerd and dockerd–and will auto-detect the correct runtime in most cases. By default it assumes you’re a developer, and it aims to make the images you build show up in the container runtime on the cluster, so you do NOT have to push to a registry to use the images. If you have a small multi-node cluster where you want to build images, and then deploy them in the same cluster, you can scale the number of builders to match the number of nodes. Each of the images will be replicated onto every node which has a builder. This lets you test Kubernetes workloads using your new image.
For more advanced use cases you can run the builder as “rootless” (not building or storing the image in the container runtime on the Kubernetes nodes) and push images to a registry if that better suits your workflow. You’ll also need to push images to a registry if you’re creating multi-architecture images.
For more details, check out the docs in the repo over on GitHub: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl#buildkit-cli-for-kubectl
Get Involved
This project wouldn’t have been possible without the awesome work by others in the open source community. In particular, Kubernetes and BuildKit. While the former is well known, the latter may not be as well known, so head over to their repo and check it out.
This project is just getting started. We’re starting it at version “v0.1.x” so we can get input from the broader community before we bump it “1.0.”
Give it a try on your Kubernetes environment today: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl#getting-started
