Skip to content
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

Merged
merged 1 commit into from
Oct 30, 2018

Conversation

ravisantoshgudimetla
Copy link
Contributor

@ravisantoshgudimetla ravisantoshgudimetla commented Oct 25, 2018

As part of this PR.

  • Removed references to rescheduler which we removed in 1.13.
  • Added section for critical pod annotation deprecation because of pod priorities going to beta in 1.11.

/cc @bsalamat
/sig scheduling

@k8s-ci-robot k8s-ci-robot added the sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. label Oct 25, 2018
@kubernetes-docs-i18n-bot kubernetes-docs-i18n-bot added the language/en Issues or PRs related to English language label Oct 25, 2018
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 25, 2018
@k8sio-netlify-preview-bot
Copy link
Collaborator

Deploy preview for kubernetes-io-master-staging ready!

Built with commit c5349fe

https://deploy-preview-10733--kubernetes-io-master-staging.netlify.com

@k8sio-netlify-preview-bot
Copy link
Collaborator

k8sio-netlify-preview-bot commented Oct 25, 2018

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.**
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.
Copy link
Member

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.

Copy link
Contributor Author

@ravisantoshgudimetla ravisantoshgudimetla Oct 25, 2018

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, done. Thanks

Copy link
Member

@bsalamat bsalamat left a 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).
Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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.
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@ravisantoshgudimetla
Copy link
Contributor Author

ravisantoshgudimetla commented Oct 28, 2018

Thanks for review @bsalamat - I have modified the content as per your suggestions.

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 30, 2018
Copy link
Member

@bsalamat bsalamat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm
/approve

@bsalamat
Copy link
Member

Thanks, @ravisantoshgudimetla!

@steveperry-53
Copy link
Contributor

/approve

@k8s-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 30, 2018
@k8s-ci-robot k8s-ci-robot merged commit 315c716 into kubernetes:master Oct 30, 2018
### 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.
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor

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.

toshipp added a commit to topolvm/topolvm that referenced this pull request May 14, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. language/en Issues or PRs related to English language lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants