My company uses it\'s own root CA and when I\'m trying to pull images. Even from a private registry I\'m getting error:
1h 3m 22 {kubelet miniku
A straight forward way to do this independent from minikube would be to use a imagePullSecrets
configuration. As documented in the Pulling an Image from a Private Registry guide, you can create a Secret
and use that along with your image like this:
apiVersion: v1
kind: Pod
metadata:
name: demo-pod
spec:
containers:
- name: private-container
image: <your-private-image>
imagePullSecrets:
- name: the_secret
Where the the_secret
could be created with:
kubectl create secret docker-registry the_secret --docker-server=xxx --docker-username=xxx --docker-password=xxx --docker-email=xxx
Or with:
kubectl create secret generic the_secret --from-file=.docker/config.json
Or with anything else which is related to kubectl create secret
- see documentation for details.
Edit: Even in the official minikube
documentation you'll find that they use Secrets
along with the registry-creds
addon.
You'll find the generic documentation here and the documentation for the addon here.
It burns down to:
minikube addons enable registry-creds
But technically it does the same as described above.
The only solution I've found so far is adding --insecure-registry gcr.io option to the minikube.
To address:
x509: certificate signed by unknown authority
Could you please try the following suggestion from Minikube repo?
copy the cert into the VM. The location should be:
/etc/docker/certs.d/
from here: https://docs.docker.com/engine/security/certificates/
ref
That thread also includes the following one-liner:
cat <certificatefile> \
| minikube ssh "sudo mkdir -p /etc/docker/certs.d/<domain> && sudo tee /etc/docker/certs.d/<domain>/ca.crt"
The issue here is the CA Trust chain of the Linux host that needs to be updated. The easiest way is to reboot the Linux host after copying the certs into the VM, if rebooting is not an option - look for a way to update-ca-certificates
.
Just restarting the Docker Daemon will most likely not solve this issue
Note: allowing the Docker daemon to use insecure registries means certificates aren't verified.. while this may help, it does not solve the question asked here