jiebi/CodeConvo huggingface dataset:
Code change:
**only do this in a test cluster**. ```shell <del> kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets </del> <ins> kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets </ins> ``` Now you can watch as the Pod reschedules on a different Node:

Related discussion:
text: 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: Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. Proposed Solution: Update to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/sig cluster-lifecycle
cc
i see the discussion / PR here: using in the kubeadm docs makes sense. /triage accepted /help
This request has been marked as needing help from a contributor. 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 : Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. /help </details
/assign
Code change:
</h4> {{ end }} <p>{{ .message | markdownify }}</p> <ins> {{- if eq .dismissParameters.dismissible true -}} <button  id="banner-dismiss" class="button" style="display: none;" data-ttl={{ .dismiss_params.showDismissedAnnouncementAfterDays }}>{{ T "banner_acknowledgement" }}</button> <!-- Only JS enabled users will see this button --> {{- end -}} </ins> </div> </aside> </div>

Related discussion:
text: This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
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
/retitle Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!
Code change:
</h4> {{ end }} <p>{{ .message | markdownify }}</p> <ins> {{- if eq .dismissParameters.dismissible true -}} <button  id="banner-dismiss" class="button" style="display: none;" data-ttl={{ .dismiss_params.showDismissedAnnouncementAfterDays }}>{{ T "banner_acknowledgement" }}</button> <!-- Only JS enabled users will see this button --> {{- end -}} </ins> </div> </aside> </div>

Related discussion:
text: The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs
Code change:
<ins> --- title: Secret id: secret date: 2018-04-12 full_link: /ja/docs/concepts/configuration/secret/ short_description: > パスワードやOAuthトークン、SSHキーのような機密の情報を保持します。 aka: tags: - core-object - security --- パスワードやOAuthトークン、SSHキーのような機密の情報を保持します。 <!--more--> 機密情報の取り扱い方法を細かく制御することができ、保存時には[暗号化](/ja/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted)するなど、誤って公開してしまうリスクを減らすことができます。{{< glossary_tooltip text="Pod" term_id="pod" >}}は、ボリュームマウントされたファイルとして、またはPodのイメージをPullするkubeletによって、Secretを参照します。Secretは機密情報を扱うのに最適で、機密でない情報には[ConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)が適しています。 </ins>

Related discussion:
text: This is a Feature Request What would you like to be Translate docs/reference/glossary/secret into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
Code change:
title: Extending the Kubernetes API weight: 30 --- <ins> Custom resources are extensions of the Kubernetes API. Kubernetes provides two ways to add custom resources to your cluster: - The [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD) mechanism allows you to declaratively define a new custom API with an API group, kind, and schema that you specify. The Kubernetes control plane serves and handles the storage of your custom resource. CRDs allow you to create new types of resources for your cluster without writing and running a custom API server. - The [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) sits behind the primary API server, which acts as a proxy. This arrangement is called API Aggregation (AA), which allows you to provide specialized implementations for your custom resources by writing and deploying your own API server. The main API server delegates requests to your API server for the custom APIs that you specify, making them available to all of its clients. </ins>

Related discussion:
text: This is a Feature Request What would you like to be Add a comparison between the CRDs and API aggregation layer. should explain this - but doesn't! Why is this needed It's needed so users can understand the difference between CRDs and API aggregation layers.
/sig docs /sig api-machinery
/trick-or-treat
! <detailsIn response to : /trick-or-treat 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
We can take some reference from this to understand the difference between and .
/triage accepted /wg api-expression
This issue looks interesting. I would like to raise a PR for more explanation. /assign
Code change:
<del> „--- </del> <ins> --- </ins> title: I componenti di Kubernetes content_type: concept weight: 20

Related discussion:
text: 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: isn't rendering correctly. Proposed Solution: Fix the Markdown for this page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language it /kind bug /priority important-longterm
Code change:
Initコンテナの順序と実行を考えるとき、リソースの使用に関して下記のルールが適用されます。 <del> * 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なinitリクエスト／リミット* になります。 </del> <ins> * 全てのInitコンテナの中で定義された最も高いリソースリクエストとリソースリミットが、*有効なinitリクエスト／リミット* になります。いずれかのリソースでリミットが設定されていない場合、これが最上級のリミットとみなされます。 </ins> * Podのリソースの*有効なリクエスト／リミット* は、下記の2つの中のどちらか高い方となります。 * リソースに対する全てのアプリケーションコンテナのリクエスト／リミットの合計 * リソースに対する有効なinitリクエスト／リミット

Related discussion:
text: 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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /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
Code change:
object named `default` for every namespace in your cluster. The `default` service accounts in each namespace get no permissions by default other than the [default API discovery permissions](/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) <del> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{<glossary_tooltip text="control plane" term_id="control-plane">}} </del> <ins> that Kubernetes grants to all authenticated principals if role-based access control (RBAC) is enabled. If you delete the `default` ServiceAccount object in a namespace, the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} </ins> replaces it with a new one. If you deploy a Pod in a namespace, and you don't

Related discussion:
text: No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.
Code change:
</td> </tr> <tr><td><code>userInfo</code> <B>[Required]</B><br/> <del> <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#userinfo-v1-authentication"><code>authentication/v1.UserInfo</code></a> </del> <ins> <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#userinfo-v1-authentication-k8s-io"><code>authentication/v1.UserInfo</code></a> </ins> </td> <td> <p>UserInfo is information about the requesting user</p>

