Code change:
For example, kubernetes-ro service appears with empty selector (this service was created by the hack/local cluster) - is that ok? What meaning such service has if it has no entity to fwd traffic to?
kubernetes and kubernetes-ro are currently "virtual" - they are not backed by running pods, but by the master itself. , abonas wrote:
if that's internal impl, why is it exposed to user? let's say a client pulls all entities and builds a UI around it. then a service with no selector arrives, and it's internal to kube - how the client should know not to present it/touch it? (similar to the "net" container in pods)
It's exposed exactly FOR users - so they can find the apiserver. It has a corresponding Endpoints object, it gets a portal IP and a kube-proxy rule, and it gets service env vars and a DNS name. The fact that it is virtual is an implementation detail. That it exists is all users should need to know. , abonas wrote:
And FWIW, the master components may one day actually be pods... , Tim Hockin wrote:
thanks for the explanation. so any general rule how to distinguish kube pods/services from user defined?
Do we need to distinguish them? We could add labels, I guess, if it is really important to distinguish them.
sometimes users would want to see only the things they defined and not implementation details of the system.
One could argue this is why the users should be using labels. I'm not against defining labels for "special" stuff, but it's new territory, so we should enter with caution. , abonas wrote:
I think the right answer might be to put them in a special "cluster" or "system" namespace. , Tim Hockin wrote:
See If we put them in a "kubernetes" ns, the DNS name would be :) I'm not against segmenting them into a different namespace. We just need to decide on what that namespace is called, plumb through that configuration, decide on compatibility for a short while or not, and decide if that namespace is "special" or just "different" - i.e. should the skydns, heapster, etc pods go into this namespace? , Brendan Burns wrote:
As said, the services are there for applications that need to contact the apiserver. Additionally, nil selectors can be used by users to import external services. Adding labels to the kubernetes services won't help. Users need to manage their objects using labels. /cc
Yeah, lots of consumers will expose "special" services. IN fact, in many clusters the "special" services will outweigh the unspecial ones. At this point, the namespace they are in is completely arbitrary, and I think because it is a name, it should be free for the end user to choose where they are surfaced.
Per the proposal here: , I think the namespace should continue to hold these services, and they require no special labels. I sense comment is made without thinking through what Kubernetes operators do to bootstrap a cluster. I think it's reasonable that namespace holds everything you need to run, and operators may or may not choose to segment their data in other namespaces. If they want to not see this information, its an exact reason for why they should use their own namespace. I don't think we need anything new here.
- I'm not clear on your meaning. Did you mean that we should make the "cluster admin" namespace a config param that everyone knows about and can be different cluster-to-cluster? Or did you mean that default is as arbitrary a name as any other? I'd be fine moving things out of default into "kube" or "kubernetes" or "cluster" or something, but I am less convinced that a flag is a good thing. , Clayton Coleman wrote:
- wherever we stick this stuff, it should be the namespace that is initially bootstrapped, which today is . I continue to believe that is as good a name as any other. I do not see a need to do more here.
I think as soon as you bring naming into the picture, making decisions based on names gets very tricky (what if I want my logging service to be everywhere?). If there is a magic namespace that exposes things to the rest of the cluster, we should ask whether there's only one magic namespace, or multiple? Are services supposed to cross namespaces? It's great that pods can find the master... but that's not the only thing they'll need to find in each namespace. And baking in special names (or customizable names) into your app code is fragile, because then your code only works inside Kubernetes. I'm just trying to pump the brakes on special services prior to us designing them... :) ----- Original Message -----
oh, to be clear, I don't want "special" services - I am merely asking if moving non-user-defined objects (where that is defined very loosely) out of "default" is worthwhile. I tend to agree with Derek that it's not worth energy. , Clayton Coleman wrote:
agree with you that lots of consumers will expose "special" services We should not use the (namespace + k8s-service + skydns) mechanism for publishing the location of those special services. We should decouple the choice of namespace to run the pods of the service in from the well-known dns address of special services. Otherwise, it will be hard to move the pods of the service to another namespace, which people will definitely want to do as they grow. Instead, we need a place to publish well-known services which is not tied to the namespace of the pods of that service.
you open a whole new topic. I've noodled with the idea of a Name resource type. We would generate a Name for each Service as "service.namespace", but users could also add their own Name resources. , Eric Tune wrote:
I'd like to understand better your comment regarding nil selectors used to export external services - can you elaborate? give an example? my understanding is that service redirects traffic to pods based on labels. with nil selector service does nothing, so why is it a service in the first place? I'm pro decoupling special services/internal implementation services from user defined entities. whether by separate namespace, or by saying that the default namespace is reserved, or by any other solution. because otherwise internal implementation and user defined content are mixed and that's no good for a proper management. just tagging you so you could see this issue and the related discussions.
Services abstract backends - they don't have to abstract pods. Some examples: You want to have an external database cluster in production, but in test you use your own databases. You would have a service for both and use the environment variables, but the production service has a nil selector with its endpoints set to the database cluster. You want to have an empty service because you're reserving a name (that isn't accessible yet) but will be in the future You want to point your service to a service in another namespace or on another cluster. You set the endpoints for your service to the publicIPs of the other service. ----- Original Message -----
, thanks. regarding the last point - I was under impression (based on some other discussion) that there would not be cross namespace interaction? that entities can can access only entities in the same namespace?
Cross-namespace is currently allowed and I think has to be allowed, though perhaps (in the fullness of time) that can be policy based rather than wide open. , abonas wrote:
please see this correspondence. my understanding is that there is isolation
Responded there. I think there's some less-than-crystal-clear words in play. , abonas wrote:
+1 to Eric's comment about ensuring there is a consistent manner for system services like kubernetes-ro, if that's not fixes for all clusters it's going to be a nightmare to write reusable containers for multiple different clusters. I don't care if we do that by using a constant namespace, or by giving system services two different names, but there needs to be at least one name that is constant. Regarding default vs. cluster namespace, I think the issue is one of clutter as a user is starting to understand k8s, you turn up a new cluster, launch a pod, or service, and it's hard to find your one object on the sea of system created pods and services. It's visual clutter that confuses people as they onboard. On Jan 23, 2015 3:01 PM, "Tim Hockin" wrote:
- can you drop me a line (my github name at google) - I want to ask you something, and you have no contact info :) , abonas wrote:
sorry for naive question but why would I care as an user that wants to run its existing workload on Kubernetes about kubernetes-ro ? If I write an application that uses kubernetes-ro then I'm locked into Kubernetes. I understand the need for kubernetes-ro being accessible by cluster level services such as monitoring, logging. I also can imagine that a power user might want to start its own cluster services that use kubernetes-ro. I don't see clearly why would majority of users care about kubernetes-ro being visible from their container. I see a reason for the cluster services being visible and accessible for Kubernetes developer, but from an user perspective such services only make the system more complex: why do I see these services (pods,rc) ? are they related to my application ? should I care about them (especially when I use hosted Kubernetes) ? why does my container get all these environment variables for cluster services ?
I will update file to explain why one would have service without a selector.
Right now, every service goes everywhere for simplicity. Name spacing and filtering probably make sense in the long run, but it's not a high priority for v1.0 Brendan On Mar 4, 2015 5:02 AM, "Rafał Sokołowski" wrote:

Related discussion:
text: `service`, a client can simply connect to $MYAPP_SERVICE_HOST on port $MYAPP_SERVICE_PORT. <ins> ## Service without selector Services, in addition to providing clean abstraction to access pods, can also abstract any kind of backend: - you want to have an external database cluster in production, but in test you use your own databases. - you want to point your service to a service in another [`namespace`](namespaces.md) or on another cluster. - you are migrating your workload to Kubernetes and some of your backends run outside of Kubernetes. In any of these scenarios you can define a service without a selector: ```json "kind": "Service", "apiVersion": "v1beta1", "id": "myapp", "port": 8765 ``` then you can explicitly map the service to a specific endpoint(s): ```json "kind": "Endpoints", "apiVersion": "v1beta1", "id": "myapp", "endpoints": ["173.194.112.206:80"] ``` Access to the service without a selector works the same as if it had selector. The traffic will be routed to endpoints defined by the user (`173.194.112.206:80` in case of this example). </ins> ## How do they work? Each node in a Kubernetes cluster runs a `service proxy`.  This application