-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Deprecate kubernetes-ro service #4567
Comments
OpenShift is most interested in the kubernetes service. Is that going away on GKE? I actually plan to use that to support running OpenShift as a pod on Kubernetes. Sent from my iPhone
|
I think it is used by third parties-- isn't that the way our SkyDNS pod knows where to get the list of things to populate DNS with? |
Heapster uses the RO service to get information about running things
|
DNS uses it. I sort of like that it is automatically rate limited, but I I will go with the flow, but please don't break DNS.
|
@derekwaynecarr @lavalamp @thockin @vmarmol @thockin |
@derekwaynecarr |
@erictune can you confirm that deprecating kubernetes-ro is needed for v1.0 (as opposed to the other issues you mentioned, and this one being optional for 1.0)? |
This is not needed for 1.0, but the other two are. Fixing labels. |
thinking about this more, this is needed for v1. |
@erictune Is it OK if we assign this issue to you? |
Yes. On Tue, Apr 28, 2015 at 2:54 PM, David Oppenheimer <notifications@github.com
|
This is a rookie question, but if the RO service is being removed, how would I access the list of services from within a container? |
Use a service account to inject credentials and access the secure (read/write) port on the master. |
@ sujaymansingh if you describe your client, I can suggest the best way to On Wed, Jun 3, 2015 at 9:16 PM, Brian Grant notifications@github.com
|
Hi @erictune It will mainly be python (though if it is HTTP anything could access it right?) I'm mainly interested in a mix of python APIs (probably using flask) and standalone scripts. |
Now that the "secrets" type has been merged, and we have namespaces, I don't think it often makes sense to give blanket readonly access to objects. So, lets deprecated it.
I don't know that we want to rip it out all in one go.
Nothing is using the
kubernetes-ro
service as far as I can see from searching the codebase, however some customers might depend on it, and maybe openshift does. For GKE, I think we'd like it gone. So, lets add a flag to the master that disables its creation. If a customer needs it we can tell them how to get it back, but it will discourage new uses.Once service-accounts land, we can give people that need it a way to automatically generate policy and credentials for things in pods. Then we can delete
kubernetes-ro
it altogether.The text was updated successfully, but these errors were encountered: