Minikube: Docker private image repository. pull access denied / repository does not exist or may require 'docker login'

[wolfebrian2120]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT

Please provide the following details:

Environment:
Running minikube and using VirtualBox as the VM host
I have created a docker image and pushed it up to docker hub.
Created a deployment yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: fedora-apache
labels:
app: fedora-apache
spec:
selector:
matchLabels:
app: fedora-apache
replicas: 2
template:
metadata:
labels:
app: fedora-apache
spec:
containers:
- name: fedora-apache
image: wolfeman2120/fedora-apache:0.01
imagePullPolicy: Always
ports:
- containerPort: 80
imagePullSecrets:
- name: my-secret

Created a kubernetes secret
apiVersion: v1
kind: Secret
metadata:
name: my-secret
data:
.dockerconfigjson:
type: kubernetes.io/dockerconfigjson

I can run docker login and it successfully logs me into docker on the command line to push up new images.

Minikube version (use minikube version):
minikube version: v0.28.2

• OS (e.g. from /etc/os-release):
  C02MH12EFD56:kubernetes bwolfe$ uname -a
  Darwin C02MH12EFD56 15.6.0 Darwin Kernel Version 15.6.0: Tue Apr 11 16:00:51 PDT 2017; root:xnu-3248.60.11.5.3~1/RELEASE_X86_64 x86_64

MAC OSX 10.11.16

I am running minikube on

• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName):
  C02MH12EFD56:kubernetes bwolfe$ cat ~/.minikube/machines/minikube/config.json
  {
  "ConfigVersion": 3,
  "Driver": {
  "IPAddress": "192.168.99.100",
  "MachineName": "minikube",
  "SSHUser": "docker",
  "SSHPort": 53365,
  "SSHKeyPath": "/Users/bwolfe/.minikube/machines/minikube/id_rsa",
  "StorePath": "/Users/bwolfe/.minikube",
  "SwarmMaster": false,
  "SwarmHost": "",
  "SwarmDiscovery": "",
  "VBoxManager": {},
  "HostInterfaces": {},
  "CPU": 2,
  "Memory": 2048,
  "DiskSize": 20000,
  "NatNicType": "virtio",
  "Boot2DockerURL": "file:///Users/bwolfe/.minikube/cache/iso/minikube-v0.28.1.iso",
  "Boot2DockerImportVM": "",
  "HostDNSResolver": false,
  "HostOnlyCIDR": "192.168.99.1/24",
  "HostOnlyNicType": "virtio",
  "HostOnlyPromiscMode": "deny",
  "UIType": "headless",
  "HostOnlyNoDHCP": false,
  "NoShare": false,
  "DNSProxy": true,
  "NoVTXCheck": false,
  "ShareFolder": ""
  },
  "DriverName": "virtualbox",
  "HostOptions": {
  "Driver": "",
  "Memory": 0,
  "Disk": 0,
  "EngineOptions": {
  "ArbitraryFlags": null,
  "Dns": null,
  "GraphDir": "",
  "Env": null,
  "Ipv6": false,
  "InsecureRegistry": [
  "10.96.0.0/12"
  ],
  "Labels": null,
  "LogLevel": "",
  "StorageDriver": "",
  "SelinuxEnabled": false,
  "TlsVerify": false,
  "RegistryMirror": null,
  "InstallURL": ""
  },
  "SwarmOptions": {
  "IsSwarm": false,
  "Address": "",
  "Discovery": "",
  "Agent": false,
  "Master": false,
  "Host": "",
  "Image": "",
  "Strategy": "",
  "Heartbeat": 0,
  "Overcommit": 0,
  "ArbitraryFlags": null,
  "ArbitraryJoinFlags": null,
  "Env": null,
  "IsExperimental": false
  },
  "AuthOptions": {
  "CertDir": "/Users/bwolfe/.minikube",
  "CaCertPath": "/Users/bwolfe/.minikube/certs/ca.pem",
  "CaPrivateKeyPath": "/Users/bwolfe/.minikube/certs/ca-key.pem",
  "CaCertRemotePath": "",
  "ServerCertPath": "/Users/bwolfe/.minikube/machines/server.pem",
  "ServerKeyPath": "/Users/bwolfe/.minikube/machines/server-key.pem",
  "ClientKeyPath": "/Users/bwolfe/.minikube/certs/key.pem",
  "ServerCertRemotePath": "",
  "ServerKeyRemotePath": "",
  "ClientCertPath": "/Users/bwolfe/.minikube/certs/cert.pem",
  "ServerCertSANs": null,
  "StorePath": "/Users/bwolfe/.minikube"
  }
  },
  "Name": "minikube"
  }

• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION):
  minikube ssh cat /etc/VERSION
  v0.28.1

• Install tools:
  I installed minikube, kubernetes and docker using brew

• Others:
  The above can be generated in one go with the following commands (can be copied and pasted directly into your terminal):

minikube version
echo "";
echo "OS:";
cat /etc/os-release
echo "";
echo "VM driver": 
grep DriverName ~/.minikube/machines/minikube/config.json
echo "";
echo "ISO version";
grep -i ISO ~/.minikube/machines/minikube/config.json

What happened:
Trying to run a deployment on the kubernetes cluster. It is unable to login to docker to pull the image from docker hub.

kubernetes fails to access docker with the secret.
Name: fedora-apache-684f9fc6f9-klhd4
Namespace: default
Node: minikube/10.0.2.15
Start Time: Wed, 15 Aug 2018 10:53:20 -0400
Labels: app=fedora-apache
pod-template-hash=2409597295
Annotations:
Status: Pending
IP: 172.17.0.4
Controlled By: ReplicaSet/fedora-apache-684f9fc6f9
Containers:
fedora-apache:
Container ID:
Image: wolfeman2120/fedora-apache:0.01
Image ID:
Port: 80/TCP
Host Port: 0/TCP
State: Waiting
Reason: ImagePullBackOff
Ready: False
Restart Count: 0
Environment:
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-gp5kr (ro)
Conditions:
Type Status
Initialized True
Ready False
PodScheduled True
Volumes:
default-token-gp5kr:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-gp5kr
Optional: false
QoS Class: BestEffort
Node-Selectors:
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 10s default-scheduler Successfully assigned fedora-apache-684f9fc6f9-klhd4 to minikube
Normal SuccessfulMountVolume 10s kubelet, minikube MountVolume.SetUp succeeded for volume "default-token-gp5kr"
Normal Pulling 9s kubelet, minikube pulling image "wolfeman2120/fedora-apache:0.01"
Warning Failed 9s kubelet, minikube Failed to pull image "wolfeman2120/fedora-apache:0.01": rpc error: code = Unknown desc = Error response from daemon: pull access denied for wolfeman2120/fedora-apache, repository does not exist or may require 'docker login'
Warning Failed 9s kubelet, minikube Error: ErrImagePull
Normal BackOff 7s (x2 over 8s) kubelet, minikube Back-off pulling image "wolfeman2120/fedora-apache:0.01"
Warning Failed 7s (x2 over 8s) kubelet, minikube Error: ImagePullBackOff
What you expected to happen:
That kubernetes would run the pods with the selected image

How to reproduce it (as minimally and precisely as possible):

Output of minikube logs (if applicable):
not sure where to look for these.
Anything else do we need to know:
I have read the documentation from kubernetes
https://kubernetes.io/docs/concepts/containers/images/

As far as i know all you have to do is run
docker login in this case it is "docker login index.docker.io"
enter password and it will create the file ~/.docker/config.json
That file must be base64 encoded in the kubernetes secret, yaml in above section minus the file

Then that secret must be referenced in the yaml of the deployments pod spec via imagePullSecrets

As far as I know I have gotten the kubernettes portion correct. Is there maybe some limitation on how minikube can handle this?
Is it not possible for the minikube VM to reach out to the internet?
Is it a limitation using VirtualBox?
From what I have read using private image repos like docker hub should be supported, There is specific documentation regarding AWS and GCR, so I would expect docker hub as well.

[tstromberg]

I'm pretty sure this should work, but is a a matter of getting the docker authentication setup correctly within Kubernetes. I honestly am not sure how to, but this page has some hints:

https://stackoverflow.com/questions/49298520/imagepullbackoff-error-google-kubernetes-engine

Regardless, we should make sure this gets documented, as I'm sure your use case is not uncommon.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[quickbooks2018]

Hi there, I provided the solution in mentioned below, kindly have a look. thanks

https://www.youtube.com/watch?v=MNM1GZpuUPw&feature=youtu.be