Kind Load vs. Local Repository

 

In this post we reviewed using kind for local development. One of the requirement for such deployment is to load the image into kind using:

kind load docker-image ${DockerTag}

The kind load CLI sends the entire image to the kind, which means it does not use the docker image layers concept. This means that any image update will take much longer time, especially for large images.

To improve this we can use a local docker repository, and configure kind to load the images from it. To deploy a local repository our development laptop we use:

docker run -d \
  --restart=always \
  -p 5000:5000 \
  --name kind-registry \
   -v $HOME/.kind/registry:/var/lib/registry \
  registry:2

Then we re-create the kind cluster with configuration to use the local registry:

cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerdConfigPatches:
- |
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
    endpoint = ["http://kind-registry:5000"]
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
EOF

To enable kind to communicate with the docker repository container, we connect the networks:

docker network connect kind kind-registry

And it is ready!

We can now load the build images into the local repository as part of our build script:

LocalRegistryTag=localhost:5000/my-image:latest
docker tag ${DockerTag} ${LocalRegistryTag}
docker push ${LocalRegistryTag}

We also should use an updated helm configuration for the images location, as well as instruct kubernetes to always pull the images from the registry. This is required since we usually do not change the image version upon local build, and simply use `latest`:

image:
  registry: localhost:5000/
  version: /dev:latest
  pullPolicy: Always

The result is a faster build and deployment process on the local laptop.