Kubernetes fails to run locally built docker image - docker

I am trying to run a docker image that I have build locally with Kubernetes.
Getting below error
Failed to pull image "myImage": rpc error: code = Unknown desc = Error response from daemon: pull access denied for myImage, repository does not exist or may require 'docker login'
In yaml file i have given as
image: myImage
imagePullPolicy: IfNotPresent
In local i am using docker-desktop and minikube.
I have tried multiple ways but only thing is working on to make tar of myImage and load in minikube.
I have tried using eval $(minikube docker-env) but after this my image is not able to build because it's pulling base image from organization nexus server.
Can anyone suggest anyother way?

Unfortunately I can't comment yet so I have to post an answer. The image you're trying to pull, myImage does not exist in the local image cache of your kubernetes cluster. Running a docker image ls command should yield a list of images that are available locally. If docker doesn't find an image locally, it will (by default) then go to Docker Hub to find the image. Seeing as the image listed has no prefix like someOrganization\ the image is assumed to be an officially published image from DockerHub themselves. Since your locally built image isn't an official Dockerhub image it doesn't know what to run. So the core of the problem is that your minikube doesn't have access to wherever you built your image. Unfortunately I haven't used minikube before so i'm unable to comment on any intricacies of how to work with it. I would be remiss if I left my answer like that, though, so looking at the docs for minikube ( REF: https://minikube.sigs.k8s.io/docs/handbook/pushing/#1-pushing-directly-to-the-in-cluster-docker-daemon-docker-env ) you're doing the right thing with the eval.
Sooo... your minikube isn't stock/vanilla and it pulls from a company repo? Sounds like you need to alter your minikube or you should re-evaluate the base image you're using and fix the Dockerfile.

To fix this, set imagePullPolicy to Never.
Ensure to set eval $(minikube docker-env) before building the image.

Maybe this is a little bit late but... if anyone has the same issue, here is how I solved something like this:
You need to pass "Never" as imagePullPolicy:
imagePullPolicy: Never
You need to load the image inside minikube:
minikube image load myImage
After all this, just continue as usual:
kubectl apply -f whereverTheFileIs.yaml

Related

What is the difference between docker pull and docker image pull commands?

As of now, I am learning Docker. This reference has mentioned two ways of pulling an image from the Docker registry. Can anyone explain this in simple terms?
Does this mean that we cannot get updates on a pulled image if we use docker image pull command?
They are the same command. From the documentation you linked:
To download a particular image, or set of images (i.e., a repository), use docker image pull (or the docker pull shorthand).
There are many "shortand commands" like:
docker push for docker image push
docker run for docker container run
...
What is the difference between docker pull and docker image pull commands?
None.
Can anyone explain this in simple terms?
They are the same.
Does this mean that we cannot get updates on a pulled image if we use docker image pull command?
No.
Also https://forums.docker.com/t/docker-pull-imagename-vs-docker-image-pull-imagename/59283

How can I use Helm to deploy a docker image from my file system?

How can I use Helm to deploy a docker image from my local file system?
What's the syntax in the chart for that?
I'm not looking to pull from the local docker daemon/repository, but from the file system proper.
file:///mumble/whatever as produced by docker build -o type=local,dest=mumble/whatever
The combined Helm/Kubernetes/Docker stack doesn't really work that way. You must build your image locally and push it to some sort of registry before you can run it (or be using a purely local environment like minikube). It's unusual to have "an image in the filesystem" at all.
Helm knows nothing about building images; for that matter, Helm on its own doesn't really know much about images at all. It knows how to apply the Go templating language to text files to (hopefully) produce YAML, and to send those to the Kubernetes cluster, but Helm has pretty limited awareness of what those mean. In a Helm chart you'd typically write something like
image: {{ .Values.registry }}/{{ .Values.image }}:{{ .Values.tag }}
but that doesn't "mean" anything to Helm.
Kubernetes does understand image: with its normal meaning, but again that generally refers to an image that lives in Docker Hub or a similar image registry, not something "on a filesystem". The important thing for Kubernetes is that it expects to have many nodes, so if an image isn't already on a node, it knows how to pull it from the registry. A very typical setup in fact is for nodes to be automatically created and destroyed (via the cluster autoscaler) and you'd almost never have anything of importance on the node outside of a pod.
This means, in practical use, you basically must have a container registry. You can use Docker Hub, or run one locally, or use something provided by your cloud provider. If you're using a desktop-oriented Kubernetes setup, both minikube and kind have instructions for running a registry as part of that setup.
Basically the one exception this is, in minikube, you can use minikube's Docker daemon directly by running
eval $(minikube docker-env)
docker build -t my-image .
This builds the image normally, keeping it "inside Docker space", except here it's inside the minikube VM.
A Docker image in a file isn't especially useful. About the only thing you can do with it is docker load it; even plain Docker without Kubernetes can't directly run it. If you happened to have the file, you could docker load it into minikube the same way we built it above, or minikube load it. If it's at all an option, though, using the standard Docker registry system will generally be easier than trying to replicate it with plain files.

Cloud Run: image [name] not found even image does exist in container registry

I try to run my image on Cloud Run but it said:
yaml:
Anyway my image does exist in the Container Registry
I try to run that container above with specific tag or Digest but it still doesn't work.
Do we have the way to solve this kind of problem?

docker pull image policy/settings

My situation is I have two images with the same tag(hash different), one at local and another at the registry. When I build dockerfile, docker always compares the hash of the two images find not equal then will pull the registry one.
I know there has an imagePullPolicy in k8s. My question is docker has any settings like imagePullPolicy?
Thanks a lot.
The Docker tooling by and large either assumes you're going to manually pull images, or provides a --pull option to integrate it with other commands. For example:
docker build has a --pull option to try to retrieve a newer version of FROM images
docker run does not; it will always reuse the image you already have, or pull one if you don't have it
Neither core docker-compose nor docker-compose up has a --pull option, but there is a docker-compose pull command that pulls every image listed in a docker-compose.yml file
docker-compose build does have a --pull option
Core Docker always tries to pull an image if it is not present; there is no equivalent to imagePullPolicy: Never. Conversely, it never tries to communicate with an image registry outside of an explicit "pull" operation; you also cannot make docker run act like imagePullPolicy: Always.
It's good practice in Kubernetes to use a unique tag per build, so you can specify an explicit build and don't have to worry about imagePullPolicy. If you do this, in plain Docker, the implicit "pull if missing" will get you the correct behavior as well.
As a potential addendum to #David Maze's answer, it looks like docker run now also has a --pull option.

Why is Kubectl looking for a local image on the Internet?

Please see my images below:
I then run this:
kubectl run my-app --image=iansimage:latest --port=5000
and this:
kubectl expose deployment my-app --type=LoadBalancer --port=8080 --target-port=5000
However, I then see this:
Notice the warning in the above screenshot: "Error response from daemon: pull access denied for iansimage, repository does not exist or may require 'docker login': denied: requested access to the resource is denied".
Why is Kubectl trying to find iansimage:latest on the internet? iansimage:latest is a local image I created as per my last question: Create an image from a Dockerfile
Please note that I am new to Kubernetes so this may be simple?
Update
Following on from Burak Serdars's comment. Say I have a com,and like this, which would nomally build an image: docker build -t "app:latest" .
How would I build this image inside a Kubernetes pod?
"Latest" is a special tag, it means that Docker always check if the downloaded image is the latest available searching the registry.
Retag your image with other tag than latest, like this :
docker tag iansimage:latest iansimage:v1
Then change your Yaml and use iansimage:v1
That solve your problem.
When you use kubectl run I believe it will create a deployment resource with a member named ImagePullPolicy which I believe defaults to Always. You might be able to change this with kubectl edit deployment my-app to set this field to IfNotPresent.
You might also consider #Enzo's suggestion to tag the image to a particular version.

Resources