[Sandbox] ko

[imjasonh]

Application contact emails

jason@chainguard.dev
jonjohnson@google.com

Project Summary

Easy and secure container builds for Go applications

Project Description

ko is a tool designed to make building containers for Go applications as simple as possible, without Dockerfiles, or Docker, or the associated privilege required. ko simply runs go build in your environment and uses OCI registry operations to add that binary to a base image directly in the registry.

Because ko focuses only on the very common Go use case, it can optimize for speed better than alternatives like Docker and Buildpacks, and can rely on Go's features to provide thorough and reliable module-level SBOMs by default at build-time. By focusing on Go, ko can also provide multi-platform builds easily without emulation, simply relying on Go's robust cross-compilation features.

Since its inception as a tool to help Knative and Tekton developers, it has since broken out and become used by many other projects, including Sigstore, Kyverno, Shipwright, and AWS's Karpenter project. It's also integrated as a Skaffold builder directly. It boasts 5400+ GitHub stars, and doesn't show any signs of slowing down.

Org repo URL

https://github.com/ko-build

Project repo URL

https://github.com/ko-build/ko

Additional repos

These projects are not yet included in the org, but would be contributed if CNCF Sandbox application was accepted:

• https://github.com/imjasonh/setup-ko
• https://github.com/chainguard-dev/terraform-provider-ko

Website URL

https://ko.build

Roadmap

https://github.com/ko-build/ko/blob/main/ROADMAP.md

Roadmap context

No response

Contributing Guide

https://github.com/ko-build/ko/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/ko-build/ko/blob/main/code-of-conduct.md

Adopters

No response

Contributing or Sponsoring Org

https://google.com

Maintainers file

https://github.com/ko-build/ko/blob/main/CONTRIBUTING.md

IP Policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

Ko has been successful so far in getting adopted mainly by word of mouth, by engineers who have used or built other tools recommending it to other projects. This has worked so far, but isn't exactly scaleable if ko wants to take over the world. It's also, historically, been seen as a "google tool", which makes sense given its history and ownership. This might be holding back its adoption, and its ability to attract contributors. In reality, the project is very independently maintained, by maintainers inside and outside of Google. Its roadmap is decided by these maintainers, not by any Google strategy.

My hope is that with CNCF's help in outreach and positioning, we can unlock the next phase of growth for the project, both in terms of adoption and attracting contributors who want to help steer the direction of the project.

Benefit to the Landscape

CNCF's landscape doesn't have many build tools. Buildpacks is the main one I can think of. Having more diverse tools like this can give end users more diverse options when looking for a solution.

Cloud Native 'Fit'

Ko sits right at the crossroads of two major Cloud Native technologies: Go and Containers. End users hoping to adopt Cloud Native will benefit from ko's ease of use and seamless developer experience.

A lot of CNCF projects are Kubernetes add-ons and controllers, which could benefit from adopting ko, as projects like Kyverno have benefitted from adopting ko.

Cloud Native 'Integration'

Ko has deep integration with Kubernetes. It has some basic YAML templating that allows users to specify on the Go importpath of their application in YAML, and ko will replace that with the equivalent built image reference by digest. It can also directly kubectl apply that YAML if needed, and can even build images directly into KinD clusters for local development.

Cloud Native Overlap

CNCF Buildpacks is the main project that overlaps, as both are build tools that produce OCI container images.

Though they solve very similar problems, they solve them in distinct enough ways, and with different enough goals, that I think there's plenty of room for them to coexist. Buildpacks aims to provide a good experience for any language, while ko only supports Go. By focusing on Go though, ko can take advantage of optimizations that can make it an overall better experience for Go developers (IMHO).

Similar projects

Outside of CNCF, the whale in the room is obviously docker build, which is very widely used, and its ease of use has been pivotal in the rise of containers across the Cloud Native ecosystem.

As with Buildpacks, ko solves a much smaller problem than docker build, and as such can optimize things much better for exactly the use case it aims to solve. So many Cloud Native projects and applications are written in Go, and could benefit from being built more securely and efficiently with ko.

Product or Service to Project separation

ko is not related to any existing paid product or service, at Google or elsewhere. It could be integrated as a build solution into a product, by using ko as a library like Skaffold does, but this would not require any input or changes on ko's part, and is already possible today. I have no knowledge of any such plan to do that, at Google or elsewhere.

Project presentations

N/A

Project champions

No response

Additional information

No response

[amye]

Previous application was accepted, this is a duplicate.