-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate critical pod annotation #10733
Conversation
Deploy preview for kubernetes-io-master-staging ready! Built with commit c5349fe https://deploy-preview-10733--kubernetes-io-master-staging.netlify.com |
Deploy preview for kubernetes-io-master-staging ready! Built with commit 6e48de3 https://deploy-preview-10733--kubernetes-io-master-staging.netlify.com |
*Warning:* currently there is no guarantee which node is chosen and which pods are being killed | ||
in order to schedule critical pods, so if rescheduler is enabled your pods might be occasionally | ||
killed for this purpose. Please ensure that rescheduler is not enabled along with priorities & preemptions in default-scheduler as rescheduler is oblivious to priorities and it may evict high priority pods, instead of low priority ones. | ||
before upgrading to Kubernetes 1.11 or higher.** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This message is a bit misleading. Priority is enabled by default in 1.11+. We should change the message and say that users should configure appropriate pod priorities for their critical pods.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. I will add it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`. | ||
|
||
The first one marks a pod a critical. The second one is required by Rescheduler algorithm. | ||
* have the `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should also change this and say that the pod must have its priorityClassName set to system-node-critical
or system-cluster-critical
and link to the pod priority doc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The subsequent section talks about using priority.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I think we should remove this paragraph given that we no longer want users to use this annotation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we remove this when we are deleting the critical pod annotation
completely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that these docs are versioned and we are changing this for 1.13, I think it makes sense to delete this paragraph. We don't want people to use this deprecated feature in 1.13.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, done. Thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, Ravi. Almost there. You can squash commits.
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`. | ||
|
||
The first one marks a pod a critical. The second one is required by Rescheduler algorithm. | ||
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/priorityClass/priorityClassName/
What I understand from this sentence is that both priorityClassName and the annotation are needed for a pod to be considered critical. So, I would write it as:
Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation with scheduler.alpha.kubernetes.io/critical-pod
as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ohh you are right, while reading it again, I got what you were telling. I have modified it.
* have the PodSpec's `tolerations` field set to `[{"key":"CriticalAddonsOnly", "operator":"Exists"}]`. | ||
|
||
The first one marks a pod a critical. The second one is required by Rescheduler algorithm. | ||
* Have the priorityClass set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster and `scheduler.alpha.kubernetes.io/critical-pod` annotation set to empty string(This will be deprecated too). | ||
|
||
A pod could also be considered critical, if its priority is greater than or equal to system-critical-priority. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line seems to be redundant.
Rescheduler doesn't have any user facing configuration (component config) or API. | ||
|
||
### Marking pod as critical when using Rescheduler. | ||
### Marking pod as critical. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove the period from the end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
cb4f984
to
6e48de3
Compare
Thanks for review @bsalamat - I have modified the content as per your suggestions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve
Thanks, @ravisantoshgudimetla! |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bsalamat, steveperry-53 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
### Marking pod as critical when priorites are enabled. | ||
|
||
To be considered critical, the pod has to run in the `kube-system` namespace (configurable via flag) and | ||
* Have the priorityClassName set as "system-cluster-critical" or "system-node-critical", the latter being the highest for entire cluster. Alternatively, you could add an annotation `scheduler.alpha.kubernetes.io/critical-pod` as key and empty string as value to your pod, but this annotation is deprecated as of version 1.13 and will be removed in 1.14. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should that be "former" instead of "latter?" It sounds like system-cluster-critical would be the highest priority, above system-node-critical.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@seh The text of the PR is correct. system-node-critical
is the highest priority. It means that the pod must run on the node. system-cluster-critical
means that the pod must run in the cluster. So, it is ok to evict it from the current node and schedule it somewhere else in the cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that makes sense now. Thank you for clarifying.
Having seen a similar sentence elsewhere in the code—mentioning "former" instead of "latter"—made me think I had found an inconsistent case here, but now I see those other sentences had the two classes reversed.
The CriticalAddonsOnly taint had been deprecated [1]. Critical add-on pods should use higher priority class now [2]. [1]: kubernetes/website#10733 [2]: https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/ Signed-off-by: Toshikuni Fukaya <toshikuni-fukaya@cybozu.co.jp>
As part of this PR.
/cc @bsalamat
/sig scheduling