An Introduction to Kaniko | Baeldung on Ops

1. Introduction

In this tutorial, we’ll take a look at building container images using Kaniko.

2. Kaniko

Kaniko is a tool to build container images from a Dockerfile. Unlike Docker, Kaniko doesn’t require the Docker daemon.

Since there’s no dependency on the daemon process, this can be run in any environment where the user doesn’t have root access like a Kubernetes cluster.

Kaniko executes each command within the Dockerfile completely in the userspace using an executor image: gcr.io/kaniko-project/executor which runs inside a container; for instance, a Kubernetes pod. It executes each command inside the Dockerfile in order and takes a snapshot of the file system after each command.

If there are changes to the file system, the executor takes a snapshot of the filesystem change as a “diff” layer and updates the image metadata.

There are different ways to deploy and run Kaniko:

Kubernetes cluster
gVisor
Google Cloud Build

In this tutorial, we’ll be deploying Kaniko using a Kubernetes cluster.

3. Installing Minikube

We’ll be using Minikube to deploy Kubernetes locally. It can be downloaded as a stand-alone binary:

$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 &&
  chmod +x minikube

We can then add Minikube executable to the path:

$ sudo mkdir -p /usr/local/bin/
$ sudo install minikube /usr/local/bin/

Next, let’s make sure the Docker daemon is running:

$ docker version

Also, this command will tell us the client and server version installed.

And now, we can create our Kubernetes cluster:

$ minikube start --driver=docker

Once the start command executes successfully, we’ll see a message:

Done! kubectl is now configured to use "minikube"
For best results, install kubectl: https://kubernetes.io/docs/tasks/tools/install-kubectl/

Upon running the minikube status command, we should see the kubelet status as “Running“:

m01
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Next, we need to set up the kubectl binary to be able to run the Kubernetes commands. Let’s download the binary and make it executable:

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s \ 
  https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl &&
  chmod +x ./kubectl

Let’s now move this to the path:

$ sudo mv ./kubectl /usr/local/bin/kubectl

We can verify the version using:

$ kubectl version

4. Building Images Using Kaniko

Now that we have a Kubernetes cluster ready, let’s start building an image using Kaniko.

First, we need to create a local directory that will be mounted in Kaniko container as the build context.

For this, we need to SSH to the Kubernetes cluster and create the directory:

$ minikube ssh
$ mkdir kaniko && cd kaniko

Next, let’s create a Dockerfile which pulls the Ubuntu image and echoes a string “hello”:

$ echo 'FROM ubuntu' >> dockerfile
$ echo 'ENTRYPOINT ["/bin/bash", "-c", "echo hello"]' >> dockerfile

If we run cat dockerfile now, we should see:

FROM ubuntu
ENTRYPOINT ["/bin/bash", "-c", "echo hello"]

And lastly, we’ll run the pwd command, to get the path to the local directory which later needs to be specified in the persistent volume.

The output for this should be similar to:

/home/docker/kaniko

And finally, we can abort the SSH session:

$ exit

4.1. Kaniko Executor Image Arguments

Before proceeding further with creating the Kubernetes configuration files, let’s take a look at some of the arguments that the Kaniko executor image requires:

Dockerfile (–dockerfile) – File containing all the commands required to build the image
Build context (–context) – This is similar to the build context of Docker, which refers to the directory which Kaniko uses to build the image. So far, Kaniko supports Google Cloud Storage (GCS), Amazon S3, Azure blob storage, a Git repository, and a local directory. In this tutorial, we’ll use the local directory we configured earlier.
Destination (–destination) – This refers to the Docker registry or any similar repository to which we push the image. This argument is mandatory. If we don’t want to push the image we can override the behavior by using the –no-push flag instead.

We can also see additional flags that can be passed.

4.2. Setting Up the Configuration Files

Let’s now start creating the configuration files required for running Kaniko in the Kubernetes cluster.

First, let’s create the persistent volume which provides the volume mount path that was created earlier in the cluster. Let’s call the file volume.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: dockerfile
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: local-storage
  hostPath:
    path: /home/docker/kaniko # replace this with the output of pwd command from before, if it is different

Next, let’s create a persistent volume claim for this persistent volume. We’ll create a file volume-claim.yaml with:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: dockerfile-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: local-storage

Finally, let’s create the pod descriptor which comprises the executor image. This descriptor has the reference to the volume mounts specified above which in turn point to the Dockerfile we’ve created before.

We’ll call the file pom.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=/workspace/dockerfile",
            "--context=dir://workspace",
            "--no-push"] 
    volumeMounts:
      - name: dockerfile-storage
        mountPath: /workspace
  restartPolicy: Never
  volumes:
    - name: dockerfile-storage
      persistentVolumeClaim:
        claimName: dockerfile-claim

As mentioned before, in this tutorial we’re focusing only on the image creation using Kaniko and are not publishing it. Hence we specify the no-push flag in the arguments to the executor.

With all of the required configuration files in place, let’s apply each of them:

$ kubectl create -f volume.yaml
$ kubectl create -f volume-claim.yaml
$ kubectl create -f pod.yaml

After applying the descriptors, we can check that the Kaniko pod comes into the completed status. We can check this using kubectl get po:

NAME     READY   STATUS      RESTARTS   AGE
kaniko    0/1   Completed       0        3m

Now we can check the logs of this pod using kubectl logs kaniko, to check the status of the image creation and it should show the following output:

INFO[0000] Resolved base name ubuntu to ubuntu          
INFO[0000] Resolved base name ubuntu to ubuntu          
INFO[0000] Retrieving image manifest ubuntu             
INFO[0003] Retrieving image manifest ubuntu             
INFO[0006] Built cross stage deps: map[]                
INFO[0006] Retrieving image manifest ubuntu             
INFO[0008] Retrieving image manifest ubuntu             
INFO[0010] Skipping unpacking as no commands require it. 
INFO[0010] Taking snapshot of full filesystem...        
INFO[0013] Resolving paths                              
INFO[0013] ENTRYPOINT ["/bin/bash", "-c", "echo hello"] 
INFO[0013] Skipping push to container registry due to --no-push flag

We can see in the output that the container has executed the steps we have put in the Dockerfile.

It began by pulling the base Ubuntu image, and it ended by adding the echo command to the entry point. Since the no-push flag was specified, it didn’t push the image to any repository.

Like mentioned before, we also see that a snapshot of the file system is taken before adding the entry point.

5. Conclusion

In this tutorial, we’ve looked at a basic introduction to Kaniko. We’ve seen how it can be used to build an image and also setting up a Kubernetes cluster using Minikube with the required configuration for Kaniko to run.

As usual, the code snippets used in this article are available over on GitHub.

Full Archive

About Baeldung