The advantage of this setup is that no images need to be pushed, since the local cluster uses images straight from your local docker daemon. It leads to much faster development cycles.
Skaffold’s heuristic to detect local clusters is based on the Kubernetes context name set on kubectl. You can find your the current context name by running:
kubectl config current-context
Skaffold checks for the following context names:
|Kubernetes context||Local cluster type||Notes|
||This context name is deprecated|
||This pattern is used by kind >= v0.6.0|
||This pattern was used by kind < v0.6.0|
||This pattern is used by k3d >= v3.0.0|
For any other name, Skaffold assumes that the cluster is remote and that images have to be pushed.
1 Additionally, a Kubernetes context may be considered as
even if it’s not named
minikube but it’s cluster certificate is stored at
$HOME/.minikube or the
minikube profile list command returns the Kubernetes
For non-standard local setups, such as a custom
some extra configuration is necessary. The essential steps are:
Ensure that Skaffold builds the images with the same docker daemon that runs the pods’ containers.
Tell Skaffold to skip pushing images either by configuring
build: local: push: false
or by marking a Kubernetes context as local (see the following example).
For example, when running
minikube with a custom profile (e.g.
minikube start -p my-profile):
Set up the docker environment for Skaffold with
source <(minikube docker-env -p my-profile). This should set some environment variables for docker (check with
env | grep DOCKER). It is important to do this in the same shell where Skaffold is executed.
Tell Skaffold that the Kubernetes context
my-profilerefers to a local cluster with
skaffold config set --kube-context my-profile local-cluster true