Closed aaron-prindle closed 3 weeks ago
@amye could you please add the TAG Runtime label (in addition to TAG App Delivery)?
Hi @angellk and @amye, currently this application is a part of the next batch of CNCF Sandbox Application Reviews which is slated for April 9th (https://github.com/orgs/cncf/projects/14). I just wanted to confirm if there was anything additional that should be done for Kaniko prior-to/during-this CNCF Sandbox Application review? Want to make sure we have done everything necessary for the process. Currently my understanding is that there is nothing else to do, just want to confirm - thanks!
@aaron-prindle activity seems to be dropping off https://github.com/GoogleContainerTools/kaniko/graphs/contributors?from=2023-07-19&to=2024-07-23&type=c is there going to be continuing interest/investment to help the massive set of end users who depend on it? (given the usage/stars etc)
Hi @dims!
activity seems to be dropping off https://github.com/GoogleContainerTools/kaniko/graphs/contributors?from=2023-07-19&to=2024-07-23&type=c
Can you explain the rationale for activity seems to be dropping off
? Currently the GoogleContainerTools/kaniko project is staffed with maintainers, doing regular project releases, reviewing and merging community contributed PRs, and responding to + triaging inbound Github issues. Activity on the project in 2024 is line with or above 2023, 2022, and 2021 so trying to understand what the dropoff is referring to?
NOTE: these are for the merged PRs vs inbound PRs which would have more contributors as not all are accepted
The numbers there seem comparable to other projects that were accepted to the CNCF IIUC from a cursory glance although I might be missing some specific metrics related to activity or contributors.
is there going to be continuing interest/investment to help the massive set of end users who depend on it? (given the usage/stars etc)
Yes, there is going to be continued interest/investment in GoogleContainerTools/kaniko to help the massive set of end users who depend on it.
Hi @aaron-prindle! As part of the TAG-Runtime review, do you have a recent presentation (slides) you or the project team has done talking about the project, history, community, roadmap, etc. ? This would be very helpful as a summary as we do our research, if you do have one. Something that if you were to present to a TAG about the project you would be able to talk to and use. Also, do you have a recent demo video? The one linked on your github is 3 years old. Thanks!
@aaron-prindle We have the following additional questions for the project team. Thank you in advance!
Date | Aug 6, 2024 |
---|---|
Project Name | Kaniko |
TAG | TAG Runtime |
Presentation | No |
Project Leads Presenting | N/A |
TAG Leadership Reviewers | Stephen Rust |
https://www.youtube.com/watch?v=EgwVQN6GNJg
https://github.com/GoogleContainerTools/kaniko/blob/45a6d2db9fc4338877063ed7d7de71ee242bf151/docs/demo.gif
kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster.
kaniko doesn't depend on a Docker daemon and executes each command within a Dockerfile completely in userspace. This enables building container images in environments that can't easily or securely run a Docker daemon, such as a standard Kubernetes cluster.
This is a general TAG-Runtime and TAG-App Delivery project, no specific working group alignment.
Kaniko’s first release was May 17, 2018. Kaniko has 14.4k stars on github and 1.4k forks.
kaniko is meant to be run as an image: gcr.io/kaniko-project/executor. It is primarily written in GO. It can run standalone, but is designed to be run within Kubernetes as a pod. Specify a service account, and create a pod spec to run the kaniko builder. The interface and UX is through running the image and specifying command line arguments, for example in a Pod spec.
Example Execution:
apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
\- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args:
\- "--dockerfile=\<path to Dockerfile within the build context\>"
\- "--context=gs://\<GCS bucket\>/\<path to .tar.gz\>"
\- "--destination=\<gcr.io/$PROJECT/$IMAGE:$TAG\>"
volumeMounts:
\- name: kaniko-secret
mountPath: /secret
env:
\- name: GOOGLE\_APPLICATION\_CREDENTIALS
value: /secret/kaniko-secret.json
restartPolicy: Never
volumes:
\- name: kaniko-secret
secret:
secretName: kaniko-secret
Roadmap was added in February 2024:
https://github.com/GoogleContainerTools/kaniko/blob/main/ROADMAP.md
The current list of maintainers shows 3 all from google. There are \~18 contributors per year of contributors doing at least 1 commit.
Security issues are handled through a documented intake process.
Kaniko slack channel is fairly low volume with low interaction: https://app.slack.com/client/T09NY5SBT/CQDCHGX7Y
There are 653 open issues (oldest 2018).
There are 27 open pull requests (oldest 2023).
Requires Google CLA in order to contribute.
As there is one primary vendor in a vendor provided repo, if that vendor were to step away the project would likely have trouble continuing.
Kaniko has a long 6+ year history as a rootless, secure, container build tool. There are concerns about maintainer diversity (currently single vendor), and the ability for the community to perform releases without a vendor. Maintenance burden for Dockerfile syntax changes, security issues, and version compatibility is consistent but not unusual. We are looking forward to the project’s response to our previous questions, and addressing the key feedback above, and would recommend moving forward with the sandbox application given those responses.
TAG Contributor strategy has reviewed this project and found the following:
This review is for the TOC’s information only. Sandbox projects are not required to have full governance or contributor documentation.
@aaron-prindle Thank you so much for your application to the CNCF, at this time the TOC will not be moving the Kaniko Sandbox application to a vote.
We would like to see this project apply at Incubation level with:
Application contact emails
aprindle@google.com
Project Summary
Daemonless, easy and secure Dockerfile container builds on Kubernetes
Project Description
Kaniko is a tool designed to build container images from a Dockerfile, inside a container or Kubernetes cluster. It does this without requiring a Docker daemon, making it a safer and more efficient way to build images compared to Docker-in-Docker (DinD) alternatives, especially in cloud-native environments. Kaniko solves the security concerns associated with the traditional DinD image building process (and other nested container approaches directly requiring namespaces & cgroups access), as it doesn’t require privileged root access on the host machine. This allows it to be used across more environments and run with additional sandboxing that can be incompatible with common container build methods. This aligns with the best practices for building secure and portable cloud-native applications, enabling developers to build images in any environment including Kubernetes clusters.
Since its inception as a tool to help Kubernetes CI/CD use cases, it has since broken out and become used by and supported by companies and projects for building on-cluser, including Gitlab, CloudBees, Tekton, and Devspace. It is directly integrated into Kubeflow for building container images. It boasts 13600+ GitHub stars, and doesn't show any signs of slowing down.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/GoogleContainerTools/kaniko
Additional repos in scope of the application
No response
Website URL
https://github.com/GoogleContainerTools/kaniko
Roadmap
https://github.com/GoogleContainerTools/kaniko/blob/main/ROADMAP.md
Roadmap context
No response
Contributing Guide
https://github.com/GoogleContainerTools/kaniko/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/GoogleContainerTools/kaniko/blob/main/code-of-conduct.md
Adopters
No response
Contributing or Sponsoring Org
Google - https://github.com/GoogleContainerTools
Maintainers file
https://github.com/GoogleContainerTools/kaniko/blob/main/MAINTAINERS.md
IP Policy
Trademark and accounts
Why CNCF?
Kaniko has garnered attention and adoption through organic growth, primarily driven by its innovative approach to container image building. Despite its successes, its association as a "Google tool" limits its potential contributor base. In reality, the project is very independently maintained, by maintainers and contributors inside and outside of Google. Its roadmap is decided by these maintainers, not by any Google strategy.
By joining the CNCF, we aim to elevate Kaniko's visibility and underscore its independence, encouraging broader adoption and contribution from the cloud-native community. The CNCF's resources and network will be instrumental in scaling Kaniko's impact, fostering integrations with other projects, and facilitating its growth as a community-driven project.
Benefit to the Landscape
Kaniko is designed around a novel approach to building container images from Dockerfiles securely and efficiently in Kubernetes environments. This enhances the CNCF landscape by offering a tool that aligns with cloud-native principles and complements existing container management and orchestration tools.
Additionally CNCF's landscape currently doesn't have many build tools. Buildpacks and ko are the main solutions here which don't support Dockerfile builds which many in the ecosystem rely on. Having more diverse tools like this can give end users more diverse options when looking for a solution.
Cloud Native 'Fit'
Kaniko epitomizes the cloud-native ethos by enabling container image builds in a Kubernetes-native way. It leverages the existing infrastructure and workflows of CNCF users/projects, aligning with the cloud-native philosophy of scalability, security, and portability. Kaniko lets users treat building containers as just another process in their Kubernetes cluster, not having to do any special plumbing or wiring up of permissions to get it working.
Cloud Native 'Integration'
Kaniko complements various CNCF projects like Kubernetes, Kubeflow, ArgoCD, and GitLab by providing a seamless and secure way to build container images for CI/CD and container orchestration platforms. Kaniko allows these projects to build containers from Dockerfiles (the most widely used container DSL) in an easy and secure way not possible with alternatives which is the project has grown and is incorporated by users on these platforms today. Kubeflow directly integrates with Kaniko for building container images on cluster
Cloud Native Overlap
Kaniko overlaps with projects like Buildpacks and Docker in the container image creation space but offers a unique approach by eliminating the need for a Docker daemon while still supporting Dockerfiles. Kaniko's approach of building containers without relying on namespaces & cgroups directly but assuming a containerized environment is unique and gives it UX and security advantages over other alternatives.
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, kaniko uses different architectural design to
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 run on Kubernetes, and could benefit from being able to build images easily on cluster (via kaniko UX) as well as building images more securely.Landscape
Yes - https://landscape.cncf.io/?item=app-definition-and-development--application-definition-image-build--kaniko
Business Product or Service to Project separation
N/A
Project presentations
N/A
Project champions
No response
Additional information
No response