Issue 1:
In many threads / meetings I mentioned that we are not satisfied with today's container runtime interface due to many reasons. Here are the top reasons off my head:

Duplicated code for supporting SyncPod for all container runtime implementations, especially with Kubernetes defined policy: StartPolicy, PullPolicy, etc. We talked about changing today's declarative API to imperative API at this lowest extensible point.

Tight coupled with image format: docker runtime supports docker image, while rkt support appc image by converting docker image to its own format. In a long run, we want to add support for other image format without changing each runtime. There is no easy way to achieve that goal with today's API.

Logging management is very different on different os distro and with different runtime implementation. We should make this pluggable with runtime.

Part of resource isolation is handled by runtime today, while another part is handled by Kubelet. The decision is ad-hoc without much thinking. We need to decide if we want runtime interface to handle resource management or completely hand over to ResourceManager module in Kubelet since qos policy is defined by Kubernetes, and it might be redefined over releases.

...

In my mind, we should separate image management, resource / cgroup management, logging management from today's runtime interface. After this effort, we effectively make today's runtime interface as pod / container lifecycle management interface.

cc/ @kubernetes/sig-node, @bgrant0607

cc/ @philips and @jonboulle @yifan-gu from coreos

cc/ @smarterclayton @derekwaynecarr from redhat

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.):

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.):

#33729

they have a different bug

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

This is a BUG report

Kubernetes version (use kubectl version):

1.4.4

kubeadm init --use-kubernetes-version v1.4.6

kubeadm init --use-kubernetes-version v1.4.1

etc.

Environment:

Cloud provider or hardware configuration:

OS (e.g. from /etc/os-release):

ubuntu 16.04

Kernel (e.g. uname -a):

Install tools:

Others:

What happened:

the containers stay in pause mode: docker.ps shows (sorry, i gave my best for table layout)

COMMAND | NAMES

------------------ | ---------------------

"kube-controller-mana" | k8s_kube-controller-manager.

"kube-scheduler --v=2" | k8s_kube-scheduler.

"/pause" | k8s_POD.d8dbe16c_kube-controller-manager-

"/pause" | k8s_POD.d8dbe16c_kube-apiserver-

"/pause" | k8s_POD.d8dbe16c_etcd-

"/pause" | k8s_POD.d8dbe16c_kube-scheduler

What you expected to happen:

start the api container at port 8080 / 6443

How to reproduce it (as minimally and precisely as possible):

I just followed the tutorials.

Anything else do we need to know:

I have nothing listening at port 8080 / 443 / 6443. I do not know which parts of the syslog could be helpful. The first part is here:

http://pastebin.com/TUk1qsms

then come a lot of xy.service not handled by systemd

and then the useless attempts to connect to the (paused) node:

26360 manager.go:843] ignoring container "/system.slice/dev-hugepages.mount"

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.800147 26360 conversion.go:133] failed to handle multiple devices for container. Skipping Filesystem stats

Nov 15 18:15:52 laptop kubelet[26360]: E1115 18:15:52.825236 26360 eviction_manager.go:162] eviction manager: unexpected err: failed GetNode: node 'laptop.tu' not found

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.849907 26360 kubelet_node_status.go:203] Setting node annotation to enable volume controller attach/detach

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854325 26360 kubelet_node_status.go:354] Recording NodeHasSufficientDisk event message for node laptop.tu

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854354 26360 kubelet_node_status.go:354] Recording NodeHasSufficientMemory event message for node laptop.tu

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854367 26360 kubelet_node_status.go:354] Recording NodeHasNoDiskPressure event message for node laptop.tu

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854385 26360 kubelet_node_status.go:73] Attempting to register node laptop.tu

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854410 26360 server.go:608] Event(api.ObjectReference{Kind:"Node", Namespace:"", Name:"laptop.tu", UID:"laptop.tu", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'NodeHasSufficientDisk' Node laptop.tu status is now: NodeHasSufficientDisk

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854466 26360 server.go:608] Event(api.ObjectReference{Kind:"Node", Namespace:"", Name:"laptop.tu", UID:"laptop.tu", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'NodeHasSufficientMemory' Node laptop.tu status is now: NodeHasSufficientMemory

Nov 15 18:15:52 laptop kubelet[26360]: I1115 18:15:52.854594 26360 server.go:608] Event(api.ObjectReference{Kind:"Node", Namespace:"", Name:"laptop.tu", UID:"laptop.tu", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Normal' reason: 'NodeHasNoDiskPressure' Node laptop.tu status is now: NodeHasNoDiskPressure

Nov 15 18:15:52 laptop kubelet[26360]: E1115 18:15:52.854691 26360 kubelet_node_status.go:97] Unable to register node "laptop.tu" with API server: Post https://192.168.0.2:6443/api/v1/nodes: dial tcp 192.168.0.2:6443: getsockopt: connection refused

It does this for the next couple of hours. Then I kick my laptop out of the window. Usually this stops the entrys.

What can I do? Where is the one parameter to rule the stuff? Do you need more information?