Issue 1:
nginx_pod.yml:

apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
hostPort: 31320
resources:
limits:
cpu: 750m
memory: 1Gi

Steps and error details:

Step1. mesos-slave specified --default_role=someone. we could see the following logs of mesos-master，mesos-slave declared all the resources with role of someone:

I0914 11:47:03.723081 1315 master.cpp:3000] Registered slave 20150914-111917-302055713-5050-1294-S0 at slave(1)@33.1.1.19:5051 (cluster-4) with cpus(someone):2; mem
(someone):2929; disk(someone):35164; ports(someone):[31000-32000]
I0914 11:47:03.723228 1315 hierarchical.hpp:455] Added slave 20150914-111917-302055713-5050-1294-S0 (cluster-4) with cpus(someone):2; mem(someone):2929; disk(someon
e):35164; ports(someone):[31000-32000] (and cpus(someone):2; mem(someone):2929; disk(someone):35164; ports(someone):[31000-32000] available)

Step2. and then the master sent offers to k8s， also with “someone”. The log‘s as follows：

I0914 11:52:16.592625 1310 master.cpp:3760] Sending 1 offers to framework 20150914-111917-302055713-5050-1294-0000 (Kubernetes) at scheduler(1)@33.1.1.22:55004
I0914 11:52:21.003809 1315 master.cpp:3461] Performing implicit task state reconciliation for framework 20150914-111917-302055713-5050-1294-0000 (Kubernetes) at sch
eduler(1)@33.1.1.22:55004
I0914 11:52:21.596210 1312 master.cpp:2273] Processing ACCEPT call for offers: [ 20150914-111917-302055713-5050-1294-O1 ] on slave 20150914-111917-302055713-5050-12
94-S0 at slave(1)@33.1.1.19:5051 (cluster-4) for framework 20150914-111917-302055713-5050-1294-0000 (Kubernetes) at scheduler(1)@33.1.1.22:55004
I0914 11:52:21.597126 1312 hierarchical.hpp:648] Recovered cpus(someone):2; mem(someone):2929; disk(someone):35164; ports(someone):[31000-32000] (total allocatable:
cpus(someone):2; mem(someone):2929; disk(someone):35164; ports(someone):[31000-32000]) on slave 20150914-111917-302055713-5050-1294-S0 from framework 20150914-11191
7-302055713-5050-1294-0000

Step3. k8sm create task(e.g. create pod). And the task failed with below log(mesos-master.log):

I0915 12:02:19.634052 1309 master.cpp:3336] Sending status update TASK_ERROR (UUID: 3fa1333c-fdfd-49dc-baf8-b1a989cd3a87) for task pod.9d458b74-5ba1-11e5-9b03-fa163
edb51bd of framework 20150914-111917-302055713-5050-1294-0000 'Task uses more resources cpus(*):1; mem(*):1088; ports(*):[31320-31320] than available cpus(someone):2; mem(someone):2929; disk(someone):35164; ports(someone):[31000-32000]'

Am I did something in wrong way? Or is it a bug?

If it is a bug, can I fix it and submmit a PR?

Issue 2:
Is there any particular reason for putting service ClusterIP and NodePort allocation logic into API server, instead of controller?

AFAIK, allocating in API server is racy when we have multiple API server, unless we write allocation status into etcd. Currently, we have a repair controller in API server which periodically examines all service ClusterIP/NodePort allocations and handle duplicate ClusterIP/NodePort assignments, which is not elegant.

So I propose to put ClusterIP/NodePort allocation logic into controller-manager component(maybe in service-controller). Adding several dedicated allocation-controllers also sounds interesting:

add a controller to allocate ClusterIP/NodePort for Service

add a controller to allocate PodCIDR for Node(which is putting in node-controller currently)

Considering that we have shareInformer now, seems reasonable to split all unrelated logic?

@smarterclayton @davidopp @gmarek @derekwaynecarr