{"action":"created","issue":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/5548","labels_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/5548/labels{/name}","comments_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/5548/comments","events_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/5548/events","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/5548","id":62422698,"number":5548,"title":"cache selector result in etcd","user":{"login":"xudifsd","id":665253,"avatar_url":"https://avatars.githubusercontent.com/u/665253?v=3","gravatar_id":"","url":"https://api.github.com/users/xudifsd","html_url":"https://github.com/xudifsd","followers_url":"https://api.github.com/users/xudifsd/followers","following_url":"https://api.github.com/users/xudifsd/following{/other_user}","gists_url":"https://api.github.com/users/xudifsd/gists{/gist_id}","starred_url":"https://api.github.com/users/xudifsd/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/xudifsd/subscriptions","organizations_url":"https://api.github.com/users/xudifsd/orgs","repos_url":"https://api.github.com/users/xudifsd/repos","events_url":"https://api.github.com/users/xudifsd/events{/privacy}","received_events_url":"https://api.github.com/users/xudifsd/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/priority/design","name":"priority/design","color":"c7def8"},{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/team/master","name":"team/master","color":"d2b48c"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":36,"created_at":"2015-03-17T15:10:16Z","updated_at":"2015-03-24T05:04:35Z","closed_at":null,"body":"This is a proposal to implement caching selector result. https://github.com/GoogleCloudPlatform/kubernetes/issues/4817#issuecomment-76495394\r\n\r\nAFAIK, currently only [two components](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/labels.md#api) use selector to group their members: `service` and `replicationController`, and they get list of their members by matching seletor against all pods' label every time.\r\n\r\nHere I propose a way to cache seletor result in etcd.\r\n\r\nDefine a new registry in etcd: selector.\r\n\r\nWhenever a `service` or `replicationController` is created, generate [uid](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/identifiers.md#uids) for its selector, and register selector with that uid in etcd. While creating `service` or `replicationController`, it watches that selector in etcd to wait updates on result of selector. We should add pre-existed matched pods to its result of course.\r\n\r\nAnd whenever a `pod` is created, matches its label with all selector under its namespace (assuming we forbidden selector select object in another ns, which I not quite sure), and add that pod to selector result if match. Update or delete a `pod` should also update all selectors' result under its ns.\r\n\r\nWhen a `selector` and `pod` is created at same time, we should use some kind of mutex to avoid race condition.\r\n\r\nAny comment?"},"comment":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/comments/85338951","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/5548#issuecomment-85338951","issue_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/5548","id":85338951,"user":{"login":"bgrant0607","id":7725777,"avatar_url":"https://avatars.githubusercontent.com/u/7725777?v=3","gravatar_id":"","url":"https://api.github.com/users/bgrant0607","html_url":"https://github.com/bgrant0607","followers_url":"https://api.github.com/users/bgrant0607/followers","following_url":"https://api.github.com/users/bgrant0607/following{/other_user}","gists_url":"https://api.github.com/users/bgrant0607/gists{/gist_id}","starred_url":"https://api.github.com/users/bgrant0607/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bgrant0607/subscriptions","organizations_url":"https://api.github.com/users/bgrant0607/orgs","repos_url":"https://api.github.com/users/bgrant0607/repos","events_url":"https://api.github.com/users/bgrant0607/events{/privacy}","received_events_url":"https://api.github.com/users/bgrant0607/received_events","type":"User","site_admin":false},"created_at":"2015-03-24T05:04:35Z","updated_at":"2015-03-24T05:04:35Z","body":"@xudifsd The goal is for 1.0 to land sometime in June.\r\n\r\nThere are multiple problems discussed on this issue.\r\n\r\nOne problem is that currently controllers and the scheduler are doing a lot of redundant work. \r\n\r\nFor instance, the replication controller manager lists pods for every RC:\r\nhttps://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/controller/replication_controller.go#L195\r\n\r\nFor each pod, the scheduler lists all services:\r\nhttps://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/scheduler/predicates.go#L275\r\nthen for each service targeting the pod, it lists all pods:\r\nhttps://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/scheduler/predicates.go#L280\r\nand it walks all pods for each node:\r\nhttps://github.com/GoogleCloudPlatform/kubernetes/blob/master/pkg/scheduler/predicates.go#L357\r\n\r\nWe'll likely need to reduce the number of queries to the apiserver in order to meet our performance goals. One simple approach discussed for the replication controller manager would be to get all pods once, then update the counts of all replication controllers. Narrowing the search by namespace may be sufficient to identify the matching RCs for now.\r\n\r\nEventually, such clients will want to continuously watch all objects of interest (RCs and pods for replication controller manager, and at least nodes, pods, and services for the scheduler) and then incrementally update their state as objects are created, updated, and deleted, in order to avoid repeated listing entirely. This will require finding related objects in constant time, which implies linking them on the client side. Also note that incremental updates requires implementation of efficient reverse lookups, to identify which selectors' results need to be updated when an object is mutated.\r\n\r\nI also want to make it feasible to push lookups for more detailed information to clients (e.g., which services target a pod), as discussed in #3676, which is only feasible if the call pattern doesn't incur quadratic complexity (or worse). This would require indexing/linking on the server, which would be used to serve at least list queries. \r\n\r\nTherefore, I think we'll need to pursue both client-side and server-side approaches.\r\n\r\nIt's likely this problem won't be completely solved by May. Whatever remains (server-side indexing, efficient watch filtering, reverse lookups, index by uid or ip address, etc.) should be enough to comprise a project.\r\n\r\nI recommend thinking about how to more efficiently solve the reverse lookup problem -- how to quickly find a matching selector, especially when using the generalized selectors (#341)."}}