Over the past few years, containers have exploded in popularity. However, the effective use of this tech is often elusive at enterprise scale. At Pivotal, we’ve helped organizations achieve better business outcomes with containers, automation, and a modern engineering culture.
We’ve recently introduced a number of products to help enterprises realize improved outcomes with Kubernetes-native tooling. Pivotal Build Service is one such tool.
The Build Service helps development teams consistently build, maintain and update production-ready OCI images.
Build Service utilizes two noteworthy components: Cloud Native Buildpacks and homegrown K8s resource controllers. Cloud Native Buildpacks, jointly created by Pivotal and Heroku, create modular, build images in a consistent, reproducible way. They produce an artifact that can run anywhere.
The second component is kpack, a set of resource controllers for Kubernetes. That's the news of the day. (Need a quick tutorial on K8s resources? Check out the project docs.)
kpack: A K8s-native Way to Build and Update Containers
We wanted Build Service to combine the Cloud Native Buildpacks experience with the declarative model of Kubernetes, and extend the K8s workflow in an idiomatic fashion. With this goal in mind, we leveraged custom resource definitions to extended the K8s API. This way, we could use Kubernetes technology to create a composable, declarative architecture to power build service. The Custom Resource Definitions (CRDs) are coordinated by Custom Controllers to automate container image builds and keep them up to date based on user-provided configuration.
Pivotal’s commercial implementation of kpack comes via Pivotal Build Service. Use it atop Kubernetes to boost developer productivity. Build Service integrates kpack with other useful things like buildpacks and the Kubernetes permissions model. You also get an optional dedicated CLI called pb to help engineers work faster, and easier manage multi-tenancy with teams.)
Of course, we also value providing the community with a K8s native experience. This is why we have open-sourced the K8s-native components under the collective name kpack.
kpack presents a CRD as its interface, and users can interact with all Kubernetes API tooling including kubectl.
Why are We Open-Sourcing kpack?
Two reasons:
-
To provide Build Service’s container building functionality and declarative logic as a consumable component that can be used by the community in other great products.
-
To provide a first-class interface, to create and modify image resources for those who desire more granular control.
Here’s a closer look at the rationale for each.
Use kpack to Build Great Products
At its core, kpack automates the creation and update of container images that can be run anywhere. It’s important tech that Pivotal’s customers value. But what could the community do with kpack? Probably many things that we can’t even imagine.
Our goal is to transform the way the world builds software. So it stands to reason that tech like kpack should be open to everyone!
We’ve already seen the potential for kpack to deliver value in other use cases. riff will use kpack to build functions to handle events. The Cloud Foundry community plans to feature kpack as the new app staging mechanism in the Cloud Foundry Application Runtime. We can’t wait to see other clever ways kpack is used!
Use kpack When You Desire More Control
Kubernetes is a new standard, it has “emerged as the runaway choice in cloud-native infrastructure.” We’ve come to understand that companies are at different stages in their K8s journey. Each group within a company has a varying degree of desire to interact directly with K8s and use K8s tooling. Consequently, we wanted to make sure that Build Service “can meet you where you are.” This is why we have a first-class kubernetes experience to interact directly with CRDs.
Let’s Get Hands-On with kpack
How would you use kubectl with kpack today?
First, install kpack on your cluster. You can follow the docs hosted in the kpack repo. Or, if you have access, you can follow the steps in the Build Service docs.
kpack enables simple workflows like the following:
Apply an Image, Automatic Build, Built Image Available
Git Push, kpack Detects Change, Buildpack Rebuild
The best way to use kpack is on an Enterprise PKS cluster with Pivotal Build Service installed. However, kpack is kubernetes native; it should run on any supported Kubernetes cluster.
Give kpack a Try!
The beauty of kpack is its flexibility. You can now extend the value of an automated build mechanism for all kinds of use cases.
Ready to learn more? Check out these links.
-
Go to the kpack repo for bits, docs and much more. Star it to stay in the loop!
-
Watch TGI Kubernetes 091 with Joe Beda, featuring kpack.
-
Request alpha access to Build Service via this form, or by reaching out to your account team. Once you’ve gained access, you’ll see the bits on up PivNet.
-
Register for SpringOne Platform, October 7-10 in Austin! It’s a terrific conference if you’re keen to learn more about modern engineering practices. We’ll a breakout session on this topic: Pack to the Future: Cloud-Native Buildpacks on k8s. We’ll have demos at the Pivotal booth as well.
So give kpack a spin, and see how it can make your workflows easier!
