Add "scheduler.alpha.kubernetes.io/critical-pod" annotation

[Dema]

As described in https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-add-on-as-critical
we should add critical-pod annotation for newer kubernetes versions to further ensure that flannel will not be kicked from the node under memory pressure.

Expected Behavior

Pod to stay scheduled and active on the node under memory pressure

Current Behavior

Pod is not being admitted on the node under memory pressure

Possible Solution

Steps to Reproduce (for bugs)

1. Have a memory pressure
2. Watch the flannel pod in Pending state

Context

Your Environment

• Flannel version:
• Backend used (e.g. vxlan or udp):
• Etcd version:
• Kubernetes version (if used):
  1.9.1 with - --feature-gates=ExperimentalCriticalPodAnnotation=true enabled
• Operating System and version:
  Gentoo linux
  8G of RAM
• Link to your project (optional):

[tomdee]

@Dema That sounds like a great idea. Do you know what K8s version is was introduced in?

PRs are of course always welcome 😄

[drake7707]

The annotation is deprecated as the entire rescheduler will be removed starting from v1.12+. Flagging pods as critical is now done by applying a priorityclass, which is supported for out of resource eviction since v1.9, see the documentation over at https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/

(In v1.11 at least) there are 2 priority classes set up by default:

$ kubectl get priorityclass
NAME                      CREATED AT
system-cluster-critical   2018-07-04T10:05:08Z
system-node-critical      2018-07-04T10:05:08Z

Which are defined as follows:

$ kubectl describe priorityclass system-node-critical
Name:           system-node-critical
Value:          2000001000
GlobalDefault:  false
Description:    Used for system critical pods that must not be moved from their current node.
Annotations:    <none>
Events:         <none>

$ kubectl describe priorityclass system-cluster-critical
Name:           system-cluster-critical
Value:          2000000000
GlobalDefault:  false
Description:    Used for system critical pods that must run in the cluster, but can be moved to another node if necessary.
Annotations:    <none>
Events:         <none>

It should suffice to add priorityClassName: system-node-critical in the pod spec to flag it as critical.

[MohdAhmad]

@tomdee I'm happy to send a PR for this but are flannel releases tied to k8s releases in any way? Because I believe setting the priority class on kubernetes versions prior to 1.11 without setting --feature-gates=PodPriority=true in the kubelet will lead to a crash.

[dlipovetsky]

I believe setting the priority class on kubernetes versions prior to 1.11 without setting --feature-gates=PodPriority=true in the kubelet will lead to a crash.

I just patched the v0.10.0 kube-flannel.yml manifest, adding priorityClassName: system-node-critical to Pod spec nested in the DaemonSet spec. I then applied the manifest to a v1.10.4 cluster that does not have the PodPriority feature enabled.

The manifest was successfully applied and flannel is running as expected. The API server did remove the priorityClassName field from the Pod spec, but I think that is expected.

This leads me to conclude that adding the priorityClassname field to flannel Pod spec will not break backward compatibility with v1.10.x clusters, though testing against other versions may be warranted.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.