Question: --- title: "Workloads" <del> weight: 50 </del> <ins> weight: 55 </ins> description: > Understand Pods, the smallest deployable compute object in Kubernetes, and the higher-level abstractions that help you to run them. no_list: true

This is a Bug Report Problem: Some pages at the same width have the same weight in their . Originally, the pages have to be sorted based on weights even when localizing the documents. However, for some pages with the same weight at the same level, they are sorted in the order of the strings of the translated titles, which makes them out of order with the English documents. Each localization teams might change the weight according to their language and put them in the right order, but I think it would be better to change the overall weights in the English document. And more than 100 pages need to be modified. For example in Korean, the pages are sorted by first letter of "Korean-translated title", the order of pages below in Korean is different with that of English. English ! Korean ! <brProposed Solution: Re-order every page that has the same weight in the same level. Page to Update: If you guys think this is needed, I will organize all the pages that need to be modified at the comment. I have structured the pages of the whole document like below. Pairs with the same weights are marked with [ N ] at the beginning of the title. The value at the end of the title is each of their weights. <img width="663" alt="image" src="https://user-"<br/kind cleanup /assign
Given how much this is a problem for localizations, we could (should?) add a CI test to warn when two pages have an equal weight in a section - that'd be a way to stop the problem returning. I presume that pages with no weight declared are also a problem for the same reason.
Thank you for comment and add as a CI test seems good idea! But before adding, wouldn't it be better to check it once and make changes, and then add this task to a CI test? :smiley: As you commented, there were some pages that had no weights, too!
I'm OK with either order. Folks can work on the CI test first, or the manual fix first. We'll only really get value if we do both of those things (otherwise, we'll tend to find that we return to a state where page weights overlap). Another fix might be to sort localized pages with overlapping weight based on the collation order of the English equivalent page.

That does not sound easy, mind!
Neither do I think it's not easy to change the weights according to each Localizations. That's why I opened an issue for English documentation!! Would it be better to open a PR first(with personally modified wieghts) and then get a review, or would it be better to agree on the appropriate weights here first??
Thank you for bringing this up in the localization meeting yesterday! After chatting about it in the meeting, we determined, based on the research done by there aren't any sections where overlapping page weights are causing a different ordered side navigation in localized content that will disrupt users from understanding content. Meaning, there aren't any sections in the side nav where this issue is occurring and a user would need to read the pages in a specific order. Our recommended action is: this as an issue within the broader sig docs community, in slack and in the next community meeting, to make sure folks working on the English language docs understand the importance of page weights and potential problem overlapping pages weights cause in localized content. Use a "lazy" updating approach, to adjust English language page weights as a page is updated. I think if we implemented idea for adding a CI warning that would help speed up making the adjustments to each English page. may also want to add a note to our docs to highlight that we shouldn't use overlapping weights within a section. and does this sound like a good summary of our discussion? Did i miss anything? cc:
Thank you for your opinion !! I also agree that each localization teams would be nice to aware of this even if it doesn't need to be modified now! For docs, it seems great idea, and I'll open an issue for that!
/triage accepted
/area localization
Watch out for updating the weight values for pages that are autogenerated - we should teach the page generator to produce our preferred values instead.
/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
During the docs sprint we were tracking the areas that we already checked for page weights issues in this Hack MD file: Pages that have been checked off on the list were reviewed or a PR was opened to address the issue.

Anything left unchecked still needs to be be reviewed and possibly updated. Note, the reference docs are mostly autogenerated and do not need to be updated.
/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
I've reviewed the hackmd file and it looks like the only section of the docs that hasn't been reviewed is the section. There is a PR open that addresses the page weights of files for the folders in the Tasks section, But there has not been a review for any of the pages within any of the folders. This is a rather large section of the docs and will definitely need to have page weights adjusted in some areas.
Hi Do you have a script to check the current weights ? if then, I think we could check remaining tasks for this issue. :)
Yes I have, but the script is not clean at all. If you need it immediately, I can upload(or send) the script right now. If not, I'll send it to you after refactoring.
It is just for checking remaining tasks :) no need to hurry :)
I've been working on making PRs to finish this issue up. The largest section left to do is the Tasks section. I plan to have PRs to cover those updates this week. Sorry i've left off wrapping this up for so long, but hopefully we can get all the page weights updated in english soon
I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. Feel free to reopen this issue if necessary. /close
Closing this issue. <detailsIn response to : I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. </details


Question: status to master if node status does not change. Kubelet will ignore this frequency and post node status immediately if any change is detected. It is only used when node lease feature is enabled. nodeStatusReportFrequency's  default value is 1m. But if nodeStatusUpdateFrequency is set explicitly,   default value is 5m. But if nodeStatusUpdateFrequency is set explicitly,  nodeStatusReportFrequency's default value will be set to nodeStatusUpdateFrequency for backward compatibility.  Default: "1m"	   Default: "5m"

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Visiting provides inaccurate default values for shutdownGracePeriod (30s rather than 0s) and shutdownGracePeriodCriticalPods (10s rather than 0s). Proposed Solution: Correct the documentation to match the actual default values. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
I would like to take up this ticket.


Question: This would create a CSR for the username "jbeda", belonging to two groups, "app1" and "app2". <del> See [Managing Certificates](/docs/concepts/cluster-administration/certificates/) for how to generate a client cert. </del> <ins> See [Managing Certificates](/docs/tasks/administer-cluster/certificates/) for how to generate a client cert. </ins> ### Static Token File

This is a clean up request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed is a task page. A better home for it would be within Comments Be sure to add Netlify redirects (see ) from the old to the new page. /language en /kind cleanup
/assign
From (I agree)
/sig auth
/triage accepted
I left notes (PR ) about how to create a new task page from the page. Does this sound like a good approach?


Question: ### Upgrade additional control plane nodes <del> 1.  Same as the first control plane node but use: </del> <ins> Same as the first control plane node but use: </ins> <del> ``` sudo kubeadm upgrade node ``` </del> <ins> ``` sudo kubeadm upgrade node ``` </ins> <del> instead of: </del> <ins> instead of: </ins> <del> ``` sudo kubeadm upgrade apply ``` </del> <ins> ``` sudo kubeadm upgrade apply ``` </ins> <del> Also `sudo kubeadm upgrade plan` is not needed. </del> <ins> Also `sudo kubeadm upgrade plan` is not needed. </ins> ### Upgrade kubelet and kubectl <del> 1.  Upgrade the kubelet and kubectl on all control plane nodes: </del> <ins> Upgrade the kubelet and kubectl on all control plane nodes: </ins> <del> {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_kubelet" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </ins> # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl &&  apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 &&  apt-mark hold kubelet kubectl <ins> - </ins> # since apt-get version 1.1 you can also use the following method apt-get update &&  apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </ins> # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> <del> 1.  Restart the kubelet </del> <ins> Restart the kubelet </ins> <del> ```shell sudo systemctl restart kubelet ``` </del> <ins> ```shell sudo systemctl restart kubelet ``` </ins> ## Upgrade worker nodes

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--indentation issue Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--18 <!--Additional Information:--fix the page indentation
/sig cluster-lifecycle docs hi, can you show which section you think is wrong or maybe provide a screenshot?
/sig cluster-lifecycle docs Attached screenshots
i don't see the attachments, possibly because you replied via email. try adding them using the GitHub web UI.
! ! ! !
Page alignment or indentation not proper looks.
ok, i can confirm this. hi, was this broken by this PR, or maybe something on the hugo side changed recently?
The Hugo upgrade was PR
/kind bug /priority important-longterm
I've tried to make a work around for this. It looks like tabs shortcodes with code snippets inside them don't play well with shortcodes (see issue ).
I will take a stab at cleaning this up assuming work isn't currently being done. We might have to adjust the page slightly until capture is removed. /assign
I can share some WIP in case it helps
thanks for taking a look and
oof, sorry I saw this after I opened the PR. That does help! I was scratching my head on some of these bugs. Let me know if you want me to modify my PR to incorporate some of your suggestions or vice versa. I was poking fun of the page on twitter and felt obligated to try to fix it :smile:
Busy at the moment I'm afraid. Feel free to snarf any bits that look useful.


