kube-fledged VS k8s-config-connector

Exactly. Part of the appeal to consolidate all of our container images to use Debian-slim is the ability to optimise the caching of layers, both in our container registry but also on our kubernetes cluster’s nodes (which can be done in a consistent manner with kube-fledged[1]).

[1] https://github.com/senthilrch/kube-fledged

If you're pulling big images you could try kube-fledged (it's the simplest option, a CRD that works like a pre-puller for your images), or if you have a big cluster you can try a p2p distributor, like kraken or dragonfly2.

Also there's that project called Nydus that allows starting up big containers way faster. IIRC, starts the container before pulling the whole image, and begins to pull data as needed from the registry.

https://github.com/senthilrch/kube-fledged

https://github.com/dragonflyoss/Dragonfly2

https://github.com/uber/kraken

https://nydus.dev/

kube fledged - pre pull containes in nodes: https://github.com/senthilrch/kube-fledged

kube-fledged is a kubernetes add-on or operator for creating and managing a cache of container images directly on the worker nodes of a kubernetes cluster. It allows a user to define a list of images and onto which worker nodes those images should be cached (i.e. pulled). As a result, application pods start almost instantly, since the images need not be pulled from the registry. kube-fledged provides CRUD APIs to manage the lifecycle of the image cache, and supports several configurable parameters in order to customize the functioning as per one’s needs. (URL: https://github.com/senthilrch/kube-fledged)

I found recently this tool kube-fledged that should do what you want..

I recommend you also look at kube-fledged this is more appealing IMHO.

If your company is k8s centric and the developers are most comfortable with k8s, you might want to focus more on something specific to k8s such as helm, or even if you don't get into helm you may want to use config connector in your yaml to manage GCP resources in an IaC compliant method. You can manage k8s resources with terraform, but if your developers are currently comfortable working directly with k8s you are going to see significant pushback getting them to add terraform as a middleware. You probably still want to manage your GKE clusters and VPCs with terraform since you can't really use config connector.

Config Connector [1] is also an option in this space for GCP, it supports many GCP resources and thus far our experience with it has been largely positive.

[1] https://cloud.google.com/config-connector/docs/overview

We use it heavily with GCP's Kubernetes Config Connector to provision architecture. It could similarly be used for Cloud Functions, etc. given a repo URL that GCP can access. GitOps + operator pattern is a pretty powerful mechanism to let k8s continuously seek state towards your ideal. https://cloud.google.com/config-connector/docs/overview

For K8s, we were using Cloud Composer to do it for us but wanted more fine control over CI/CD, so we decided to go with Airflow on K8s. That's all hosted in GKE now and deployed using ArgoCD with helm. This also led down the IaC rabbit hole which has been a ton of fun too. We use the GCP ConfigConnector resources for that which is a little challenging at first, but gets a lot easier as time goes on.

Terraform is 90% of cloud IaC. But there are newer Kubernetes Operators like Config Connector that can create cloud specific resources.

It works particularly well with Google Config Connector as then it's all just manifests.