I am testing Rancher 2.8.5 for a client and am evaluating how private registries work. It a struggle so far. As far as I can determine:
- Creating a pod thru kubectl, using --overrides functions result in "ErrImagePull "
kubectl run tester —namespace gratstats --image quay.io/majonesservices/tester-pod:latest restart=Never -it --rm – /bin/bash --overrides=‘{ “spec”: { “template”: { “spec”: { “imagePullSecrets”: [{“name”: “majonesservices-runforest2-pull-secret”}] } } } }’
- Creating a POD by importing yaml thru the Rancher WebUI also results in ErrImagePull
apiVersion: v1
kind: Pod
metadata:
name: tester
namespace: gratstats
spec:
containers:
- args:
- bash
- ‘-c’
- read && su postgres
image: quay.io/majonesservices/tester-pod
imagePullPolicy: Always
imagePullSecret:
- name: majonesservices-runforest2-pull-secret
name: tester
When examining the resulting running / err POD YAML, the imagePullSecret reference is not listed.
Of course, if I make the image repo public, all is well! No authentication is needed
- The ONLY way to leverage a private REPO is to use the WebUI and “CREATE” the POD using the config features:
SO, the big question is: My client will expect to leverage private repos in many different ways. Is it too much to ask a YAML import, containing a imagePullSecret tag from the UI to work?
Am I missing something??
Overall, as a developer, I typically like to spin up a pod to debug, I keep a private image with my favorite debug tools and will simply use kubectl to run it. /bin/bash shell into the running container to perform needed tests: nslookup, connect to other services to eval the network. So, it’s quite a pain to just not be able to do that unless my tools are public.