Question: <ins> --- layout: blog title: "逐个 KEP 地增强 Kubernetes" date: 2022-08-11 slug: enhancing-kubernetes-one-kep-at-a-time --- <!-- layout: blog title: "Enhancing Kubernetes one KEP at a Time" date: 2022-08-11 slug: enhancing-kubernetes-one-kep-at-a-time canonicalUrl: https://www.k8s.dev/blog/2022/08/11/enhancing-kubernetes-one-kep-at-a-time/ --> <!-- **Author:** Ryler Hockenbury (Mastercard) --> **作者：** Ryler Hockenbury（Mastercard） <!-- Did you know that Kubernetes v1.24 has [46 enhancements](https://kubernetes.io/blog/2022/05/03/kubernetes-1-24-release-announcement/)? That's a lot of new functionality packed into a 4-month release cycle. The Kubernetes release team coordinates the logistics of the release, from remediating test flakes to publishing updated docs. It's a ton of work, but they always deliver. The release team comprises around 30 people across six subteams - Bug Triage, CI Signal, Enhancements, Release Notes, Communications, and Docs.  Each of these subteams manages a component of the release. This post will focus on the role of the enhancements subteam and how you can get involved. --> 你是否知道 Kubernetes v1.24 有 [46 个增强特性](https://kubernetes.io/zh-cn/blog/2022/05/03/kubernetes-1-24-release-announcement/)？ 在为期 4 个月的发布周期内包含了大量新特性。 Kubernetes 发布团队协调发布的后勤工作，从修复测试问题到发布更新的文档。他们需要完成成吨的工作，但发布团队总是能按期交付。 发布团队由大约 30 人组成，分布在六个子团队：Bug Triage、CI Signal、Enhancements、Release Notes、Communications 和 Docs。 每个子团队负责管理发布的一个组件。这篇博文将重点介绍增强子团队的角色以及你如何能够参与其中。 <!-- ## What's the enhancements subteam? Great question. We'll get to that in a second but first, let's talk about how features are managed in Kubernetes. Each new feature requires a [Kubernetes Enhancement Proposal](https://github.com/kubernetes/enhancements/blob/master/keps/README.md) - KEP for short. KEPs are small structured design documents that provide a way to propose and coordinate new features. The KEP author describes the motivation, design (and alternatives), risks, and tests - then community members provide feedback to build consensus. --> ## 增强子团队是什么？ 好问题。我们稍后会讨论这个问题，但首先让我们谈谈 Kubernetes 中是如何管理功能特性的。 每个新特性都需要一个 [Kubernetes 增强提案](https://github.com/kubernetes/enhancements/blob/master/keps/README.md)， 简称为 KEP。KEP 是一些小型结构化设计文档，提供了一种提出和协调新特性的方法。 KEP 作者描述其提案动机、设计理念（和替代方案）、风险和测试，然后社区成员会提供反馈以达成共识。 <!-- KEPs are submitted and updated through a pull request (PR) workflow on the [k/enhancements repo](https://github.com/kubernetes/enhancements). Features start in alpha and move through a graduation process to beta and stable as they mature. For example, here's a cool KEP about [privileged container support on Windows Server](https://github.com/kubernetes/enhancements/blob/master/keps/sig-windows/1981-windows-privileged-container-support/kep.yaml).  It was introduced as alpha in Kubernetes v1.22 and graduated to beta in v1.23. Now getting back to the question - the enhancements subteam coordinates the lifecycle tracking of the KEPs for each release. Each KEP is required to meet a set of requirements to be cleared for inclusion in a release. The enhancements subteam verifies each requirement for each KEP and tracks the status. --> 你可以通过 [Kubernetes/enhancements 仓库](https://github.com/kubernetes/enhancements)的拉取请求（PR）工作流来提交和更新 KEP。 每个功能特性始于 Alpha 阶段，随着不断成熟，经由毕业流程进入 Beta 和 Stable 阶段。 这里有一个很酷的 KEP 例子，是关于 [Windows Server 上的特权容器支持](https://github.com/kubernetes/enhancements/blob/master/keps/sig-windows/1981-windows-privileged-container-support/kep.yaml)。 这个 KEP 在 Kubernetes v1.22 中作为 Alpha 引入，并在 v1.23 中进入 Beta 阶段。 现在回到上一个问题：增强子团队如何协调每个版本的 KEP 生命周期跟踪。 每个 KEP 都必须满足一组清晰具体的要求，才能被纳入一个发布版本中。 增强子团队负责验证每个 KEP 的要求并跟踪其状态。 <!-- At the start of a release, [Kubernetes Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) submit their enhancements to opt into a release. A typical release might have from 60 to 90 enhancements at the beginning.  During the release, many enhancements will drop out. Some do not quite meet the KEP requirements, and others do not complete their implementation in code. About 60%-70% of the opted-in KEPs will make it into the final release. --> 在一个发行版本启动时，各个 [Kubernetes 特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIG) 会提交各自的增强特性以进入某版本发布。通常一个版本最初可能有 60 到 90 个增强特性。随后，许多增强特性会被过滤掉。 这是因为有些不完全符合 KEP 要求，而另一些还未完成代码的实现。最初选择加入的 KEP 中大约有 60% - 70% 将进入最终发布。 <!-- ## What does the enhancements subteam do? Another great question, keep them coming! The enhancements team is involved in two crucial milestones during each release: enhancements freeze and code freeze. --> ## 增强子团队做什么？ 这是另一个很好的问题，切中了要点！增强特性的团队在每个版本中会涉及两个重要的里程碑：增强特性冻结和代码冻结。 <!-- #### Enhancements Freeze Enhancements freeze is the deadline for a KEP to be complete in order for the enhancement to be included in a release. It's a quality gate to enforce alignment around maintaining and updating KEPs. The most notable requirements are a (1) [production readiness review ](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md)(PRR) and a (2) [KEP file](https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template) with a complete test plan and graduation criteria. --> #### 增强特性冻结 增强特性冻结是一个 KEP 按序完成增强特性并纳入一个发布版本的最后期限。 这是一个质量门控，用于强制对齐与 KEP 维护和更新相关的事项。 最值得注意的要求是 (1) [生产就绪审查](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md)(PRR) 和 (2) 附带完整测试计划和毕业标准的 [KEP 文件](https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template)。 <!-- The enhancements subteam communicates to each KEP author through comments on the KEP issue on Github. As a first step, they'll verify the status and check if it meets the requirements.  The KEP gets marked as tracked after satisfying the requirements; otherwise, it's considered at risk. If a KEP is still at risk when enhancement freeze is in effect, the KEP is removed from the release. This part of the cycle is typically the busiest for the enhancements subteam because of the large number of KEPs to groom, and each KEP might need to be visited multiple times to verify whether it meets requirements. --> 增强子团队通过在 Github 上对 KEP 问题发表评论与每位 KEP 作者进行沟通。 作为第一步，子团队成员将检查 KEP 状态并确认其是否符合要求。 KEP 在满足要求后被标记为已被跟踪（Tracked）；否则，它会被认为有风险。 如果在增强特性冻结生效时 KEP 仍然存在风险，该 KEP 将被从发布版本中移除。 在发布周期的这个阶段，增强子团队通常是最繁忙的，因为他们要梳理大量的 KEP，可能需要反复审查每个 KEP 才能验证某个 KEP 是否满足要求。 <!-- #### Code Freeze Code freeze is the implementation deadline for all enhancements. The code must be implemented, reviewed, and merged by this point if a code change or update is needed for the enhancement. The latter third of the release is focused on stabilizing the codebase - fixing flaky tests, resolving various regressions, and preparing docs - and all the code needs to be in place before those steps can happen. The enhancements subteam verifies that all PRs for an enhancement are merged into the [Kubernetes codebase](https://github.com/kubernetes/kubernetes) (k/k). During this period, the subteam reaches out to KEP authors to understand what PRs are part of the KEP, verifies that those PRs get merged, and then updates the status of the KEP. The enhancement is removed from the release if the code isn't all merged before the code freeze deadline. --> #### 代码冻结 代码冻结是从代码上实现所有增强特性的最后期限。 如果某增强特性的代码需要更改或更新，则必须在这个时间节点完成所有代码实现、代码审查和代码合并工作。 版本发布的最后三个工作专注于稳定代码库：修复测试问题，解决各种回归并准备文档。而在此之前，所有代码必须就位。 增强子团队将验证某增强特性相关的所有 PR 均已合并到 [Kubernetes 代码库](https://github.com/kubernetes/kubernetes) (k/k)。 在此期间，子团队将联系 KEP 作者以了解哪些 PR 是 KEP 的一部分，检查这些 PR 是否已合并，然后更新 KEP 的状态。 如果在代码冻结的最后期限之前这些代码还未全部合并，该增强特性将从发布版本中移除。 <!-- ## How can I get involved with the release team? I'm glad you asked. The most direct way is to apply to be a [release team shadow](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md). The shadow role is a hands-on apprenticeship intended to prepare individuals for leadership positions on the release team. Many shadow roles are non-technical and do not require prior contributions to the Kubernetes codebase. With 3 Kubernetes releases every year and roughly 25 shadows per release, the release team is always in need of individuals wanting to contribute. Before each release cycle, the release team opens the application for the shadow program. When the application goes live, it's posted in the [Kubernetes Dev Mailing List](https://groups.google.com/a/kubernetes.io/g/dev).  You can subscribe to notifications from that list (or check it regularly!) to watch when the application opens. The announcement will typically go out in mid-April, mid-July, and mid-December - or roughly a month before the start of each release. --> ## 我如何才能参与发布团队？ 很高兴你提出这个问题。 最直接的方式就是申请成为一名[发布团队影子](https://github.com/kubernetes/sig-release/blob/master/release-team/shadows.md)。 影子角色是一个见习职位，旨在帮助个人在发布团队中担任领导职位做好准备。许多影子角色是非技术性的，且不需要事先对 Kubernetes 代码库做出贡献。 Kubernetes 每年发布 3 个版本，每个版本大约有 25 个影子，发布团队总是需要愿意做出贡献的人。 在每个发布周期之前，发布团队都会为影子计划打开申请渠道。当申请渠道上线时， 会公布在 [Kubernetes 开发邮件清单](https://groups.google.com/a/kubernetes.io/g/dev)中。 你可以订阅该列表中的通知（或定期查看！），以了解申请渠道何时开通。该公告通常会在 4 月中旬、7 月中旬和 12 月中旬发布， 或者在每个版本开始前大约一个月时发布。 <!-- ## How can I find out more? Check out the [role handbooks](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks) if you're curious about the specifics of all the Kubernetes release subteams. The handbooks capture the logistics of each subteam, including a week-by-week breakdown of the subteam activities.  It's an excellent reference for getting to know each team better. You can also check out the release-related Kubernetes slack channels - particularly #release, #sig-release, and #sig-arch. These channels have discussions and updates surrounding many aspects of the release. --> ## 我怎样才能找到更多信息？ 如果你对所有 Kubernetes 发布子团队的详情感到好奇， 请查阅[角色手册](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks)。 这些手册记录了每个子团队的后勤工作，包括每周对子团队活动的细分任务。这是更好地了解每个团队的绝佳参考。 你还可以查看与发布相关的 Kubernetes slack 频道，特别是 #release、#sig-release 和 #sig-arch。 这些频道围绕发布的许多方面进行了讨论和更新。 </ins>

This is a Feature Request Will add zh-cn text for:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
/language zh /assign


Question: <del> --- reviewers: - davidopp - wojtek-t title: Pod Priority and Preemption content_type: concept weight: 70 --- <!-- overview --> {{< feature-state for_k8s_version="v1.14" state="stable" >}} [Pods](/docs/concepts/workloads/pods/) can have _priority_. Priority indicates the importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. <!-- body --> {{< warning >}} In a cluster where not all users are trusted, a malicious user could create Pods at the highest possible priorities, causing other Pods to be evicted/not get scheduled. An administrator can use ResourceQuota to prevent users from creating pods at high priorities. See [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) for details. {{< /warning >}} ## How to use priority and preemption To use priority and preemption: 1.  Add one or more [PriorityClasses](#priorityclass). 1.  Create Pods with[`priorityClassName`](#pod-priority) set to one of the added PriorityClasses. Of course you do not need to create the Pods directly; normally you would add `priorityClassName` to the Pod template of a collection object like a Deployment. Keep reading for more information about these steps. {{< note >}} Kubernetes already ships with two PriorityClasses: `system-cluster-critical` and `system-node-critical`. These are common classes and are used to [ensure that critical components are always scheduled first](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/). {{< /note >}} ## PriorityClass A PriorityClass is a non-namespaced object that defines a mapping from a priority class name to the integer value of the priority. The name is specified in the `name` field of the PriorityClass object's metadata. The value is specified in the required `value` field. The higher the value, the higher the priority. The name of a PriorityClass object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names), and it cannot be prefixed with `system-`. A PriorityClass object can have any 32-bit integer value smaller than or equal to 1 billion. Larger numbers are reserved for critical system Pods that should not normally be preempted or evicted. A cluster admin should create one PriorityClass object for each such mapping that they want. PriorityClass also has two optional fields: `globalDefault` and `description`. The `globalDefault` field indicates that the value of this PriorityClass should be used for Pods without a `priorityClassName`. Only one PriorityClass with `globalDefault` set to true can exist in the system. If there is no PriorityClass with `globalDefault` set, the priority of Pods with no `priorityClassName` is zero. The `description` field is an arbitrary string. It is meant to tell users of the cluster when they should use this PriorityClass. ### Notes about PodPriority and existing clusters -   If you upgrade an existing cluster without this feature, the priority of your existing Pods is effectively zero. -   Addition of a PriorityClass with `globalDefault` set to `true` does not change the priorities of existing Pods. The value of such a PriorityClass is used only for Pods created after the PriorityClass is added. -   If you delete a PriorityClass, existing Pods that use the name of the deleted PriorityClass remain unchanged, but you cannot create more Pods that use the name of the deleted PriorityClass. ### Example PriorityClass ```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority value: 1000000 globalDefault: false description: "This priority class should be used for XYZ service pods only." ``` ## Non-preempting PriorityClass {#non-preempting-priority-class} {{< feature-state for_k8s_version="v1.19" state="beta" >}} Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue ahead of lower-priority pods, but they cannot preempt other pods. A non-preempting pod waiting to be scheduled will stay in the scheduling queue, until sufficient resources are free, and it can be scheduled. Non-preempting pods, like other pods, are subject to scheduler back-off. This means that if the scheduler tries these pods and they cannot be scheduled, they will be retried with lower frequency, allowing other pods with lower priority to be scheduled before them. Non-preempting pods may still be preempted by other, high-priority pods. `PreemptionPolicy` defaults to `PreemptLowerPriority`, which will allow pods of that PriorityClass to preempt lower-priority pods (as is existing default behavior). If `PreemptionPolicy` is set to `Never`, pods in that PriorityClass will be non-preempting. An example use case is for data science workloads. A user may submit a job that they want to be prioritized above other workloads, but do not wish to discard existing work by preempting running pods. The high priority job with `PreemptionPolicy: Never` will be scheduled ahead of other queued pods, as soon as sufficient cluster resources "naturally" become free. ### Example Non-preempting PriorityClass ```yaml apiVersion: scheduling.k8s.io/v1 kind: PriorityClass metadata: name: high-priority-nonpreempting value: 1000000 preemptionPolicy: Never globalDefault: false description: "This priority class will not cause other pods to be preempted." ``` ## Pod priority After you have one or more PriorityClasses, you can create Pods that specify one of those PriorityClass names in their specifications. The priority admission controller uses the `priorityClassName` field and populates the integer value of the priority. If the priority class is not found, the Pod is rejected. The following YAML is an example of a Pod configuration that uses the PriorityClass created in the preceding example. The priority admission controller checks the specification and resolves the priority of the Pod to 1000000. ```yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent priorityClassName: high-priority ``` ### Effect of Pod priority on scheduling order When Pod priority is enabled, the scheduler orders pending Pods by their priority and a pending Pod is placed ahead of other pending Pods with lower priority in the scheduling queue. As a result, the higher priority Pod may be scheduled sooner than Pods with lower priority if its scheduling requirements are met. If such Pod cannot be scheduled, scheduler will continue and tries to schedule other lower priority Pods. ## Preemption When Pods are created, they go to a queue and wait to be scheduled. The scheduler picks a Pod from the queue and tries to schedule it on a Node. If no Node is found that satisfies all the specified requirements of the Pod, preemption logic is triggered for the pending Pod. Let's call the pending Pod P. Preemption logic tries to find a Node where removal of one or more Pods with lower priority than P would enable P to be scheduled on that Node. If such a Node is found, one or more lower priority Pods get evicted from the Node. After the Pods are gone, P can be scheduled on the Node. ### User exposed information When Pod P preempts one or more Pods on Node N, `nominatedNodeName` field of Pod P's status is set to the name of Node N. This field helps scheduler track resources reserved for Pod P and also gives users information about preemptions in their clusters. Please note that Pod P is not necessarily scheduled to the "nominated Node". After victim Pods are preempted, they get their graceful termination period. If another node becomes available while scheduler is waiting for the victim Pods to terminate, scheduler will use the other node to schedule Pod P. As a result `nominatedNodeName` and `nodeName` of Pod spec are not always the same. Also, if scheduler preempts Pods on Node N, but then a higher priority Pod than Pod P arrives, scheduler may give Node N to the new higher priority Pod. In such a case, scheduler clears `nominatedNodeName` of Pod P. By doing this, scheduler makes Pod P eligible to preempt Pods on another Node. ### Limitations of preemption #### Graceful termination of preemption victims When Pods are preempted, the victims get their [graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). They have that much time to finish their work and exit. If they don't, they are killed. This graceful termination period creates a time gap between the point that the scheduler preempts Pods and the time when the pending Pod (P) can be scheduled on the Node (N). In the meantime, the scheduler keeps scheduling other pending Pods. As victims exit or get terminated, the scheduler tries to schedule Pods in the pending queue. Therefore, there is usually a time gap between the point that scheduler preempts victims and the time that Pod P is scheduled. In order to minimize this gap, one can set graceful termination period of lower priority Pods to zero or a small number. #### PodDisruptionBudget is supported, but not guaranteed A [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB) allows application owners to limit the number of Pods of a replicated application that are down simultaneously from voluntary disruptions. Kubernetes supports PDB when preempting Pods, but respecting PDB is best effort. The scheduler tries to find victims whose PDB are not violated by preemption, but if no such victims are found, preemption will still happen, and lower priority Pods will be removed despite their PDBs being violated. #### Inter-Pod affinity on lower-priority Pods A Node is considered for preemption only when the answer to this question is yes: "If all the Pods with lower priority than the pending Pod are removed from the Node, can the pending Pod be scheduled on the Node?" {{< note >}} Preemption does not necessarily remove all lower-priority Pods. If the pending Pod can be scheduled by removing fewer than all lower-priority Pods, then only a portion of the lower-priority Pods are removed. Even so, the answer to the preceding question must be yes. If the answer is no, the Node is not considered for preemption. {{< /note >}} If a pending Pod has inter-pod affinity to one or more of the lower-priority Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence of those lower-priority Pods. In this case, the scheduler does not preempt any Pods on the Node. Instead, it looks for another Node. The scheduler might find a suitable Node or it might not. There is no guarantee that the pending Pod can be scheduled. Our recommended solution for this problem is to create inter-Pod affinity only towards equal or higher priority Pods. #### Cross node preemption Suppose a Node N is being considered for preemption so that a pending Pod P can be scheduled on N. P might become feasible on N only if a Pod on another Node is preempted. Here's an example: *   Pod P is being considered for Node N. *   Pod Q is running on another Node in the same Zone as Node N. *   Pod P has Zone-wide anti-affinity with Pod Q (`topologyKey: topology.kubernetes.io/zone`). *   There are no other cases of anti-affinity between Pod P and other Pods in the Zone. *   In order to schedule Pod P on Node N, Pod Q can be preempted, but scheduler does not perform cross-node preemption. So, Pod P will be deemed unschedulable on Node N. If Pod Q were removed from its Node, the Pod anti-affinity violation would be gone, and Pod P could possibly be scheduled on Node N. We may consider adding cross Node preemption in future versions if there is enough demand and if we find an algorithm with reasonable performance. ## Troubleshooting Pod priority and pre-emption can have unwanted side effects. Here are some examples of potential problems and ways to deal with them. ### Pods are preempted unnecessarily Preemption removes existing Pods from a cluster under resource pressure to make room for higher priority pending Pods. If you give high priorities to certain Pods by mistake, these unintentionally high priority Pods may cause preemption in your cluster. Pod priority is specified by setting the `priorityClassName` field in the Pod's specification. The integer value for priority is then resolved and populated to the `priority` field of `podSpec`. To address the problem, you can change the `priorityClassName` for those Pods to use lower priority classes, or leave that field empty. An empty `priorityClassName` is resolved to zero by default. When a Pod is preempted, there will be events recorded for the preempted Pod. Preemption should happen only when a cluster does not have enough resources for a Pod. In such cases, preemption happens only when the priority of the pending Pod (preemptor) is higher than the victim Pods. Preemption must not happen when there is no pending Pod, or when the pending Pods have equal or lower priority than the victims. If preemption happens in such scenarios, please file an issue. ### Pods are preempted, but the preemptor is not scheduled When pods are preempted, they receive their requested graceful termination period, which is by default 30 seconds. If the victim Pods do not terminate within this period, they are forcibly terminated. Once all the victims go away, the preemptor Pod can be scheduled. While the preemptor Pod is waiting for the victims to go away, a higher priority Pod may be created that fits on the same Node. In this case, the scheduler will schedule the higher priority Pod instead of the preemptor. This is expected behavior: the Pod with the higher priority should take the place of a Pod with a lower priority. ### Higher priority Pods are preempted before lower priority pods The scheduler tries to find nodes that can run a pending Pod. If no node is found, the scheduler tries to remove Pods with lower priority from an arbitrary node in order to make room for the pending pod. If a node with low priority Pods is not feasible to run the pending Pod, the scheduler may choose another node with higher priority Pods (compared to the Pods on the other node) for preemption. The victims must still have lower priority than the preemptor Pod. When there are multiple nodes available for preemption, the scheduler tries to choose the node with a set of Pods with lowest priority. However, if such Pods have PodDisruptionBudget that would be violated if they are preempted then the scheduler may choose another node with higher priority Pods. When multiple nodes exist for preemption and none of the above scenarios apply, the scheduler chooses a node with the lowest priority. ## Interactions between Pod priority and quality of service {#interactions-of-pod-priority-and-qos} Pod priority and {{< glossary_tooltip text="QoS class" term_id="qos-class" >}} are two orthogonal features with few interactions and no default restrictions on setting the priority of a Pod based on its QoS classes. The scheduler's preemption logic does not consider QoS when choosing preemption targets. Preemption considers Pod priority and attempts to choose a set of targets with the lowest priority. Higher-priority Pods are considered for preemption only if the removal of the lowest priority Pods is not sufficient to allow the scheduler to schedule the preemptor Pod, or if the lowest priority Pods are protected by `PodDisruptionBudget`. The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/). You can use the QoS class to estimate the order in which pods are most likely to get evicted. The kubelet ranks pods for eviction based on the following factors: 1. Whether the starved resource usage exceeds requests 1. Pod Priority 1. Amount of resource usage relative to requests See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods) for more details. kubelet out-of-resource eviction does not evict Pods when their usage does not exceed their requests. If a Pod with lower priority is not exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. ## {{% heading "whatsnext" %}} * Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) </del>

