<p dir="auto"><strong>Is this a request for help?</strong> (If yes, you should use our troubleshooting guide and community support channels, see <a href="http://kubernetes.io/docs/troubleshooting/" rel="nofollow">http://kubernetes.io/docs/troubleshooting/</a>.):</p>
<p dir="auto"><strong>What keywords did you search in Kubernetes issues before filing this one?</strong> (If you have found any duplicates, you should instead reply there.): "static pod orphaned" and "static pod register-node"</p>
<hr>
<p dir="auto"><strong>Is this a BUG REPORT or FEATURE REQUEST?</strong> (choose one): BUG REPORT</p>

<p dir="auto"><strong>Kubernetes version</strong> (use <code class="notranslate">kubectl version</code>): v1.5.0-beta.2</p>
<p dir="auto"><strong>Environment</strong>:</p>
<ul dir="auto">
<li><strong>Cloud provider or hardware configuration</strong>: azure</li>
<li><strong>OS</strong> (e.g. from /etc/os-release): CentOS 7</li>
<li><strong>Kernel</strong> (e.g. <code class="notranslate">uname -a</code>): Linux master-1 4.8.11-1.el7.elrepo.x86_64 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="35192559" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/1" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/1/hovercard" href="https://github.com/kubernetes/kubernetes/issues/1">#1</a> SMP Sat Nov 26 11:13:42 EST 2016 x86_64 x86_64 x86_64 GNU/Linux</li>
<li><strong>Install tools</strong>: kargo (+custom changes)</li>
<li><strong>Others</strong>:</li>
</ul>
<p dir="auto"><strong>What happened</strong>:<br>
The controller-manager logs repeatedly show that it deleted orphaned pods which belong to the static pods of kubelets which have "--register-node=false" set:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="I1206 11:31:14.941598       1 gc_controller.go:184] Found orphaned Pod kube-controller-manager-master-1 assigned to the Node master-1. Deleting.
I1206 11:31:14.941605       1 gc_controller.go:71] PodGC is force deleting Pod: kube-system:kube-controller-manager-master-1
I1206 11:31:15.425141       1 gc_controller.go:188] Forced deletion of orphaned Pod kube-controller-manager-master-1 succeeded"><pre class="notranslate"><code class="notranslate">I1206 11:31:14.941598       1 gc_controller.go:184] Found orphaned Pod kube-controller-manager-master-1 assigned to the Node master-1. Deleting.
I1206 11:31:14.941605       1 gc_controller.go:71] PodGC is force deleting Pod: kube-system:kube-controller-manager-master-1
I1206 11:31:15.425141       1 gc_controller.go:188] Forced deletion of orphaned Pod kube-controller-manager-master-1 succeeded
</code></pre></div>
<p dir="auto">The pods/containers are not really deleted. It looks like only the "mirror" PODs are deleted and later readded. But I'm not sure about this as I did not dig into mirror PODs that deep.</p>
<p dir="auto">The POD status seems to be jumping from "Running" to "Pending" and back after every few seconds.</p>
<p dir="auto"><strong>What you expected to happen</strong>:<br>
I'd expect that the gc_controller would ignore static/mirror PODs in this case. I'm not sure how GC should work here in case the source kubelet dies as we don't have node status here.</p>
<p dir="auto"><strong>How to reproduce it</strong> (as minimally and precisely as possible):<br>
Run a kubelet with "--register-node=false" and add some static PODs/manifests. kargo for example does this at the moment.</p>
<p dir="auto"><strong>Anything else do we need to know</strong>:</p>
<p dir="auto">Forked from <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="144977919" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/23684" data-hovercard-type="pull_request" data-hovercard-url="/kubernetes/kubernetes/pull/23684/hovercard" href="https://github.com/kubernetes/kubernetes/pull/23684">#23684</a> ...</p>
<p dir="auto">There are debate over that pr on system automatically publishs the fields in NodeStatus.NodeSystemInfo. I don't fully understand the concern, but in my opinion, the advantage of publishing those labels will help debugging and analyzing the issues related to different OSImage, RuntimeVersion, KubeletVersion, etc. especially for a large cluster (&gt; 100 nodes).</p>
<p dir="auto">cc/ <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/bgrant0607/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/bgrant0607">@bgrant0607</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/davidopp/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/davidopp">@davidopp</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/vishh/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/vishh">@vishh</a></p>