Darwin bhutwala-mac 18.7.0 Darwin Kernel Version 18.7.0: Thu Jan 23 06:52:12 PST 2020; root:xnu-4903.278.25~1/RELEASE_X86_64 x86_64Skaffold's heuristic to detect kind cluster
kind's docs on using local registry
Current workaround is to edit the kubeconfig to rename kubernetes context to something other than:
kind-(.*) for kind >= v0.6.0 or
(.*)@kind for kind < v0.6.0
@yashbhutwala - if you set build.local.push:false in your skaffold.yaml that should always force push, can you confirm whether that works for you?
@balopat setting build.local.push to both false and true, skaffold still tries to load images into the nodes. I want to _disable loading images_.
Same thing for me.
Loading images inside a kind cluster has poor performances, like really bad...using a local registry is way better. I think @yakovzaytsev wants to disable the load feature for this reason, and so do I.
Maybe create new settings like:
deploy.kind.localRegistry (true|false to disable loading images)deploy.kind.clusterName (to force the kind cluster name & deactivate the feature if needed)This seems entirely reasonable. Anyone open to sending a PR in to fix this?
I am also facing the same issue while using local registry in KIND with skaffold in GitHub actions. Images are loaded into nodes but pods are not able to pull the images with image name - localhost:5000 registry url.
sorry this one got a bit lost, but yes I agree this is entirely reasonable and we should fix this in skaffold. we're forcing a kind load but we should enable local registries, I think @maximegaillard's idea is probably the easiest way to support this. sig-cluster-lifecycle also has a proposal for communicating this back up: https://github.com/kubernetes/enhancements/pull/1757. we could use this if/when it gets implemented.
we probably won't prioritize this in the next few months but PRs welcome 馃檹
Same for k3d.
deploy.k3d.localRegistry@nkubala I am creating a PR for this.
@betterclever awesome :) Please keep us updated on that if you can!
We're also keen on seeing this added, as the current loading functionality is ultra slow.
@betterclever any progress so far, or would you want me to take a jab at it?
@Multiply I haven't been able to pick this up yet. Please go ahead. 馃榾
Another relevant issue #4955 but not completely related. When implementing #4955 it would be great to consider use of local registry.
Current workaround is to edit the kubeconfig to rename kubernetes context to something other than:
kind-(.*)forkind >= v0.6.0or
(.*)@kindforkind < v0.6.0
Is there another workaround as well?
I can't remove the k3d prefix from my k3d context.
We could also have heuristic checking if image name refers to localhost-like address to disable loading images for both k3d/kind.
@nkubala @tstromberg Raised PR for this with unit tests, tested locally, works like charm, run/dev is much faster now!
Most helpful comment
Same thing for me.
Loading images inside a kind cluster has poor performances, like really bad...using a local registry is way better. I think @yakovzaytsev wants to disable the load feature for this reason, and so do I.
Maybe create new settings like:
deploy.kind.localRegistry(true|false to disable loading images)deploy.kind.clusterName(to force the kind cluster name & deactivate the feature if needed)