Suggestion from in /sig docs /assign cc
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
I think this makes sense. I'd like to keep the URL but change the display title to Scheduling, Preemption and Eviction.
sgtm


Question: You should see a "Running" my-scheduler pod, in addition to the default kube-scheduler pod in this list. <ins> ### Enable leader election </ins> To run multiple-scheduler with leader election enabled, you must do the following: First, update the following fields in your YAML file: * `--leader-elect=true` <del> * `--lock-object-namespace=lock-object-namespace` * `--lock-object-name=lock-object-name` </del> <ins> * `--lock-object-namespace=<lock-object-namespace>` * `--lock-object-name=<lock-object-name>` {{< note >}} The control plane creates the lock objects for you, but the namespace must already exist. You can use the `kube-system` namespace. {{< /note >}} </ins> <del> If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for endpoints resources, as in the following example: </del> <ins> If RBAC is enabled on your cluster, you must update the `system:kube-scheduler` cluster role. Add your scheduler name to the resourceNames of the rule applied for `endpoints` and `leases` resources, as in the following example: </ins> ``` kubectl edit clusterrole system:kube-scheduler ``` ```yaml <del> - apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-scheduler rules: - apiGroups: - "" resourceNames: - kube-scheduler - my-scheduler resources: - endpoints verbs: - delete - get - patch - update </del> <ins> apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "true" labels: kubernetes.io/bootstrapping: rbac-defaults name: system:kube-scheduler rules: - apiGroups: - coordination.k8s.io resources: - leases verbs: - create - apiGroups: - coordination.k8s.io resourceNames: - kube-scheduler - my-scheduler resources: - leases verbs: - get - update - apiGroups: - "" resourceNames: - kube-scheduler - my-scheduler resources: - endpoints verbs: - delete - get - patch - update </ins> ``` ## Specify schedulers for pods

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I followed the steps in tutorial. At the end of it the annotation-second-scheduler POD got into the pending state. Client Version: v1.17.0 Server Version: v1.17.0 Errors visible in my-scheduler POD: Proposed Solution: Remove lock-object-namespace and lock-object-name from There is no lock-object-namespace namespace, hence my-scheduler won't not work properly. In addition to that, add the following lines to clusterrole system:kube-scheduler: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
It looks to me as if ought to tell the reader to add a new namespace to hold lock objects. Does that sound right? /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
could you confirm if you were trying to set up leader election or not?


