Introduction

Addressing the challenge of time-consuming build, push, and deploy processes in a dynamic development environment is a critical issue. The current time per build for a fully optimized Docker Image in a large Microservices-based application demands thoughtful and strategic solutions as it consumes a lot of time. Streamlining and enhancing these processes require careful engineering to improve efficiency and overall development workflow. In this article, we shall discuss a strategy to deal with it using Kaniko.

Pre-Requisites

• Docker
• Dockerhub Account
• Kubernetes Cluster

Intro to Kaniko

Meet Kaniko. It's an Open Source project which focuses on building our Docker Images inside a Kubernetes Cluster. The Docker Image is built inside the cluster from start to finish. It is designed to be secure and efficient. It does not require any additional dependencies or privileges beyond what is already provided by the Kubernetes cluster.

With a Highly Specced Kubernetes Node and a container native environment provided by Kubernetes we can expect serious time gains using Kaniko.

How does it work?

Kaniko itself is an image which builds images using Dockerfile and Build Contexts. Within the Kaniko image, the base image’s file system is extracted, and commands specified on the Dockerfile are executed in it. After each command, the file system is snapshotted (i.e. layers are created, just like in a normal docker build), and when the last command is executed, the final image is built by appending all the layers of changed files to the base image and the metadata of the image is updated.

Implementation

Before starting the builds, we must deploy Kaniko into the Kubernetes Cluster. If you have not provisioned a Cluster, use Minikube to create the cluster in your system.

Minikube Installation Guide

For Mac (Apple Silicon/ Intel):

brew install minikube

For Linux (x86_64):

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

sudo install minikube-linux-amd64 /usr/local/bin/minikube

Alternatively, you can get the latest binaries for all system architectures from the Github Releases page of Minikube.

Start the Kubernetes cluster with minikube start

You can now start administering the cluster with the kubectl CLI tool.

Building with Kaniko

Kaniko is a plug-and-play type of software. It does not need to be deployed into a cluster in the traditional sense. It's as simple as pointing Kaniko to the Code Base and the Dockerfile, and Kaniko does the rest.

Once the image is built and pushed, the deployed container exits and is removed from the cluster by the Control Plane. Anytime a new build is required, Kaniko can run on the cluster again. It's a typical tool used in CI environments where Webhooks trigger builds, and certain commands are then executed to generate the Build Files.

We can start building a Docker Image as we've already set up our Kubernetes Cluster.

Pushing Images to a Docker Registry

Kaniko Supports pushing built docker images to different registries. I'll use Docker Hub as my container registry for this example, but you can use any registry listed here.

Perform a docker login in your system and use your Dockerhub username and password. A config file will be generated by Docker at $HOME/.docker/config.json.

{
	"auths": {
		"https://index.docker.io/v1/": {
			"auth": "base64-encoded-username-password-string"
		}
	}

Or you can just encode your username and password in the base64 form as shown below and add it to the config.json file above.

echo -n registry-username:registry-password | base64

Once our config.json file is ready, we will create a Kubernetes secret, which will be used by Kaniko to push built images into the registry.

Run the command below to create the secret.

kubectl create secret generic docker-registry-credentials \
--from-file=$HOME/.docker/config.json \
--type=kubernetes.io/dockerconfigjson

Building a Docker Image with Kaniko

Please save the file below as kaniko-build-runner.yml and execute it in the cluster with the command:

kubectl -f kaniko-pod.yml apply

apiVersion: v1
kind: Pod
metadata:
  Name: kaniko-builder
spec:
  Containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=/workspace/Dockerfile", "--context=dir://workspace","--destination=docker-username/repository"]
    volumeMounts:
    - name: kaniko-docker-registry-secret
      mountPath: /kaniko/.docker
    - name: dockerfile-storage
      mountPath: /workspace
    restartPolicy: Never
    volumes:
    - name: kaniko-docker-registry-secret
      secret:
        secretName: docker-registry-credentials
        items:
        - key: .dockerconfigjson
          path: config.json
    - name: dockerfile-storage
      persistentVolumeClaim:
        claimName: dockerfile-claim
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: dockerfile
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  accessModes:
  - ReadWriteOnce
  storageClassName: local-storage
  # provide the path to the directory containing code and Dockerfile here
  hostPath:
    path: /home/blogger/kaniko-dir/

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

Disadvantages of Kaniko

There are some notable disadvantages of using Kaniko, such as:

1. Supports building Linux Images only. Currently, Windows Images are not supported by Kaniko. You won’t be able to build any images with Windows Base in a Kubernetes Cluster with Kaniko.
2. Kaniko is only supported on the official Docker Image provided by the maintainers. Running Kaniko on other images (by copying its executables, etc) may or may not work, and no support is provided for such environments.

Conclusion

In this article, we learned how Kaniko works and leveraged it to build a docker image inside a Kubernetes cluster using Kaniko.

Thank you for reading. Please comment below if you have any queries. I periodically update my articles to ensure legibility.