kube-fledged pulls your images onto the nodes so pods start without a registry round trip

The unit of work is an ImageCache custom resource

kube-fledged is a Kubernetes operator for creating and managing a cache of container images directly on the worker nodes of a cluster. A user defines a list of images and onto which worker nodes those images should be cached, meaning pulled. As a result, application pods start almost instantly, since the images need not be pulled from the registry.

The API is custom resources, and the verification commands in the README show the resource kind: kubectl get imagecaches. The name of the resource is the visible contract, and the lifecycle is the standard operator pattern. The README states that kube-fledged provides CRUD APIs to manage the lifecycle of the image cache, and supports several configurable parameters to customize the functioning as per one's needs.

The operator covers the full lifecycle. There is a section on how to create an image cache, how to view the status of an image cache, how to add and remove images in an image cache, how to refresh an image cache, and how to delete an image cache, plus a section on removing kube-fledged itself. The refresh operation is the one that matters most in practice, because it is how you pick up a new tag of an image that is already cached, and the delete operation is how you reclaim the disk.

The Go module path is github.com/senthilrch/kube-fledged, requiring Go 1.26.0 with toolchain go1.26.5, and the project is Apache-2.0 licensed.

The use cases say when caching pays and when it does not

The README's use case list is the most useful part of the document for deciding whether this belongs in your cluster, because each entry names a specific constraint that caching removes.

Applications that require rapid start-up and/or scaling are first, with the example of an application performing real-time data processing that needs to scale rapidly due to a burst in data volume. Serverless functions typically need to react immediately to incoming events and spin up containers within a fraction of a second. IoT applications running on edge devices need to tolerate the intermittent network connectivity between the edge device and the image registry.

The fourth case is the security one, and it is the most distinct from the performance cases. If images need to be pulled from a private registry and everyone cannot be granted access to pull images from that registry, then the images can be made available on the nodes of the cluster. That converts a registry access-control problem into a node-caching problem, and it is a different reason to deploy the operator than the other three.

The fifth is a rollout safety case. If a cluster administrator or operator needs to roll out upgrades to an application and wants to verify beforehand if the new images can be pulled successfully, the cache gives them a place to try the pull before the deployment.

Read together, the first three are about latency and the last two are about access and verification. A cluster with fast registry links and small images satisfies none of them, which is the case where the operator is overhead.

Node selection depends on the kubernetes.io/hostname label

The prerequisites section is short and one item is a hard requirement. A functioning Kubernetes cluster, which could be a simple development cluster like minikube or a large production cluster. Cluster-admin privileges to the Kubernetes cluster for deploying kube-fledged. And all master and worker nodes having the kubernetes.io/hostname label.

That last requirement is the one that trips people up, because the label is not always present on every node in an existing cluster, and the operator selects nodes by it. A cluster that needs the label added to every node before the operator will work is a cluster where someone has to touch the node configuration.

For development, the README lists the local toolchain: git, make, go, a Docker engine of 19.03 or later, openssl, kubectl, helm, gpg and gnu-sed installed on a local Linux or Mac machine, with kubectl configured properly to access the cluster.

The gnu-sed and gpg entries are worth noticing, because they indicate the build and release path is not a plain go build. The Makefile confirms the shape: it builds a controller, a CRI client, a webhook server image and an operator image, with the image repositories defaulting to docker.io/senthilrch/ prefixed names and the versions of the underlying tools pinned through variables such as ALPINE_VERSION, CRICTL_VERSION, DOCKER_VERSION, GOLANG_VERSION and OPERATORSDK_VERSION.

The CGO handling in the Makefile is also deliberate. Only enable CGO, and build the UDP backend, on AMD64, with CGO_ENABLED=1 for the amd64 architecture and 0 otherwise.

Three install paths, and the Helm chart one is the smoothest

There are three documented installation routes, and they deploy into a separate namespace called kube-fledged using pre-built images in Docker Hub.

The YAML manifest route clones the source and runs a make target:

$ git clone https://github.com/senthilrch/kube-fledged.git $HOME/kube-fledged
$ cd $HOME/kube-fledged
$ make deploy-using-yaml

The verification step is the same shape in all three routes, checking the pods and then the custom resources:

$ kubectl get pods -n kube-fledged -l app=kubefledged
$ kubectl get imagecaches -n kube-fledged (Output should be: 'No resources found')

The Helm chart route creates the namespace and installs the chart from the project chart repository:

$ export KUBEFLEDGED_NAMESPACE=kube-fledged
$ kubectl create namespace ${KUBEFLEDGED_NAMESPACE}

$ helm repo add kubefledged-charts https://senthilrch.github.io/kubefledged-charts/
$ helm repo update
$ helm install kube-fledged kubefledged-charts/kube-fledged -n ${KUBEFLEDGED_NAMESPACE} --wait