Question: Kubernetes documentation welcomes improvements from all contributors, new and experienced! --> <del> 本网站由 [Kubernetes SIG（特别兴趣小组） Docs](/zh/docs/contribute/#参与docs特别兴趣小组) 维护. </del> <ins> 本网站由 [Kubernetes SIG（特别兴趣小组） Docs](/zh/docs/contribute/#get-involved-with-SIG-Docs) 维护. </ins> Kubernetes 文档项目的贡献者:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Chinese page is different with English version page. Proposed Solution: Update Chinese page Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language zh /assign
thanks reviews and approvement from xichengliudui, tengqm and idealhack


Question: This page shows how to attach handlers to Container lifecycle events. Kubernetes supports the postStart and preStop events. Kubernetes sends the postStart event immediately after a Container is started, and it sends the preStop event immediately before the <del> Container is terminated. </del> <ins> Container is terminated. A Container may specify one handler per event. </ins>

begins by stating: I suggest appending the following sentence: This was not obvious to me. In other programming contexts, multiple handlers per event are allowed; for example, in client-side JavaScript, more than one click handler may be specified.
/kind feature /language en /priority backlog /triage accepted /good-first-issue That's a nice improvement.
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /kind feature /language en /priority backlog /triage accepted /good-first-issue 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
/assign


Question: other = "Đóng góp" [main_copyright_notice]  other = """The Linux Foundation ®. Đã đăng ký Bản quyền. The Linux Foundation đã đăng ký và sử dụng nhãn hiệu. Để biết danh sách các nhãn hiệu của The Linux Foundation, xem Trademark Usage page"""   other = """The Linux Foundation ®. Tất cả các quyền được bảo lưu. The Linux Foundation đã đăng ký thương hiệu và sử dụng thương hiệu. Để xem danh sách các thương hiệu của The Linux Foundation, vui lòng xem trang Sử dụng Thương hiệu của chúng tôi"""  [main_documentation_license]  other = """Các tác giả Kubernetes | Tài liệu được phân phối theo CC BY 4.0""" [main_edit_this_page] other = "Sửa trang này" [main_github_create_an_issue] other = "Tạo một Issue"   other = """Tác giả Kubernetes | Tài liệu phân phối dưới CC BY 4.0"""  [main_github_invite]  other = "Quan tâm đến việc hacking mã nguồn Kubernetes?"   other = "Có quan tâm đến việc đóng góp vào mã nguồn chính của Kubernetes?"  [main_github_view_on] other = "Xem trên GitHub" [main_kubernetes_features]  other = "Các tính năng của Kubernetes"   other = "Tính năng Kubernetes"  [main_kubeweekly_baseline]  other = "Muốn nhận những tin tức Kubernetes mới nhất? Đăng kí KubeWeekly."   other = "Muốn nhận tin tức Kubernetes mới nhất không? Đăng ký KubeWeekly."  [main_kubernetes_past_link]  other = "Xem các bản tin trước đây"   other = "Xem những bản tin trước đó"  [main_kubeweekly_signup]  other = "Đăng kí"   other = "Đăng ký"  [main_page_history]  other ="Lịch sử trang"   other ="Lịch sử Trang"  [main_page_last_modified_on]  other = "Trang được sửa lần cuồi vào"   other = "Trang được chỉnh sửa lần cuối vào"  [main_read_about] other = "Đọc về"

Đề nghị thay thế "lạc thú" bằng "lỗi thời" !
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
Please raise the issue in english putting the language code before the issue in [] example [vi] Issue title here It will be good practice to write the description and title of the issue in English only.
Thank you! BTW i'd commited about this change, waiting for review.
Fixed in


Question: log retrievals), and can accept and serve those resources in different representations for convenience or efficiency. <del> Kubernetes supports efficient change notifications on resources via *watches*. </del> <ins> Kubernetes supports efficient change notifications on resources via _watches_: {{< glossary_definition prepend="in the Kubernetes API, watch is" term_id="watch" length="short" >}} </ins> Kubernetes also provides consistent list operations so that API clients can effectively cache, track, and synchronize the state of resources.

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update the to include an explanation of “watch”. Why is this needed The watch verb (and actually watchcollection as well) is K8s-specific jargon. We should help readers understand it. Comments Extra credit for also using the new term in existing pages, using a . /kind feature /wg api-expression
/assign
/priority backlog /triage accepted
Hi PR: for this issue. PTAL
I'm happy for any reviewer (for English) to take a look there.


Question:
 ## `LoggingConfiguration`     {#LoggingConfiguration} **Appears in:** - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) LoggingConfiguration contains logging options Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information.

Field	Description

format [Required]
 string 	  Format Flag specifies the structure of log messages. default value of format is `text`

sanitization [Required]
 bool 	  [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)</td> </tr> </tbody> </table> </ins> ## `KubeletConfiguration`     {#kubelet-config-k8s-io-v1beta1-KubeletConfiguration}

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Visiting provides inaccurate default values for shutdownGracePeriod (30s rather than 0s) and shutdownGracePeriodCriticalPods (10s rather than 0s). Proposed Solution: Correct the documentation to match the actual default values. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
I would like to take up this ticket.


/language zh
/reopen This was incorrectly
Reopened this issue. <detailsIn response to : /reopen This was incorrectly 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
/assign


Question: Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. | Kubernetes version | Windows Server LTSC releases | Windows Server SAC releases | <del> | --- | --- | --- | --- | </del> <ins> | --- | --- | --- | </ins> | *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | | *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In there is a table broken with GitHub Markdown renderer. ! BTW, the table is not broken with Hugo Markdown renderer. ! Proposed Solution: Page to Update: No Page on to Update. Just a Markdown file on GitHub to update. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
We support viewing the rendered documentation via I don't think this issue is valid.
/priority awaiting-more-evidence /langauge en
Thank for your comment. I will describe a bit more about this issue I opened. [As-is] Yes, although the second row of the Markdown code has 4 columns and other rows have 3 columns, this table is rendered alright by Hugo Markdown renderer. This is a issue about improving consistency of the number of columns in the Markdown code, regardless of the type of Markdown renderer. [To-be]

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , the link is broken. Proposed Solution: In Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
already logged here: /close /sig cluster-lifecycle
Closing this issue. <detailsIn response to : already logged here: /sig cluster-lifecycle 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


Question: 特定のバージョンをダウンロードする場合、コマンドの`$(curl -LS https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 <del> たとえば、Linuxへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: </del> <ins> たとえば、Linuxへ{{< skew currentPatchVersion >}}のバージョンをダウンロードするには、次のコマンドを入力します: </ins> ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/linux/amd64/kubectl </ins> ``` 2. kubectlバイナリを実行可能にしてください。

Problem: Based on , I have created this issue/task to help update the [ja] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ja" /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/containers/container- 46: IPDNS /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- 146: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- 283: )Service /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- 220: {{< param "fullversion" }}: 223: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- 34: Linux{{< param "fullversion" }}: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: macOS{{< param "fullversion" }}: 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 181: {{< 181: "fullversion" }}){{< param "fullversion" }} 186: curl -LO {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- 107: Kubernetes{{< param "fullversion" }} 111: releases/latest/download/kube- kubectl apply -f - 150: .PrepareNode.

ps1 -KubernetesVersion {{% param "fullversion" %}} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- 35: # {{% param "fullversion" %}} 36: -Lo C:k {{% param "fullversion" %}} 70: -Lo C:k {{% param "fullversion" %}} 86: {{< param "fullversion" }}: 89: releases/latest/download/kube- kubectl apply -f - /sig docs /sig localization /language ja cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- /sig localization /language ja cc: 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
cc:
/triage accepted /area localization /priority backlog


Question: | `MemoryPressure` | `True` 表示节点存在内存压力，即节点内存可用量低，否则为 `False` | | `PIDPressure` | `True` 表示节点存在进程压力，即节点上进程过多；否则为 `False` | | `NetworkUnavailable` | `True` 表示节点网络配置不正确；否则为 `False` | <ins> {{< /table >}} </ins> <!-- If you use command-line tools to print details of a cordoned Node, the Condition includes

The Chinese version of the chapter introducing the concept of misses the explanation of the info field compared to the English version. Please check it.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
/language zh
this is fixed here


Question: * [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) <del> ## Clusters * [AppArmor](/docs/tutorials/clusters/apparmor/) * [seccomp](/docs/tutorials/clusters/seccomp/) </del> ## Services * [Using Source IP](/docs/tutorials/services/source-ip/)

This is a Feature Request What would you like to be Post-merge of , move the tutorials under into Merge clusters section into security section here: Why is this needed Issue description is a slight modification from original request in the comment Comments /hold for /cc /sig docs security
this might be a good first issue for new contributors in sig-security-docs /triage accepted
Hi, I would like to work on this issue. /assign
/kind cleanup
Hi , I a query: moving the tutorials from the cluster sub-directory into the security sub-directory, the cluster sub-directory will only have its file so do I need to do something regarding it ( file)? Thanks
Whenever you are free can you please help me with the above mentioned query. Thanks


Question: `cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. `completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh). `config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.  --> `apply`            | `kubectl apply -f FILENAME [flags]`| 从文件或 stdin 对资源应用配置更改。 `attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 挂接到正在运行的容器，查看输出流或与容器（stdin）交互。 `auth`    | `kubectl auth [flags] [options]` | 检查授权。 `autoscale`    | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动扩缩由副本控制器管理的一组 pod。 `certificate`    | `kubectl certificate SUBCOMMAND [options]` | 修改证书资源。 `cluster-info`    | `kubectl cluster-info [flags]` | 显示有关集群中主服务器和服务的端口信息。 `completion`    | `kubectl completion SHELL [options]` | 为指定的 Shell（Bash 或 Zsh）输出 Shell 补齐代码。 `config`        | `kubectl config SUBCOMMAND [flags]` | 修改 kubeconfig 文件。有关详细信息，请参阅各个子命令。

web
/retitle [zh-cn] Fix table formatting errors on the kubectl page
/triage accepted


Question: {{< /note >}} {{< note >}} <del> Pod anti-affinity requires nodes to be consistently labelled, in other words every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior. </del> <ins> Pod anti-affinity requires nodes to be consistently labelled, in other words, every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior. </ins> {{< /note >}} <del> As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution` which denote "hard" vs. "soft" requirements. See the description in the node affinity section earlier. An example of `requiredDuringSchedulingIgnoredDuringExecution` affinity would be "co-locate the pods of service A and service B in the same zone, since they communicate a lot with each other" and an example `preferredDuringSchedulingIgnoredDuringExecution` anti-affinity would be "spread the pods from this service across zones" (a hard requirement wouldn't make sense, since you probably have more pods than zones). </del> <ins> #### Types of inter-pod affinity and anti-affinity Similar to [node affinity](#node-affinity) are two types of Pod affinity and anti-affinity as follows: * `requiredDuringSchedulingIgnoredDuringExecution` * `preferredDuringSchedulingIgnoredDuringExecution` </ins> <del> Inter-pod affinity is specified as field `podAffinity` of field `affinity` in the PodSpec. And inter-pod anti-affinity is specified as field `podAntiAffinity` of field `affinity` in the PodSpec. </del> <ins> For example, you could use `requiredDuringSchedulingIgnoredDuringExecution` affinity to tell the scheduler to co-locate Pods of two services in the same cloud provider zone because they communicate with each other a lot. Similarly, you could use `preferredDuringSchedulingIgnoredDuringExecution` anti-affinity to spread Pods from a service across multiple cloud provider zones. </ins> <del> #### An example of a pod that uses pod affinity: </del> <ins> To use inter-pod affinity, use the `affinity.podAffinity` field in the Pod spec. For inter-pod anti-affinity, use the `affinity.podAntiAffinity` field in the Pod spec. #### Pod affinity example {#an-example-of-a-pod-that-uses-pod-affinity} Consider the following Pod spec: </ins> {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} <del> The affinity on this pod defines one pod affinity rule and one pod anti-affinity rule. In this example, the `podAffinity` is `requiredDuringSchedulingIgnoredDuringExecution` while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity rule says that the pod should not be scheduled onto a node if that node is in the same zone as a pod with label having key "security" and value "S2". See the [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution` flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor. </del> <ins> This example defines one Pod affinity rule and one Pod anti-affinity rule. The Pod affinity rule uses the "hard" `requiredDuringSchedulingIgnoredDuringExecution`, while the anti-affinity rule uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`. </ins> <del> The legal operators for pod affinity and anti-affinity are `In`, `NotIn`, `Exists`, `DoesNotExist`. </del> <ins> The affinity rule says that the scheduler can only schedule a Pod onto a node if the node is in the same zone as one or more existing Pods with the label `security=S1`. More precisely, the scheduler must place the Pod on a node that has the `topology.kubernetes.io/zone=V` label, as long as there is at least one node in that zone that currently has one or more Pods with the Pod label `security=S1`. The anti-affinity rule says that the scheduler should try to avoid scheduling the Pod onto a node that is in the same zone as one or more Pods with the label `security=S2`. More precisely, the scheduler should try to avoid placing the Pod on a node that has the `topology.kubernetes.io/zone=R` label if there are other nodes in the same zone currently running Pods with the `Security=S2` Pod label. See the [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) for many more examples of Pod affinity and anti-affinity. </ins> <del> In principle, the `topologyKey` can be any legal label-key. However, for performance and security reasons, there are some constraints on topologyKey: </del> <ins> You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the `operator` field for Pod affinity and anti-affinity. </ins> <del> 1. For pod affinity, empty `topologyKey` is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution`. 2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution`. 3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or disable it. 4. Except for the above cases, the `topologyKey` can be any legal label-key. </del> <ins> In principle, the `topologyKey` can be any allowed label key with the following exceptions for performance and security reasons: </ins> <del> In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces` of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`). If omitted or empty, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears. </del> <ins> * For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution` and `preferredDuringSchedulingIgnoredDuringExecution`. * For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules, the admission controller `LimitPodHardAntiAffinityTopology` limits `topologyKey` to `kubernetes.io/hostname`. You can modify or disable the admission controller if you want to allow custom topologies. </ins> <del> All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity must be satisfied for the pod to be scheduled onto a node. </del> <ins> In addition to `labelSelector` and `topologyKey`, you can optionally specify a list of namespaces which the `labelSelector` should match against using the `namespaces` field at the same level as `labelSelector` and `topologyKey`. If omitted or empty, `namespaces` defaults to the namespace of the Pod where the affinity/anti-affinity definition appears. </ins> #### Namespace selector {{< feature-state for_k8s_version="v1.22" state="beta" >}} <del> Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces. The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field. </del> <ins> You can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces. The affinity term is applied to namespaces selected by both `namespaceSelector` and the `namespaces` field. </ins> Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and <del> null `namespaceSelector` means "this pod's namespace". </del> <ins> null `namespaceSelector` matches the namespace of the Pod where the rule is defined. {{<note>}} </ins> This feature is beta and enabled by default. You can disable it via the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler. <ins> {{</note>}} </ins> <del> #### More Practical Use-cases </del> <ins> #### More practical use-cases </ins> <del> Interpod Affinity and AntiAffinity can be even more useful when they are used with higher level collections such as ReplicaSets, StatefulSets, Deployments, etc.  One can easily configure that a set of workloads should </del> <ins> Inter-pod affinity and anti-affinity can be even more useful when they are used with higher level collections such as ReplicaSets, StatefulSets, Deployments, etc.  These rules allow you to configure that a set of workloads should </ins> be co-located in the same defined topology, eg., the same node. <del> ##### Always co-located in the same node </del> <ins> Take, for example, a three-node cluster running a web application with an in-memory cache like redis. You could use inter-pod affinity and anti-affinity to co-locate the web servers with the cache as much as possible. </ins> <del> In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible. Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`. The deployment has `PodAntiAffinity` configured to ensure the scheduler does not co-locate replicas on a single node. </del> <ins> In the following example Deployment for the redis cache, the replicas get the label `app=store`. The `podAntiAffinity` rule tells the scheduler to avoid placing multiple replicas with the `app=store` label on a single node. This creates each cache in a separate node. </ins> ```yaml apiVersion: apps/v1

Page: This page could use a review and update for consistency, clarity, and style. Some sections read like tasks instead of conceptual information, and there's a few areas where the headings and readability are not in line with our style guidelines. /assign /sig docs /triage accepted /language en /kind cleanup
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The description provide in the following section is somewhat missing out the details. It is not justifying the value of weight one should configure in the affinity section of a deployment. Proposed Solution: It would be best if this page can contain a legitimate example around the weight in Node affinity. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--v1.18 <!--Additional Information:--What is the significance of weight: 1 as compared to weight: 100 ? Creating first issue in GIT, apologies if I have missed out something. Would be happy to hear from you.
/language en /sig scheduling
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle rotten
/remove-lifecycle rotten
/priority backlog
From what I understand, the scheduler iterates through each field for each matched affinity term and computes a sum, then places pods in nodes that meet the scheduling requirements by order of highest weight sum. Is this correct?
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
fixes this.
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .


Question: response to a successful request is a hello message: ```none <del> Hello Kubernetes! </del> <ins> Hello, world! Version: 2.0.0 Hostname: hello-world-cdd4458f4-m47c8 </ins> ``` ## Using a service configuration file

After running the kubectl apply command at , "kubectl get all" shows it is having "ImagePullBackOff" error When I do a describe it says the image is too old and need to be updated According to this link , the image was created back in 2016. Can we either update all the sample images to use manifest version 2 or find another image that works out of the box?
Related issue:
We shoudl fix this i think. sftim Any idea how we could resolve to help with tutorial working again?
Sample yaml reported in the issue: /language en
It seems that the image may have been removed by Google. We can either update the sample with image's new location (will need some searching), similar to what we’ve done for other tutorials (example ), or find a suitable alternative image to use.
I'd love to help out if appropriate, it appears to be a good first issue but I am not sure.
Would be good to fix this issue with the tutorial. /priority backlog /triage accepted
/kind bug


Question: Used on: Node <del> Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on the clusters it creates. With this feature gate enabled on a cluster, you can add labels to particular worker nodes to exclude them from the list of backend servers. </del> <ins> You can add labels to particular worker nodes to exclude them from the list of backend servers used by external load balancers. </ins> The following command can be used to exclude a worker node from the list of backend servers in a backend set:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: mentions a feature gate; however, Kubernetes v1.23 onwards don't have such a feature gate. This is in connection with a label, . Proposed Solution: Drop the mention of the feature gate. Reword the description of that label accordingly. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /kind bug /priority backlog
/triage accepted
I would to like to work on this issue. /assign
/sig docs
The issue is fixed .


