I am using Docker for Mac with Kubernetes support and I'm struggling to create a Kubernetes Deployment that references a locally built image.
Output of docker images
:
REPOSITORY TAG IMAGE
test latest 2c3bdb36a5ed
My deployment.yaml :
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-deployment
spec:
selector:
matchLabels:
app: helloworld
replicas: 1
template:
metadata:
labels:
app: helloworld
spec:
containers:
- name: aaa
image: test:latest
ports:
- containerPort: 8080
When i run kubectl apply -f deplyment.yaml
pods are created but:
helloworld-deployment-764b8b85d8-2c4kl 0/1 ImagePullBackOff 0
helloworld-deployment-764b8b85d8-rzq7l 0/1 ImagePullBackOff 0
kubectl describe
of one of these pods gives:
Normal Scheduled 20s default-scheduler Successfully assigned helloworld-deployment-79f66d97c6-7tj2x to docker-for-desktop
Normal SuccessfulMountVolume 19s kubelet, docker-for-desktop MountVolume.SetUp succeeded for volume "default-token-72f44"
Normal BackOff 16s kubelet, docker-for-desktop Back-off pulling image "test:latest"
Warning Failed 16s kubelet, docker-for-desktop Error: ImagePullBackOff
Normal Pulling 4s (x2 over 19s) kubelet, docker-for-desktop pulling image "test:latest"
Warning Failed 2s (x2 over 17s) kubelet, docker-for-desktop Failed to pull image "test:latest": rpc error: code = Unknown desc = Error response from daemon: pull access denied for test, repository does not exist or may require 'docker login'
Warning Failed 2s (x2 over 17s) kubelet, docker-for-desktop Error: ErrImagePull
What is interesting is that if i try to run some image hosted on dockerhub then everything is fine, I also tried to use skaffold and it also works like a charm...
I see some similar issues regarding minikube where the solution is to use the minikube docker daemon to build images so that they can be referenced from the Kubernetes cluster.
I would like to avoid setting up local repo, so how can I make it work with Docker's Kubernetes ?
I was able to run a local image by setting the imagePullPolicy
to Never
.
For example:
apiVersion: v1
kind: Pod
metadata:
name: local-image-test
spec:
containers:
- name: local-image-container
image: local-image:latest
imagePullPolicy: Never
(Credit to https://github.com/kubernetes/kubernetes/issues/1293#issuecomment-357326426 for this solution)
Use tagged version of image rather than latest because If you are shipping Docker images to a production environment, you should just ignore the latest tag. Don’t use it. Don’t be tempted by it. It’s easy to look at it and think that your deployment script should just pull “latest” and your build process will ensure that’s valid.
In addition to techtrainer comment and answer, I would like to provide some examples of how to do it.
General rule. You have to use tag version of images rather than latest
.
With Docker tags, the more specific you can get, the better. Get specific to avoid using the wrong image.
Consider this if you don't want your colleagues or other Docker users pulling down images and having no idea how recent they are.
Get specific to avoid such issues.
docker tag IMAGE ID image/TAG:version.d.m.y
For better management of your images, you should have some smart convention of naming. I prefer to use a stage, version, and date of creation of the image. For example:
docker tag 113a43faa138 ubuntu/prod:v1.8.6.2018
It means production stage, version 1, created on 8 June 2018.
And that's all. Your version is available, and naming is easier to understand for you and further users of this image.
来源:https://stackoverflow.com/questions/50739405/docker-for-mac-kubernetes-reference-local-image