-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Flux can't check for updated images in a private registry #1396
Comments
It looks like I was actually running an older version of flux in this cluster (v1.5.0). I'll reopen this once I get a chance to test with the latest if it's still an issue. |
Getting the same error; adding the... imagePullSecrets:
- name: registry-secret ...didn't do anything, and I'm running the latest version of Flux (1.7.1). |
Can we reopen this? I can't seem to get it to work either. Secret exists and is made as per your instructions... |
Also seeing this issue on Flux 1.7.1 using Azure Kubernetes Service (brand new RBAC cluster). |
Still seeing this in 1.9 w/private registry that uses an internally signed certificate. |
yeah, nothing works, adding imagepullsecrets to deployment\serviceaccout. doesnt matter. ACR, flux 1.9, AKS 1.11.5 @brantb |
apparently its not a thing as of now: #1694 |
The merged PR fixes this issue for Azure's container registry but what about other private registries? I feel like the real solution here is to use the imagePullSecrets from the pod if it is available. |
I'm having the same error. Not using AKS. Using our own k8s cluster.
I'm still getting |
@kwontae Have you resolve this issue ? I have the same one |
Hey @AntoineGodeau #2589 (comment) this has helped me resolve my issue! |
When using a private docker registry, flux doesn't seem to be able to check for updated images using the default ServiceAccount's
imagePullSecrets
.I tested this out on a brand new Azure Container Registry instance and k8s namespace created for this purpose.
k8s is able to pull and run the container. However, after killing flux and memcached (to wipe out any cached creds) I still see this in the logs:
ts=2018-09-26T20:14:29.675347521Z caller=warming.go:162 component=warmer canonical_name=branttest.azurecr.io/party-clippy auth={map[]} err="requesting tags: Get https://branttest.azurecr.io/v2/party-clippy/tags/list: unauthorized: authentication required"
Adding an
imagePullSecret
directly to the Deployment makes this error go away (presumably because it's working).The text was updated successfully, but these errors were encountered: