Introducing kpack, a Kubernetes Native Container Build Service

August 20, 2019 Matthew McNew

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:

  1. 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.  

  2. 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.

So give kpack a spin, and see how it can make your workflows easier!

About the Author

Matthew McNew

Matthew works as a Software Engineer at Pivotal. He currently contributes to the Build Service team. Matthew enjoys writing obscure testing libraries and forgetting about computers on traveling expeditions. He lives in Chicago with one house plant.

Previous
A Technical Comparison of Popular API Gateways with Apigee Edge, Spring Cloud Gateway, and Ocelot
A Technical Comparison of Popular API Gateways with Apigee Edge, Spring Cloud Gateway, and Ocelot

Next
How to Trim Your API Access Costs with a Cache
How to Trim Your API Access Costs with a Cache