Question: ``` <!-- <del> Use `CTRL-C` to terminate to kubectl. </del> <ins> Use `CTRL-C` to terminate kubectl. </ins> You cannot drain the third node because evicting `zk-2` would violate `zk-budget`. However, the node will remain cordoned.

Numbers in the following list may be not up to date. Please run again before working on each of them.
/language zh /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /language zh /triage accepted /help 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
/assign


Question: version: "v1.9" githubbranch: "v1.9.0" docsbranch: "release-1.9" <del> url: https://kubernetes.io/docs/home/ </del> <ins> url: https://kubernetes.io </ins> - fullversion: "v1.8.4" version: "v1.8" githubbranch: "v1.8.4" docsbranch: "release-1.8" <del> url: https://v1-8.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-8.docs.kubernetes.io </ins> - fullversion: "v1.7.6" version: "v1.7" githubbranch: "v1.7.6" docsbranch: "release-1.7" <del> url: https://v1-7.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-7.docs.kubernetes.io </ins> - fullversion: "v1.6.8" version: "v1.6" githubbranch: "v1.6.8" docsbranch: "release-1.6" <del> url: https://v1-6.docs.kubernetes.io/docs/home/ </del> <ins> url: https://v1-6.docs.kubernetes.io </ins> - fullversion: "v1.5.7" version: "v1.5" githubbranch: "v1.5.7" docsbranch: "release-1.5" <del> url: https://v1-5.docs.kubernetes.io/docs/ </del> <ins> url: https://v1-5.docs.kubernetes.io </ins> deprecated: false currentUrl: https://kubernetes.io/docs/home/ nextUrl: http://kubernetes-io-vnext-staging.netlify.com/

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: When switching to a different version of the docs, I get redirected to the root of the doc tree. Proposed Solution: Would be nice to redirect users to an equivalent page in the previous version of docs. Easy way to get started would be to just support pages that haven't moved or been refactored. Could get fancier after that.
Also related (found while I was reproducing this), the drop-down mechanism that allows version changing doesn't render correctly on safari (mobile or laptop) so that you can't choose the older versions, and the same happens in Chrome (IOS) - you see part of 1.8, but the rest of the list is cut off. See embedded screenshot (from Chrome IOS) !
I've attempted to implement a solution to this in . This part works by default This part requires setting data on the page as to where to send the person.
This issue is still present on the current version of the website.
not sure if we should reopen this issue or file a new one as a bug report but this no longer works. from what I can tell during the migration to hugo the header file was removed


Question:
扩缩 是通过改变 Deployment 中的副本数量来实现的。

  注意  如果你是在 上一节 之后尝试此操作, 你可能需要从 创建一个集群 开始， 因为 Service 可能已被删除。
   {{< note >}}
如果你是在 上一节 之后尝试此操作, 那么你可能已经删除了公开 Deployment 的 Service。在这种情况下，请使用以下命令再次公开 Deployment：

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
 {{< /note >}}

Chinese document display in raw html format. <img width="868" alt="image" src=""
/language zh
/kind bug
Related page: /retitle [zh] Displays Raw Html data in tutorials page
/sig docs /triage accepted /priority backlog
As per original site, this part should look something like this - !
/assign


Question: ## Labels, annotations and taints used on API objects <ins> ### apf.kubernetes.io/autoupdate-spec Type: Annotation Example: `apf.kubernetes.io/autoupdate-spec: "true"` Used on: [`FlowSchema` and `PriorityLevelConfiguration` Objects](/concepts/cluster-administration/flow-control/#defaults) If this annotation is set to true on a FlowSchema or PriorityLevelConfiguration, the `spec` for that object is managed by the kube-apiserver. If the API server does not recognize an APF object, and you annotate it for automatic update, the API server deletes the entire object. Otherwise, the API server does not manage the object spec. For more details, read  [Maintenance of the Mandatory and Suggested Configuration Objects](/docs/concepts/cluster-administration/flow-control/#maintenance-of-the-mandatory-and-suggested-configuration-objects). </ins> ### app.kubernetes.io/component Type: Label

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: According to , Kubernetes uses an annotation: . However, this annotation isn't registered (registration means adding it into ) Proposed Solution: Register and document the annotation. I am not sure which version of Kubernetes / will add the support for this annotation. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig api-machinery /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions 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
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
Anyone is welcome to work on this. See for information about contributing to Kubernetes, including to the documentation.
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
hey can i work on this issue
Anyone is (still) welcome to work on this. See for information about contributing to Kubernetes, including to the documentation.
can you assign me this issue i would like to work on this issue
you are welcome to work on this issue; we have a no cookie licking policy in SIG Docs. Anyone is welcome to work on an issue. If someone has already said that they plan to work on it, it's polite to liaise with them first. However, a second contributor can join the effort: either by opening their own PR, by reviewing the first contributor's work, or by some other means such as pairing.

We rarely assign issues to contributors because of the policy on .
I'll add one thing. If people - including you - would like to document a missing annotation, take a look at Working top down (ie, oldest first) is even more helpful.
/assign


Question: The output is similar to the following. The column `CONTAINER-RUNTIME` outputs the runtime and its version. <ins> For Docker Engine, the output is similar to this: </ins> ```none <del> # For dockershim </del> NAME         STATUS   VERSION    CONTAINER-RUNTIME node-1       Ready    v1.16.15   docker://19.3.1 node-2       Ready    v1.16.15   docker://19.3.1 node-3       Ready    v1.16.15   docker://19.3.1 ``` <ins> If your runtime shows as Docker Engine, you still might not be affected by the removal of dockershim in Kubernetes 1.24. [Check the runtime endpoint](#which-endpoint) to see if you use dockershim. If you don't use dockershim, you aren't affected. For containerd, the output is similar to this: </ins> ```none <del> # For containerd </del> NAME         STATUS   VERSION   CONTAINER-RUNTIME node-1       Ready    v1.19.6   containerd://1.4.1 node-2       Ready    v1.19.6   containerd://1.4.1

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to explain how to tell apart two cases that involve Docker Engine as a container runtime Docker Engine + dockershim + kubelet Docker Engine + cri-dockerd + kubelet The second case, using 2 third-party components, is not affected by the dockership deprecation. As a project we are not telling cri-dockerd users to migrate away. Why is this needed If someone is using cri-dockerd with Docker Engine, they don't need to take action relating to the deprecation of dockershim. That person might visit and then be confused about whether they still need to take action. Comments /sig node /priority important-soon /language en /kind feature Part of
Very relevant to
It really should say , rather than It doesn't say "for cri-containerd" or "for containerd with cri plugin", either. Adding an example could be done too, but not relevant here. It is covered on
Neither nor seem to have a way to tell the CRI in use ? They only describe the container runtime, and in some cases the API version... Needed to look at directly. The output of didn't help.
Looks like crictl is only documented under "debugging", even if required ? That is, is now required even for Docker (it wasn't, for dockershim)
/triage accepted
I think it would be more interesting to look at users using the "docker" container runtime, to see if they have changed CRI... They would need to change their CRI, from to cri- Including kubelet and crictl configuration ? But they don't need to relearn everything or transfer images, etc.
This should say "docker" (which the command does), and not (not really relevant) They main reason is in the confusion between container runtimes, and the CRI being used for them ? "This section presents information you need to know when migrating from dockershim to other container runtimes." Which of course doesn't make any sense to begin with, since dockershim is not a container runtime.

So it should be divided into two: 1) how to change dockershim to cri-dockerd 2) how to change docker to containerd Of course, if you are already set on replacing the container runtime, then you don't need to bother with the first one.
That seems fair enough. We can also add instructions for switching your node from Docker Engine to something else, if we want.
where feasible we prefer to link to external docs that are specific to external tools, rather than document them ourselves. This case seems like a reasonable case for doing the documenting ourselves.
Unfortunately it also assumes that there are any good external docs, which doesn't seem to be the case for either CRI ? It is a big problem for minikube, the only container runtime which is easy to install (i.e. ) is no longer supported. So we end up having to pre-install all three of them, rather than doing some simple provisioning before the bootstrapping. "Patches accepted", I suppose...
Visual summary: ! The top diagram would be when running Kubernetes 1.23, and the bottom diagram would be when running Kubernetes 1.24 The docker installation () stays the same, the only introduction is the new cri-dockerd ()
From what I understand, needs to add info about how cri-dockerd users aren't affected, and how to check the CRI socket to tell if you do use cri-dockerd. (how? if crictl is not installed, is there another way?) Also, needs more guidance for migrating from dockershim to cri-dockerd (in addition to migrating from Docker Engine to containerd). Is this out of scope for this issue? /assign
I'd say yes: it is out of scope for this issue. It's fine to track a separate issue to add docs for that.
I believe that is mandatory, without dockershim But I assume you would look at kubelet configuration If it doesn't have any configuration, it is using dockershim. And thus it would be affected by this change. So far, we don't know what the minimum requirements on Kubernetes version and Docker version is, for it. But we can assume that anything after 1.20 and 19.03 should be fine, for changing to cri-dockerd 0.2.x.

The recommendation would probably be to go with 1.24 and 20.10, and assuming a real release of 0.2.1 ? This is now up to Mirantis to describe, for cri-dockerd. Kubernetes version | Validated version --- | ---- 12 | 17.03 13 | 18.06 14 | 18.09 18 | 19.03 20 | ???
There is a . If you talk CRI to some unidentified CRI socket and the thing at the other end identifies itself as Docker Engine, odds on you're talking to or . You can narrow it down by running . That's likely to give you either the PID and name of the daemon involved, or possibly point to a socket-activation tool such as systemd. If it is systemd owning the socket, you'd grep through systemd config to find what's configured to listen on that socket.
Is this essentially an umbrella issue for and now?
It's all done!


Question: <ins> --- title: "Introduction To Kubectl" content_type: concept weight: 1 --- Kubectl is the Kubernetes cli version of a swiss army knife, and can do many things. While this Book is focused on using Kubectl to declaratively manage Applications in Kubernetes, it also covers other Kubectl functions. ## Command Families Most Kubectl commands typically fall into one of a few categories: | Type                                   | Used For                   | Description                                        | |----------------------------------------|----------------------------|----------------------------------------------------| | Declarative Resource Management        | Deployment and Operations (e.g. GitOps)   | Declaratively manage Kubernetes Workloads using Resource Config     | | Imperative Resource Management         | Development Only           | Run commands to manage Kubernetes Workloads using Command Line arguments and flags | | Printing Workload State | Debugging  | Print information about Workloads | | Interacting with Containers | Debugging  | Exec, Attach, Cp, Logs | | Cluster Management | Cluster Ops | Drain and Cordon Nodes | ## Declarative Application Management The preferred approach for managing Resources is through declarative files called Resource Config used with the Kubectl *Apply* command. This command reads a local (or remote) file structure and modifies cluster state to reflect the declared intent. {{< alert color="success" title="Apply" >}} Apply is the preferred mechanism for managing Resources in a Kubernetes cluster. {{< /alert >}} ## Printing state about Workloads Users will need to view Workload state. - Printing summarize state and information about Resources - Printing complete state and information about Resources - Printing specific fields from Resources - Query Resources matching labels ## Debugging Workloads Kubectl supports debugging by providing commands for: - Printing Container logs - Printing cluster events - Exec or attaching to a Container - Copying files from Containers in the cluster to a user's filesystem ## Cluster Management On occasion, users may need to perform operations to the Nodes of cluster.  Kubectl supports commands to drain Workloads from a Node so that it can be decommission or debugged. ## Porcelain Users may find using Resource Config overly verbose for *Development* and prefer to work with the cluster *imperatively* with a shell-like workflow.  Kubectl offers porcelain commands for generating and modifying Resources. - Generating + creating Resources such as Deployments, StatefulSets, Services, ConfigMaps, etc - Setting fields on Resources - Editing (live) Resources in a text editor {{< alert color="warning" title="Porcelain For Dev Only" >}} Porcelain commands are time saving for experimenting with workloads in a dev cluster, but shouldn't be used for production. {{< /alert >}} </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Move the page from the to the Why is this needed Multiple versions of the kubectl documentation exists which can be merged into the kubectl reference section in the Kubernetes upstream website. Part of Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/good-first-issue /language-en /help-wanted
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --<!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --<!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language-en /help-wanted 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
/triage accepted
The source code to move is inside
/assign
/sig docs
Hey and I created a PR for this issue. Please take a look.
would you be willing to file some similar issues? I would mark them with /help but not with /good-first-issue
Yes, I'll create the rest of the issues today.