Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: cAdvisor has a option to only collect docker related cgroups. Kubelet stats api now supports allocatable cgroup, /kubepods, for the runtime cgroup and the kubelet cgroup. But with settings, Kubelet stats api can not query pod related cgroups metrics. FYI: What you expected to happen: should be compatible with kubelet stats api.
/cc
/sig node /sig instrumentation
add to cadvisor in A comma-separated list of cgroup path prefix that needs to be collected even docker-only is specified bump cadvisor dep for Kubernetes setting to
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

Discussion:
"../examples/walkthrough": { "pod1": &api.Pod{}, "pod2": &api.Pod{}, <ins> "pod-with-http-healthcheck": &api.Pod{}, "service":                   &api.Service{}, "replication-controller":    &api.ReplicationController{}, </ins> }, }

```yaml kind: Service apiVersion: v1beta1 <del> id: nginxExample </del> <ins> # must be a DNS compatible name id: nginx-example </ins> # the port that this service should serve on port: 8000 # just like the selector in the replication controller, # but this time it identifies the set of pods to load balance # traffic to. selector: <del> - name: nginx </del> <ins> name: nginx </ins> # the container on each pod to connect to, can be a name # (e.g. 'www') or a number (e.g. 80) containerPort: 80

kind: Service apiVersion: v1beta1 <del> id: nginxExample </del> <ins> id: nginx-example </ins> # the port that this service should serve on port: 8000 # just like the selector in the replication controller, # but this time it identifies the set of pods to load balance # traffic to. selector: <del> - name: nginx </del> <ins> name: nginx </ins> # the container on each pod to connect to, can be a name # (e.g. 'www') or a number (e.g. 80) containerPort: 80