-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minikube connection to internal registry is refused #4604
Comments
I've found the issue gets resolved if you remove the |
thanks @castlemilk - I suspected the same let me try deleting the daemonset |
I can't tell from #4627 - do we think this issue has been fixed now? If not, what is required to do so? |
@tstromberg I think, #4627 does not resolves this issue.. |
I was experiencing the exact same issue with Tekton, the merged changes in #4639, should hopefully resolve this and ensure testing validates connectivity from outside the minikube cluster (on port 5000) as well as internal access to the registry (on port 80) |
This PR fixes kubernetes#4604 by adding a new selector to concerned svc/rc only. This also reverts `kubernetes.io/minikube-addons` to `registy` for registry-proxy so that addon manager can deploy registry-proxy when registry addon is enabled.
@tstromberg @castlemilk @kameshsampath and others, I think #4805 should fix this issue. |
This PR addresses kubernetes#4604 by adding a new selector to concerned svc/rc only. This also reverts `kubernetes.io/minikube-addons` to `registy` for registry-proxy so that addon manager can deploy registry-proxy when registry addon is enabled.
This PR addresses kubernetes#4604 by adding a new selector to concerned svc/rc only. This also reverts `kubernetes.io/minikube-addons` to `registy` for registry-proxy so that addon manager can deploy registry-proxy when registry addon is enabled.
Deleting the daemonset isn't really a workaround, as it gets recreated by the addon. Does anyone know a proper workaround until the fix gets released? |
That's a good idea ;) |
Has anyone tested this with v1.3.1? I'm curious if this issue can be closed. |
Any luck confirming whether or not this issue still exists with v1.3.1? |
@tstromberg - still same issue :( , if you can deploy the demo https://github.com/kameshsampath/pipeline-helloworld after enabling https://github.com/kameshsampath/minikube-helpers/registry you will see it just times out at the stage of pushing the image to local registry. I tried 1.3.1, 1.2.0 both same result. Works as usual with 1.1.1 |
Not sure about those repos, but I can successfully make requests to the internal registry now via say: Try setting your Tekton apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
name: helloworld-image
spec:
type: image
params:
- name: url
value: "registry.kube-system:80/tutorial/helloworld" |
@castlemilk ah thats a good tip . I was simply aliasing the same via my helper. |
@castlemilk I checked your example with Minikube 1.3.1 (registry add-on enabled and registry-proxy active) and Tekton 0.6.0. It worked and uses the registry service. It is important setting port 80 in the url (it does not work without setting any port) because this matches the registry service port. |
I can't tell from the comments - was there a resolution found here? |
@castlemilk - were you able to use the image without setting insecure-regsitry in minkube start ?
|
@tstromberg @castlemilk - I am able to run with |
@tstromberg - I feel I still need to use my registry helper https://github.com/kameshsampath/minikube-helpers/tree/master/registry to make it resolve the |
@kameshsampath have you tried with other drivers? could you tell me what your helper does, is there any way we could integrate into minikube? |
@medyagh - i see that my helper consistently working with 1.4.0 with both hyperkit and virtualbox. This is what my helper does
After these 3 you can now push and pull to the internal registry using the custom domain names.
I was thinking to make this an |
@kameshsampath that is a good idea ! please feel free to make a PR for it ! |
@kameshsampath do you still have interests to make a PR for this and to clarify is the daemonset is inside minikube? |
@kameshsampath - PR looks good, but could use a quick README file so that users understand what it is actually doing. |
@tstromberg - thinking where is the right place to add that, just in the addons folder ? I also got another question on whats the best practice to do the following while disabling the addon:
|
@tstromberg - updates done on the PR. thanks |
@tstromberg - I think this issue has popped up again with 1.8.2, after applying the |
No thoughts, but a 404 does sound like a very different than "connection refused". |
Anyone still running into this with minikube v1.10.x or newer? |
OK, looks like this is safe to close. Please reopen if the issue return. |
When I try to push images to internal registry from container (build via Tekton piplines) I get a connection refused error. This is working well with minikube v1.1.1.
The exact command to reproduce the issue:
Following https://github.com/kameshsampath/minikube-helpers/tree/master/registry/README.adoc.
The full output of the command that failed:
[build-greeter-jvm : buildah-build-push] Head http://dev.local/v2/rhdevelopers/pipeline-greeter/blobs/sha256:9ce2ac72ea3a3f426d08fe7ed892b6983f6ded93b9f82d8f87b8083760f26bec: dial tcp 10.111.212.82:80: connect: connection refused
The output of the
minikube logs
command:When I inspected registry logs I got this
registry-p8bmz registry 10.1.0.20 - - [25/Jun/2019:08:54:32 +0000] "HEAD /v2/rhdevelopers/pipeline-greeter/blobs/sha256:49d9522d5abfe1bf7e9646b02e1125fec6376add018a3a1a9a5ab875a3e52b68 HTTP/1.1" 404 157 "" "Buildah/1.7"
The operating system version:
minikube version: v1.2.0
macOS Mojave 10.14.5
hyperkit
orvirtualbox
Related: #4553
The text was updated successfully, but these errors were encountered: