jiebi/CodeConvo huggingface dataset:
Change:
### Access to key and certificate <del> As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes. </del> <ins> As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes. </ins> These will be used by the controller-manager to sign the kubelet certificates. Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA

Discussion:
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: uses the outdated term “master” and “master node”. Proposed Solution: Replace references to the control plane that use the term “master” with the current term: “control plane”. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /kind cleanup /wg naming
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 “Kubelet TLS Bootstrapping” uses outdated wording
I would like to take up this issue
/assign
Change:
<li data-type="gauge"><label class="metric_detail">Type:</label> <span class="metric_type">Gauge</span></li> </ul> </div><div class="metric" data-stability="alpha"> <ins> <div class="metric_name">kube_apiserver_nodeport_allocator_allocation_errors_total</div> <div class="metric_help">Number of errors trying to allocate NodePort</div> <ul> <li><label class="metric_detail">Stability Level:</label><span class="metric_stability_level">ALPHA</span></li> <li data-type="counter"><label class="metric_detail">Type:</label> <span class="metric_type">Counter</span></li> <li class="metric_labels_varying"><label class="metric_detail">Labels:</label><span class="metric_label">scope</span></li></ul> </div><div class="metric" data-stability="alpha"> <div class="metric_name">kube_apiserver_nodeport_allocator_allocation_total</div> <div class="metric_help">Number of NodePort allocations</div> <ul> <li><label class="metric_detail">Stability Level:</label><span class="metric_stability_level">ALPHA</span></li> <li data-type="counter"><label class="metric_detail">Type:</label> <span class="metric_type">Counter</span></li> <li class="metric_labels_varying"><label class="metric_detail">Labels:</label><span class="metric_label">scope</span></li></ul> </div><div class="metric" data-stability="alpha"> </ins> <div class="metric_name">kube_apiserver_nodeport_allocator_available_ports</div> <div class="metric_help">Gauge measuring the number of available NodePorts for Services</div> <ul>

Discussion:
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: removed metric from the documented metrics for Kubernetes v1.30, but the metric is still collected for the API server (ref: and ). Proposed Solution: Reinstate the documentation for such metric. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.30 <!--Additional Information:--
/sig instrumentation
/triage accepted
This metrics exists in the file generated by . Or there is a problem with the file generated by before. Let me generate the metrics file again and see. /assign
After I re-ran the script, some metrics were indeed missing (not just metrics ), it was a problem with the generated script, I will take a closer look.
Change:
title: Secret and configuration management description: > Deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration. <del> weight: 50 </del> <ins> weight: 30 </ins> --- {{% capture overview %}}

Discussion:
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 write a new concept page: (or possibly ) If the does not work as the page overview, consider tweaking the glossary entry so that it does. Then use a Hugo shortcode. Why is this needed ConfigMap is a core object type for Kubernetes; as such, it needs documenting properly. Comments Consider using as an example for page structure. It's better to put Task-style documentation in task pages such as and then hyperlink to those from the Concept page. Also see: /docs/user-guide/configmap need more details on ConfigMap updates Actionable user-guide/configmap does not document self-updating It's unclear what happens when ConfigMap is changed Need doc on using ConfigMap updates Wanted: ConfigMap Rollout Options Doc
/language en /sig apps
/priority important-longterm
This is worth prioritizing /priority important-soon
/remove-priority important-longterm
/project Doc Sprints
/assign
/unassign
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
Still worth documenting /remove-lifecycle stale
/reopen let's collaborate on this!
Change:
{{ end }} </tbody> </table> <ins> {{- end -}} </ins>

Discussion:
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 Migrate to instead of Hugo's Why is this needed Upstream Hugo has deprecated , which we use. We should aim to migrate to use ; see Comments We may need to upgrade to a newer Hugo as part of this work, or related to it. /area web-development /lifecycle frozen
/triage accepted /priority backlog
Let me see if I can assist with this. Edit: Proposed fix in /assign
Change:
See [Participating in SIG Docs](/docs/contribute/participate/) for more details about roles and permissions. --> <del> ## 入门 </del> <ins> ## 入门 {#getting-started} </ins> 任何人都可以提出文档方面的问题（issue），或贡献一个变更，用拉取请求（PR）的方式提交到 [GitHub 上的 `kubernetes/website` 仓库](https://github.com/kubernetes/website)。

Discussion:
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
Change:
### Cloud native security {#further-reading-cloud-native} <del> * CNCF [white paper](https://github.com/cncf/tag-security/tree/main/security-whitepaper) </del> <ins> * CNCF [white paper](https://github.com/cncf/tag-security/blob/main/community/resources/security-whitepaper/v2/CNCF_cloud-native-security-whitepaper-May2022-v2.pdf) </ins> on cloud native security. * CNCF [white paper](https://github.com/cncf/tag-security/blob/f80844baaea22a358f5b20dca52cd6f72a32b066/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf) on good practices for securing a software supply chain.

Discussion:
The CNCF on cloud native security defines security controls and practices that are appropriate to different lifecycle phases 404 link
/language en
/assign
/retitle Broken link to CNCF white paper in "Cloud Native Security" page /kind bug Page reported in issue (based on initial title):
/priority backlog /triage accepted
Change:
--days=10000  build-server-full server nopass <del> <!-- 1.  Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. 1.  Fill in and add the following parameters into the API server start parameters: --> 1.  拷贝文件 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 到你的目录中。 1.  在 API 服务器的启动参数中添加以下参数： </del> <ins> <!-- 4.  Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. --> 4.  拷贝文件 `pki/ca.crt`、`pki/issued/server.crt` 和 `pki/private/server.key` 到你的目录中。 <!-- 5.  Fill in and add the following parameters into the API server start parameters: --> 5.  在 API 服务器的启动参数中添加以下参数： </ins> --client-ca-file=/yourdirectory/ca.crt --tls-cert-file=/yourdirectory/server.crt

Discussion:
Link to The secondary list elements in the page are all "1." , they are not in order, it looks weird
/sig docs
Hi can you please elaborate which page are you talking about?
Sorry, I forgot to check the link in my issue, the correct link is
/language zh /triage accepted /retitle [zh] Wrong list numbering in page FYI: Page to update: page: file:
/assign
/assign
This fixes this issue.
please avoid assigning yourself to a issue that is already assigned to somebody else.
Change:
<ins> --- # Removed from Kubernetes title: ReadOnlyAPIDataVolumes content_type: feature_gate _build: list: never render: false stages: - stage: beta defaultValue: true fromVersion: "1.8" toVersion: "1.9" - stage: stable fromVersion: "1.10" toVersion: "1.10" removed: true --- Set [`configMap`](/docs/concepts/storage/volumes/#configmap), [`secret`](/docs/concepts/storage/volumes/#secret), [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi) and [`projected`](/docs/concepts/storage/volumes/#projected) {{< glossary_tooltip term_id="volume" text="volumes" >}} to be mounted read-only. Since Kubernetes v1.10, these volume types are always read-only and you cannot opt out. </ins>

Discussion:
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: It seems that Kubernetes previously had a feature gate named ; however, does not mention that feature gate. Proposed Solution: Update to mention . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
A web page that mentions the former feature gate:
/assign
/triage accepted /language en
/sig storage
According to CHANGELOG:
Hi so from this reference we don't need to add feature gate? and if so can we close this issue ?
We do need to update that page. Because the feature gate is no longer in active use, we'd add it to
This is a low-priority issue!
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]:
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]:
/remove-lifecycle rotten
/priority important-longterm
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on /unassign
/assign
How's this work going?
i would like to work on it. /assign
Thanks
Change:
Example: <del> If `kube-proxy` version is **{{< skew latestVersion >}}**: </del> <ins> If `kube-proxy` version is **{{< skew oldestMinorVersion >}}**: </ins> <del> * `kubelet` version must be at the same minor version as **{{< skew latestVersion >}}**. </del> <ins> * `kubelet` version must be at the same minor version as **{{< skew oldestMinorVersion >}}**. </ins> * `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.

Discussion:
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 example used to verify the relationship between the version of kube-proxy and kube-apiserver is problematic Proposed Solution: The version of kube-proxy must be less than or euqual to the version of kube-apiserver, so if the version of kube-proxy is 1.18, the version of kube-apiserver can be 1.18, 1.19 and 1.20. The setence should be "kube-apiserver version must be between 1.18 and 1.20, inclusive". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/kind bug /language en
thanks for finding this problem. PRs welcome! /help /good-first-issue /sig docs architecture /priority important-longterm
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 : thanks for finding this problem. PRs welcome! /good-first-issue /sig docs architecture /priority important-longterm </details
/assign
Change:
You should enable this admission controller if you intend to make any use of Kubernetes `ServiceAccount` objects. <ins> Regarding the annotation `kubernetes.io/enforce-mountable-secrets`: While the annotation's name suggests it only concerns the mounting of Secrets, its enforcement also extends to other ways Secrets are used in the context of a Pod. Therefore, it is crucial to ensure that all the referenced secrets are correctly specified in the ServiceAccount. </ins> ### StorageObjectInUseProtection **Type**: Mutating.

Discussion:
The documentation for the annotation on consists of : This leaves unclear the details of the actual effect of the annotation. By checking I was able to determine that setting this annotation to causes the following enforcements: (1) s mounted as must appear in the 's (2) s referenced in in or must appear in the 's (3) s referenced in of s must appear in the 's (1) is implied by the name of the annotation, but the lack of any mention of (2) or (3) in the documentation forced me to check the code to ensure that it wasn't only enforcing mounting of s as the name implies. The documentation also mentions only the field of the , yet the enforcement also takes into account the 's field (which the 's are checked against). The documentation would be improved by describing the actual enforcement behaviour that this feature implements. This feature may also benefit from being mentioned in the document.
/triage accepted /help /kind feature
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 : /triage accepted /help /kind feature </details
I see , can come up with something like: I'll take this up?
/assign
Change:
title: 클러스터(Cluster) id: cluster date: 2019-06-15 <del> full_link: </del> <ins> full_link: </ins> short_description: > <del> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> aka: tags: - fundamental - operation --- <del> 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </del> <ins> 컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. </ins> <del> <!--more--> </del> <ins> <!--more--> </ins> 워커 노드는 애플리케이션의 구성요소인 {{< glossary_tooltip text="파드" term_id="pod" >}}를 호스트한다. {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}은 워커 노드와

Discussion:
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: Glossary tooltip code for "node" shouldn't be in the short_description section. It doesn't display it correctly. Proposed Solution: Change it like original document. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Page to check:
/language ko /assign
Change:
### kubeadm 업그레이드 <del> 1.  모든 워커 노드에서 kubeadm을 업그레이드한다. </del> <ins> -  모든 워커 노드에서 kubeadm을 업그레이드한다. </ins> <del> {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </ins> # 1.18.x-00의 x를 최신 패치 버전으로 바꾼다 apt-mark unhold kubeadm &&  apt-get update && apt-get install -y kubeadm=1.18.x-00 &&  apt-mark hold kubeadm <ins> - </ins> # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update &&  apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </ins> # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다 yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> ### 노드 드레인 <del> 1.  스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. </del> <ins> -  스케줄 불가능(unschedulable)으로 표시하고 워크로드를 축출하여 유지 보수할 노드를 준비한다. </ins> ```shell # <node-to-drain>을 드레이닝하려는 노드 이름으로 바꾼다.

Discussion:
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: Broken layout on "kubeadm " ! Proposed Solution: Check and apply upstream changes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
/unassign This issue already has been assigned to .
Change:
kubectl get pod termination-demo -o go-template="{{range .status.containerStatuses}}{{.lastState.terminated.message}}{{end}}" <ins> If you are running a multi-container pod, you can use a Go template to include the container's name. By doing so, you can discover which of the containers is failing: ```shell kubectl get pod multi-container-pod -o go-template='{{range .status.containerStatuses}}{{printf "%s:n%snn" .name .lastState.terminated.message}}{{end}}' ``` </ins> ## Customizing the termination message Kubernetes retrieves termination messages from the termination message file

Discussion:
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 The example works well for a single-container pod. However, it is important for multi-container pods to know which container failed. The following command would show which container failed within the pod: Why is this needed Because the current command only shows the error message, not which container is failing — thus confusing if it is a multi-container pod. This change will hopefully help people running multi-container pods figuring out the faulty container. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --None.
/language en /triage accepted /priority backlog
/assign
Hello developers! I want to contribute to this issue and give info about multi-container. If anyone can guide me to the resources, it would be really helpful.
Hello , thanks for your help. You can take a look at the PR created , and see if you find anything odd. If so, please comment or add a patch to it. Thanks!
Okay!
Change:
Secrets that a Pod requests are potentially visible within its containers. Therefore, one Pod does not have access to the Secrets of another Pod. <ins> ### Configure least-privilege access to Secrets To enhance the security measures around Secrets, Kubernetes provides a mechanism: you can annotate a ServiceAccount as `kubernetes.io/enforce-mountable-secrets: "true"`. For more information, you can refer to the [documentation about this annotation](/docs/concepts/security/service-accounts/#enforce-mountable-secrets). </ins> {{< warning >}} Any containers that run with `privileged: true` on a node can access all Secrets used on that node.

Discussion:
The documentation for the annotation on consists of : This leaves unclear the details of the actual effect of the annotation. By checking I was able to determine that setting this annotation to causes the following enforcements: (1) s mounted as must appear in the 's (2) s referenced in in or must appear in the 's (3) s referenced in of s must appear in the 's (1) is implied by the name of the annotation, but the lack of any mention of (2) or (3) in the documentation forced me to check the code to ensure that it wasn't only enforcing mounting of s as the name implies. The documentation also mentions only the field of the , yet the enforcement also takes into account the 's field (which the 's are checked against). The documentation would be improved by describing the actual enforcement behaviour that this feature implements. This feature may also benefit from being mentioned in the document.
/triage accepted /help /kind feature
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 : /triage accepted /help /kind feature </details
I see , can come up with something like: I'll take this up?
/assign