Announcing the Release of kpack 0.4.0

October 11, 2021 Beena More

Kpack, a Kubernetes-native way to build and update containers, is getting an update with the 0.4.0 release, available today. It provides an automated, on-cluster build experience using Kubernetes primitives and the Cloud Native Buildpacks project.

Kpack is an open source project initiated by VMware in 2019. Since then, it has achieved a thriving and growing community ecosystem:

  • 500+ GitHub stars
  • 40+ contributors since inception, including industry leaders like SAP and Bloomberg
  • Over 3,000+ repo clones in August 2021
  • 128 PRs opened year to date

Since its inception, the project has shipped several minor releases. This latest, 0.4.0, marks a special milestone. Since the 0.3.0 release, the core kpack team has gained many new and active contributors have joined the core kpack team; coupled with our community-led approach, this has helped propel the latest round of growth and innovation, including investment in a new API version.

Kpack 0.4.0 introduces a new API version (v1alpha2), which delivers on the project's short-term roadmap and allows us to respond to feedback and feature requests from the community in the future. To ensure a smooth migration, the project will continue to support v1alpha1. 

Here’s what users can look forward to when they unbox kpack 0.4.0!  

Easier discovery and configuration of the `kp CLI`

These features are designed to reduce the challenges associated with getting started with `kp` so that more people can enjoy the benefits of the CLI when using kpack compared to `kubectl`.

  • Easy installation with Homebrew: Popular Mac and Linux installer Homebrew now supports kp CLI, in response to OSS community feedback.

  • In order to use certain features of `kp` that manipulate an image registry, users currently have to create a configmap that provides the configuration necessary for `kp` to communicate with the desired registry. Users can now create this configuration using `kp` itself.

Support for signed container images via Cosign 

Attestation for the origin of images is a common security concern for anyone adopting containers. As industry sentiment on the matter evolves, so too do the technical solutions attempting to deliver the corresponding outcome. Based on community feedback, the kpack project pivoted to Cosign from the existing Notary integration to attest the container image origin. A few of the reasons we shifted to Cosign are its support for image relocation; more-active community; regular PRs; easier, faster startup; and simpler UX overall. The v1alpha1 API will continue to support Notary, but v1alpha2 will not.

Support for Kubernetes service binding specifications

Kpack users often want to pass custom configurations as part of the build process, for example, settings.xml configurations for maven apps. Kpack previously used the Cloud Native Buildpack service binding specification. Following the industry trend toward leveraging native Kubernetes concepts, kpack will transition to using the Kubernetes service binding spec.

Support for using remote registries to store cache layers

Caching image layers from previous builds provides a powerful performance optimization. Previously, users had to use persistent volumes. With this release, kpack adds more image caching options. Kpack users now have the flexibility to store an image cache in either remote registry or persistent volumes. Additionally, the entire container image can be used as a cache. 

Run build pods on dedicated worker nodes

As part of building an image, kpack spins up a pod to execute the container build. However, the node that hosts this pod is chosen by the Kubernetes Scheduler. Community members who operate large installations require stricter control over the node assignment for these build pods. With the 0.4.0 release, operators have the ability to apply affinity and tolerations when configuring their image resource. 

Try kpack for container build automation

We are grateful for contributions from the community and are eager to release them to our users. Whether you’re an experienced user or new to kpack, here are a few ways to engage with the project:

  • Try – If you are new to kpack, check out the kpack quick start guide 

  • Check out – Go to the kpack repo for the bits; star it to stay in the loop

  • Contribute – If this excites you, come join our kpack community! Ask any questions you might have on #kpack on the Buildpacks Slack. Listen in, participate, and influence the kpack roadmap in our weekly working group meetings every Wednesday at 10 AM Eastern Time.

Previous
VMware Tanzu Build Service 1.3 Is Now Available
VMware Tanzu Build Service 1.3 Is Now Available

We're excited to announce the general availability of version 1.3 and with it, “bring your own UBI base OS ...

Next
Accelerate Your Container Adoption with VMware Tanzu Build Service 1.1
Accelerate Your Container Adoption with VMware Tanzu Build Service 1.1

VMware Tanzu Build Service 1.1, now generally available, adds image signing capabilities, CLI enhancements,...