Related discussion:
text: Several of the types used in AdmissionRequest does not seem to be documented anywhere. The links point to the general Kubernetes API docs, but the actual types does not seem to be defined there. Searching in the docs does not turn up any obvious references, and neither does web searches. Types missing documentation:
/sig docs /language en
Yes, no documentation for and But for , it should be . The doc is here:
/triage accepted /assign
Code change:
| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | | | `ProcMountType` | `false` | Alpha | 1.12 | | | `QOSReserved` | `false` | Alpha | 1.11 | | <del> | `RemainingItemCount` | `false` | Alpha | 1.15 | | </del> <ins> | `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 | | `RemainingItemCount` | `true` | Beta | 1.16 | | </ins> | `RemoveSelfLink` | `false` | Alpha | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | Beta | 1.20 | | | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 |

Related discussion:
text: lists RemainingItemCount as alpha but shows it went beta. /kind bug /language en /sig api-machinery
/triage accepted
What was the version when it was promoted to beta? (The PR seems quite old). Was it if I am not wrong? /assign
Code change:
<ins> --- title: Conceitos main_menu: true content_type: concept weight: 40 --- <!-- overview --> A seção de Conceitos irá te ajudar a aprender mais sobre as partes do ecossistema Kubernetes e as abstrações que o Kubernetes usa para representar seu {{< glossary_tooltip text="cluster" term_id="cluster" length="all" >}}. Ela irá lhe ajudar a obter um entendimento mais profundo sobre como o Kubernetes funciona. <!-- body --> </ins>

Related discussion:
text: 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: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
Code change:
{{- if or (eq .endTime nil ) (gt ( time .endTime ) now ) -}} {{- if not $announcementShown -}} {{- $announcementShown = true -}} <del> <div lang="en" id="announcement" style="background-color: #3371e3; color: #fff; {{ .style | safeCSS }}"> </del> <ins> <div lang="en" id="announcement" data-announcement-name="{{ .name }}" style="background-color: #3371e3; color: #fff; {{ .style | safeCSS }}"> </ins> <aside> <div class="announcement-main" data-nosnippet> {{ if .title }}

Related discussion:
text: This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
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
/retitle Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!
Code change:
{{- if or (eq .endTime nil ) (gt ( time .endTime ) now ) -}} {{- if not $announcementShown -}} {{- $announcementShown = true -}} <del> <div lang="en" id="announcement" style="background-color: #3371e3; color: #fff; {{ .style | safeCSS }}"> </del> <ins> <div lang="en" id="announcement" data-announcement-name="{{ .name }}" style="background-color: #3371e3; color: #fff; {{ .style | safeCSS }}"> </ins> <aside> <div class="announcement-main" data-nosnippet> {{ if .title }}

Related discussion:
text: The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs
Code change:
with static, long-lived credentials. In Kubernetes v1.24 and later, the [LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) prevents Kubernetes from automatically creating these tokens for <del> ServiceAccounts. </del> <ins> ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled by default; in other words, Kubernetes does not create these tokens. </ins> ## Authenticating service account credentials {#authenticating-credentials}

Related discussion:
text: No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
&hellip;until now:
I reckon will close this issue.
Code change:
* 使用证书配置的 Nginx 服务器 * 使证书可以访问 Pod 的 [Secret](/zh/docs/concepts/configuration/secret/) <del> 你可以从 [Nginx https 示例](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/staging/https-nginx/) </del> <ins> 你可以从 [Nginx https 示例](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/) </ins> 获取所有上述内容。你需要安装 go 和 make 工具。如果你不想安装这些软件，可以按照 后文所述的手动执行步骤执行操作。简要过程如下：

Related discussion:
text: The specific location of the document is The documentation says You can acquire all these from the nginx https example. This requires having go and make tools installed. The link of the Chinese document is: he cannot access the link of the English document is: accessible
/triage accepted /language zh /kind bug
/assign
Code change:
[cAdvisor](https://github.com/google/cadvisor) that runs within the kubelet. If you enable the `PodAndContainerStatsFromCRI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) in your cluster, and you use a container runtime that supports statistics access via <del> {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI), then </del> <ins> {{< glossary_tooltip term_id="container-runtime-interface" text="Container Runtime Interface">}} (CRI), then </ins> the kubelet [fetches Pod- and container-level metric data using CRI](/docs/reference/instrumentation/cri-pod-container-metrics), and not via cAdvisor. ## {{% heading "whatsnext" %}}

Related discussion:
text: This is a Bug Report The glossary tooltip for is referencing section, instead it should reference to page.
/sig docs /language en
/assign
fixed
/retitle Incorrect glossary tooltip link for 'Container runtime interface' /priority backlog /triage accepted
Code change:
* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) <del> * Kube-proxy running in mode IPVS </del> * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster {{< version-check >}}

Related discussion:
text: This is a Bug Report <!--Required Information--Problem: In Dualstack doc updates for 1.18 , it only removes IPVS prerequisites in but not remove it in , you still can find "Kube-proxy running in mode IPVS" in the doc. Proposed Solution: remove "Kube-proxy running in mode IPVS" in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /priority important-soon /kind bug – Can you verify the issue described is correct? If so we can tag it as a good first issue and have someone tackle it.
Hi and Thank you very much for raising this. I can indeed validate that the issue is correct and that the proposed solution is correct and would be more than happy to review a PR if someone would be happy to contribute. Thanks again
/assign
– no further action from you needed, this was a small fix. Thank you!