Build Docker container images in Kubernetes with kaniko
No Docker daemon? Working in a Kubernetes cluster? No problem. Kaniko, a new open source tool, allows developers to build an image in a container without needing any special privileges.
Generally, building an image from a standard Dockerfile requires interactive access to a Docker daemon. But what happens when you don’t have root access? Working without privileges makes it difficult to build container images, especially in environments that can’t easily or securely expose their Docker daemons. Like, for instance, in a Kubernetes cluster.
Introducing kaniko, an open-source tool designed to help developers build container images from a Dockerfile inside a container or Kubernetes cluster.
Kaniko doesn’t rely on a Docker daemon. Instead, it executes each command in userspace within a Dockerfile. The image is built from scratch, and contains only a static Go binary plus the configuration files needed for pushing and pulling images. Then, kaniko pushes the newly built image to a registry. Voila! You’ve now built a container image in a standard Kubernetes cluster or Google Kubernetes Engine!
How does kaniko work?
Kaniko executor image is responsible for building an image from a Dockerfile and pushing it to a registry.
Here’s how it works: kaniko runs as a container image that takes in three arguments – a Dockerfile, a build context, and the registry where the image is pushed to. It extracts the filesystem of the base image within the executor image.
Then, any commands are executed in the Dockerfile, snapshotting the filesystem in userspace. Kaniko attaches a layer of changed files to the base image after every command. Finally, the executor pushes the new image to the specified registry.
Since Kaniko does all of this completely in user-space within the executor image, it completely avoids needing any privileged access on users’ machines. No Docker daemon, no CLI, no problem.
Kaniko is similar to other tools like img and orca-build. While both of these tools also build container images from Dockerfiles, they approach the problem differently. For example, img builds images as an unprivileged user within a container, compared to how kaniko builds as a root user within a container in an unprivileged environment. Similarly, orca-build executes builds with kernel namespaceing techniques. Kaniko executes builds as a root user within a container.
SEE MORE: A look back and a leap forward: “Docker has been the driving force behind the containerization movement”
Interested in trying out kaniko? This open-source tool is still in development, but you can try it out for yourself via GitHub. Fair warning, to run kaniko in a Kubernetes cluster, developers need a standard running Kubernetes cluster and a Kubernetes secret.