{"action":"created","issue":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/4971","labels_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/4971/labels{/name}","comments_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/4971/comments","events_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/4971/events","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/4971","id":59584809,"number":4971,"title":"Scheduler spreading using services vs replication controllers","user":{"login":"abhgupta","id":1211613,"avatar_url":"https://avatars.githubusercontent.com/u/1211613?v=3","gravatar_id":"","url":"https://api.github.com/users/abhgupta","html_url":"https://github.com/abhgupta","followers_url":"https://api.github.com/users/abhgupta/followers","following_url":"https://api.github.com/users/abhgupta/following{/other_user}","gists_url":"https://api.github.com/users/abhgupta/gists{/gist_id}","starred_url":"https://api.github.com/users/abhgupta/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/abhgupta/subscriptions","organizations_url":"https://api.github.com/users/abhgupta/orgs","repos_url":"https://api.github.com/users/abhgupta/repos","events_url":"https://api.github.com/users/abhgupta/events{/privacy}","received_events_url":"https://api.github.com/users/abhgupta/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/area/scheduling","name":"area/scheduling","color":"ab6420"},{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/labels/priority/P3","name":"priority/P3","color":"fef2c0"},{"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":5,"created_at":"2015-03-03T02:13:22Z","updated_at":"2015-03-06T15:12:20Z","closed_at":null,"body":"Creating a separate issue since the PR (https://github.com/GoogleCloudPlatform/kubernetes/pull/4674) in which this discussion was initiated is merged and this merits a second look.\r\n\r\nI had raised the question of why we used services instead of replication controllers for identifying peer pods for spreading by the scheduler. The argument is that services might not be needed and could be avoided in some cases, whereas replication controller will most likely always be there.\r\n\r\n@bgrant0607 's initial response: why use services instead of replication controllers for identifying peer pods for spreading. Discussed in #1965 and #2312. Replication controllers are associated with deployments. We expect there to be multiple per service: canaries, rolling updates, multiple release tracks, etc. What people want is spreading of the whole service. Custom spreading is discussed in #4301 and #367.\r\n\r\nWhile I agree that there can be multiple replication controllers per service, I still believe that spreading of pods should still happen independently for the replication controllers. Also, we have customer use cases where the services are not created at all and routing/load balancing to a group of pods is being handled by custom middleware.\r\n\r\nRolling updates: the new pods coming in should be scheduled on the best possible minions and should not be combined with the existing older pods for achieving a good spread. Eventually, when all the older pods are removed and only the new ones remain, its the spreading of the new pods that really matters.\r\n\r\nCanaries: This one is slightly different, but in general the same argument applies here as for rolling updates.\r\n\r\nMultiple release tracks: shouldn't we have a good spread within each release track to ensure HA for each release track? Why would we want to jointly consider the pods for different release tracks for a good spread?"},"comment":{"url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/comments/77574100","html_url":"https://github.com/GoogleCloudPlatform/kubernetes/issues/4971#issuecomment-77574100","issue_url":"https://api.github.com/repos/GoogleCloudPlatform/kubernetes/issues/4971","id":77574100,"user":{"login":"danmcp","id":492994,"avatar_url":"https://avatars.githubusercontent.com/u/492994?v=3","gravatar_id":"","url":"https://api.github.com/users/danmcp","html_url":"https://github.com/danmcp","followers_url":"https://api.github.com/users/danmcp/followers","following_url":"https://api.github.com/users/danmcp/following{/other_user}","gists_url":"https://api.github.com/users/danmcp/gists{/gist_id}","starred_url":"https://api.github.com/users/danmcp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danmcp/subscriptions","organizations_url":"https://api.github.com/users/danmcp/orgs","repos_url":"https://api.github.com/users/danmcp/repos","events_url":"https://api.github.com/users/danmcp/events{/privacy}","received_events_url":"https://api.github.com/users/danmcp/received_events","type":"User","site_admin":false},"created_at":"2015-03-06T15:12:20Z","updated_at":"2015-03-06T15:12:20Z","body":"@bgrant0607 \r\n\r\nI am not saying ignore service.  Just that it isn't the best first priority.  If you spread with replication controller as the first priority and service after, you still get the service spreading, without the edge cases.\r\n\r\nI will mention too it isn't just 1 replication controller cases that are broken only spreading by service.  One example would be:\r\n\r\nStart with:\r\n\r\nNode1: P1_RC1_S1, P2_RC1_S1, P3_RC1_S1, P4_RC1_S1\r\nNode2: P1_RC2_S1, P2_RC2_S1, P1_RC3_S1, P2_RC3_S1\r\n\r\nSo you have 3 replication controllers total and 1 service that spans all of them.  The above example is perfectly spread by service.  But if you scale down RC1 to 0.  You are left with the 2 remaining replication controllers with their resources all on 1 node.\r\n\r\nI don't have an example that spreading by replication controller then service is worse though.\r\n\r\nI don't disagree you have to have self healing still.  Are you arguing you would rather only heal these types of problems after the fact rather than build the logic (with RC labeling or otherwise) into the scheduler?  If so, are you just making an argument of it's too much complexity?"}}