The Helm operator route clones the source and runs make deploy-using-operator, and the verification there uses a different label selector, app.kubernetes.io/name=kube-fledged, which reflects the operator's own chart conventions rather than the plain manifests.

The chart parameters are documented separately in docs/helm-parameters.md, and the Makefile carries a proxy escape hatch for building behind a proxy, exporting HTTP_PROXY and HTTPS_PROXY in upper case.

The CRI client is what makes the cache real on the node

The build targets give away the architecture, and they are the interesting part of the repository layout. The Makefile declares a controller, a cri-client-image, an operator image and a webhook server image, and the CRI client is built around CRICTL, pinned at v1.36.0.

A controller alone cannot put an image on a node. Kubernetes gives a controller the ability to create and delete objects, not to make the container runtime on a specific machine hold a particular image. The CRI client is the component that talks to the container runtime interface on the node and does the actual pull, and the controller is what decides which images go to which nodes and keeps that state.

The webhook server is the third piece. An operator that installs a custom resource into a cluster often has to do it through an admission webhook so that the operator is present when the resource is created, rather than relying on a periodic reconcile loop to notice it. That is the standard operator pattern, and the presence of a webhook image confirms kube-fledged follows it rather than using a simpler poll-only controller.

The repository layout matches: cmd/ holds the entry points, pkg/ the library code, build/ the build scripts, deploy/ the manifests, hack/ the developer scripts, docs/ the documentation, e2etest/ the end-to-end tests, and a .golangci.yml for linting. The Go dependencies include the operator SDK machinery, client-go and the API server libraries at 0.36.2, helm.sh/helm/v3 at 3.21.3, and sigs.k8s.io/e2e-framework for the end-to-end tests, along with glog and pkg/errors.

Maintenance is steady, and the release line tells you what changed

The release history shows an unusual pattern. There is v0.11.0 from 2026-07-16, and then a long gap back to v0.10.0 in October 2022 and v0.9.0 in January 2022. The last push was on 2026-09-17.

That gap is the interesting fact. The project was quiet for roughly three and a half years and then produced a new minor version in mid-2026, which suggests a burst of work rather than a steady trickle. The README also carries a Travis CI badge and a Coveralls coverage badge, which are both indicators of a project whose continuous integration predates the GitHub Actions migration that most Go projects made.

The Go module tells you the current shape. It requires Go 1.26.0 with toolchain go1.26.5, and the Kubernetes libraries are at 0.36.2, which is a recent Kubernetes release. A project that was dormant through 2022 to 2025 and now depends on k8s.io/api at 0.36.2 has clearly been updated to a current Kubernetes baseline, which matters for anyone running a recent cluster.

The licence is Apache-2.0, and the Makefile carries the standard Apache 2.0 header with the copyright line for 2018 the kube-fledged authors. For a component that runs with cluster-admin privileges and executes pulls on every node in the cluster, a permissive licence with a patent grant is a reasonable choice for a vendor embedding it.

Where kube-fledged is the wrong tool

The first wrong-tool case is the cluster with fast pulls and small images. If your base image is tens of megabytes and the registry is on the same network, the pull takes a second or two and the operator adds a controller, a webhook server, a per-node client and a custom resource to manage. The complexity is real and it is not a self-contained complexity, because it touches every node in the cluster.

The second is the storage cost. Caching images on nodes means the disk space of every node holds a copy of every image in every cache that targets it. On a cluster with large images and many nodes, that is a meaningful amount of disk, and the operator has to be told which nodes to cache which images, because the default of caching everywhere multiplies the cost.

The third is the risk of a stale cache. The refresh operation exists precisely because a cached tag is a snapshot, and a tag that moves, say latest, will not update on the node until something refreshes it. A deployment that assumes a node has the newest build of a mutable tag can start the old code, and the failure is silent. Teams that use mutable tags need to think about how refresh is triggered, and the README does not document a scheduling mechanism for it beyond the manual operation.

The fourth is that a node-level pull is not the same as a node-level guarantee. Kubernetes will still schedule a pod onto a node that does not have the image, and the pull will happen then, so the cache is an optimisation and not a preloading contract. A team that needs pods to start without any registry dependency at all, for a genuinely disconnected node, is looking for a different mechanism.

Editorial conclusion

kube-fledged fits a cluster where pod start time is dominated by image pull time, whether that is a slow link to the registry, a burst of serverless cold starts, or a private registry that application teams may not access. It does not fit a cluster with small images on fast links, where the operator adds a moving part for no gain. Before deploying it, confirm that every master and worker node carries the kubernetes.io/hostname label, since the operator selects nodes by that label, and note that the project needs cluster-admin privileges to install.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. senthilrch/kube-fledged on GitHub