Change:
// GetActivePods returns non-terminal pods func (kl *Kubelet) GetActivePods() []*v1.Pod { <del> allPods := kl.podManager.GetPods() </del> <ins> allPods, mirrorPods := kl.podManager.GetPodsAndMirrorPods() mirrorPodSet := make(map[string]*v1.Pod) for _, p := range mirrorPods { mirrorPodSet[kubecontainer.GetPodFullName(p)] = p } for i := range allPods { podFullName := kubecontainer.GetPodFullName(allPods[i]) // replace static pod with mirror pod as some info (e.g. spec.Priority) // is needed to make further decisions (e.g. eviction) if mirrorPod, ok := mirrorPodSet[podFullName]; ok { allPods[i] = mirrorPod } } </ins> activePods := kl.filterOutTerminatedPods(allPods) return activePods }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks!--What happened: Eviction manager evicts the below static and critical pod when the node observed MemoryPressure. The k8s server version is v1.13.2, and the pod priority is enabled. As far as I can see, the eviction manager does not evict such pods. What you expected to happen: Static pods with are not deleted as well as those with a critical pod annotation. How to reproduce it (as minimally and precisely as possible): pod with system-node-critical priority using by kubelet option memory load to the target node until eviction manager observes memory pressure. critical and static pod is evicted. Anything else we need to know?: When I set critical-pod annotation (and enables ) insted of pod priority, the eviction manager DOES NOT evict the static and critical pod. Environment: Kubernetes version (use ): v1.13.2 Cloud provider or hardware configuration: baremetal
/sig node
from enable priority is , more than I can not understand why it has happened
Right. It seems the expected behavior and the actual behavior are different. will remove next k8s v1.14 (it's written in the document), but I'd like to wait for it until the critical priority can prevent eviction.
I see this as well. Start from the bottom and read up. It ranks ibm-master-proxy-static which is a static pod that has priority system-node-critical. It actually is always ranked first as well.
It can be replicated by causing disk pressure (using ) And then viewing the eviction manager logs. `journalctl -u kubelet | grep eviction There's also the piece that when the static pod is evicted kubelet never ends up starting it back up again.
Enabling ExperimentalCriticalPodAnnotation=true makes it not fail and detect properly
Setting on the static pod also works. It appears that a static pod doesn't get set based on . If this is expected then it should be documented. Although it seems like the priority class name should be honored for static pods.
I've confirmed that the problem occurs when a static pod has set to but does not set accordingly.

doesn't see the priority as being set and thus thinks the pod isn't critical which ultimately causes the eviction. I would have expected to translate to .
The code fix is available in master branch right now, which means it will be auto included in the upcoming 1.14 release. For lower releases, you need to wait for a while before cherrypick PRs get approved and merged.
Cherrypick PRs have been created and waiting for approval. 1.13 - 1.12 - 1.11 -
Your patch does not work for me. The case in that you completely replaces static pods with the mirror pods. But static pods contains important annotations such as . For static pods is , for mirror - . As a result, eviction manager supposes that pod is not static.
I doubt it. A mirror pod should be annotated with : Otherwise the PR won't pass the e2e test.
When I get static pod through I see . But when I try to debug eviction manager, I see that pod has annotation
Thanks for the info. Then we are sort of in a dilemma - on one hand annotation is needed to check if it's a static pod, on the other hand we also need the corresponding mirror pod to get the priority value. I will provide a supplemental fix later.
can we please hold on those cherry-picks until the supplemental fix is also available?
sure.
Here is a detailed explanation on why previous PR passed the e2e test: As , the critical static pod failed on IsStaticPod() check (because of mirror pod is tagged as " api") And it's reasonable that it's being marked as "to be deleted": However, as , there is some weird log showing: It's because the pod we passed onto () is a mirror pod, and it's deleted (or probably a dummy delete) by container runtime without any error. To take an analogy, it's sort of like a "controllee" (mirror pod) gets deleted, but "controller" (static pod) is still alive, so it causes data inconsistency, and the above error msg popped up. And in user's perspective, the static pod is "not" evicted, then it "looks" like previous PR works.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
Status of cherry pick PRs: 1.13 - - merged 1.12 - - merged 1.11 - - merged
/close As all PRs have been cherrypicked.
Closing this issue. <detailsIn response to : /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
When will this be released for 1.11.x? We are getting this same issue with and believe it's related: The api log:
Maybe in v1.11.10 (but I didn't see it in v1.11.10-beta.0 yet)
Thanks, I assume this is pretty high priority if it's causing to be evicted?
Yes. Prior to get it in 1.11.x, you can work it around by manually setting the priority value (not only setting priority name) to the control plane pods (apiserver, controller-manager and scheduler).
I think the priority value is correct:
Did you get that from ? If so, that's not sufficient. You should work around by hardcoding it into your static pod yaml file.
I did get it from , will try hardcoding. Thanks!
Were you successful ? I'm running into this same problem (unfortunately on a 1.10 cluster, which doesn't have this patch) and received the error: Looks like it comes from
I see this as well but the actual disk is not even full.