K
Q

Docker for Mac - Kubernetes - reference local image

6/7/2018

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 ?

-- user62058
docker-for-mac
kubernetes

Similar Questions

Kubernetes - Traffic always redirect to the same pod
How to reach kubernete service running in minikube from the same computer
provide default objects in kubernetes namespaces
kubectl run fail in interactive mode on CI
Cannot access flask app running on minikube from local
Kubernetes Statefulsets: Restart all pods concurrently (instead of in sequence)

3 Answers

10/11/2018

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)

--
Source: StackOverflow
6/8/2018

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.

-- Prateek Jain
Source: StackOverflow
6/8/2018

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.

-- d0bry
Source: StackOverflow