jiebi/CodeConvo huggingface dataset:
Code change:
This is a Feature Request Korean Localization for branch. What would you like to be Any localization contributions for Korean. Comments This issue is to notify the schedule of Korean localization to contributors. is the current work branch for Korean localization. Important dates A Korean localization work branch is merged to main branch after we complete around 3~4 weeks job. PR Freeze: 10/03 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 10/06 (merge to main branch) 3~4 , main . PR : 10/03 ( PR , PR ) : 10/06 (main , k8s.io ) /language ko /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 : ## In English This is a Feature Request is the current work branch for Korean localization.PR Freeze: 10/03 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 10/06 (merge to main branch) PR : 10/03 ( PR , PR ) : 10/06 (main , k8s.io ) /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
Thanks :) /triage accepted
/milestone dev-1.25-ko.1

Related discussion:
text: title: 코드 컨트리뷰터(Code Contributor) id: code-contributor date: 2018-04-12 <del> full_link: /ko/docs/community/devel/ </del> <ins> full_link: https://github.com/kubernetes/community/tree/master/contributors/devel </ins> short_description: > 쿠버네티스 오픈소스 코드베이스에 코드를 개발하고 기여하는 사람.
Code change:
This is a Bug Report I have fixed the same issue in English docs, same issue is followed by the other localization team. has one broken issue which needs to fix. ! Refer my merged PR of english docs. /assign
/triage accepted

Related discussion:
text: title: 代码贡献者（Code Contributor） id: code-contributor date: 2018-04-12 <del> full_link: /docs/community/devel/ </del> <ins> full_link: https://github.com/kubernetes/community/tree/master/contributors/devel </ins> short_description: > 为 Kubernetes 开源代码库开发并贡献代码的人。
Code change:
This is a Bug Report I have fixed the same issue in English docs, same issue is followed by the other localization team. has one broken issue which needs to fix. ! Refer my merged PR of english docs. /assign
/triage accepted

Related discussion:
text: title: Code Contributor id: code-contributor date: 2018-04-12 <del> full_link: /docs/community/devel/ </del> <ins> full_link: https://github.com/kubernetes/community/tree/master/contributors/devel </ins> short_description: > A person who develops and contributes code to the Kubernetes open source codebase.
Code change:
This is a Feature Request What would you like to be Translate content/ja/docs/tasks/debug/debug- into Japanese. Why is this needed This file is only translated the title, not translated the description and the body text. Comments /language ja
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
/assign

Related discussion:
text: --- title: アプリケーションのトラブルシューティング <del> description: Debugging common containerized application issues. </del> <ins> description: コンテナ化されたアプリケーションの一般的な問題をデバッグします。 </ins> weight: 20 --- <del> This doc contains a set of resources for fixing issues with containerized applications. It covers things like common issues with Kubernetes resources (like Pods, Services, or StatefulSets), advice on making sense of container termination messages, and ways to debug running containers. </del> <ins> このドキュメントには、コンテナ化されたアプリケーションの問題を解決するための、一連のリソースが記載されています。Kubernetesリソース(Pod、Service、StatefulSetなど)に関する一般的な問題や、コンテナ終了メッセージを理解するためのアドバイス、実行中のコンテナをデバッグする方法などが網羅されています。 </ins>
Code change:
If this is your first contribution, visit for information on how to get started. Review a few to see which content you have to change and which you leave unchanged. Make sure your base, target branch is and create a working branch called . Create a file called Copy the content of to the file you created Localize the content. Push your change and create a pull request. Completing this feature issue fixes part of /language hi /triage accepted
/assign Thank you

Related discussion:
text: <ins> --- title: क्यूबएडीएम (Kubeadm) id: kubeadm date: 2018-04-12 full_link: /docs/admin/kubeadm/ short_description: > कुबेरनेट्स को जल्दी से इंस्टॉल करने और एक सुरक्षित क्लस्टर स्थापित करने के लिए एक उपकरण। aka: tags: - tool - operation --- कुबेरनेट्स को जल्दी से इंस्टॉल करने और एक सुरक्षित क्लस्टर स्थापित करने के लिए एक उपकरण। <!--more--> आप कंट्रोल प्लेन और {{< glossary_tooltip text="वर्कर नोड्स" term_id="node" >}} दोनों घटकों को स्थापित करने के लिए क्यूबएडीएम का उपयोग कर सकते हैं। </ins>
Code change:
If this is your first contribution, visit for information on how to get started. Review a few to see which content you have to change and which you leave unchanged. Make sure your base, target branch is and create a working branch called . Create a file called Copy the content of to the file you created Localize the content. Push your change and create a pull request. Completing this feature issue fixes part of /language hi /triage accepted
/assign
Ahan! A great approach to helping new contributors. Sorry I missed that point. /unassign
Hello Team, This is my first issue on kubernetes/website. I would like to work on it /assign
Keep working on this issue. Feel free to raise a PR

Related discussion:
text: <ins> --- title: लिमिटरेंज (LimitRange) id: limitrange date: 2019-04-15 full_link:  /docs/concepts/policy/limit-range/ short_description: > नेमस्पेस में प्रति कंटेनर या पॉड में संसाधन खपत को सीमित करने के लिए प्रतिबंध प्रदान करता है। aka: tags: - core-object - fundamental - architecture related: - pod - container --- नेमस्पेस में प्रति {{< glossary_tooltip text="कंटेनर" term_id="container" >}} या {{< glossary_tooltip text="पॉड" term_id="pod" >}} में संसाधन खपत को सीमित करने के लिए प्रतिबंध प्रदान करता है। <!--more--> लिमिटरेंज, टाइप (type) द्वारा बनाई जा सकने वाले ऑब्जेक्ट्स और साथ ही नेमस्पेस में अलग-अलग {{< glossary_tooltip text="कंटेनर" term_id="container" >}} या {{< glossary_tooltip text="पॉड" term_id="pod" >}} द्वारा अनुरोध/उपभोग किए जा सकने वाले कंप्यूट संसाधनों की मात्रा को सीमित करता है। </ins>
Code change:
This is a Bug Report Objective should be replace by उद्देश्य in content/hi/docs/tutorials/kubernetes-basics/create-cluster/cluster- <!--Required Information--Problem: Objective is english word in hindi content Proposed Solution: Replace with उद्देश्य Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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
/kind documentation
/assign

Related discussion:
text: <div class="row"> <div class="col-md-8"> <del> <h3>Objectives</h3> </del> <ins> <h3>उद्देश्य</h3> </ins> <ul> <li>जानें कुबेरनेट्स क्लस्टर क्या है।</li> <li>जानें मिनिक्यूब क्या है।</li>
Code change:
Umbrella issue: contains multiple "use cases" for Secrets. However, many of these are mini-tasks. In this issue, I'd like to discuss each of these use cases at a high level to see which we can remove, which we can trim, and which we can move to a new or existing task page. That way, the "Use cases section could even be a bulleted list with links to relevant tasks. Use case: As container environment variables Recommendation: Delete Justification: the goal is achieved in . This also isn't a use case, it's a way to use a secret. Use case: Pod with SSH keys Recommendation: Delete content, keep use case as bullet Justification: the steps add no value beyond the existing task to . Use case: Pods with prod / test credentials Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page. Use case: dotfiles in a secret volume Recommendation: Remove steps and keep as bullet point with additional info about why it would be useful. Use case: Secret visible to one container in a Pod Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page with actual steps to achieve more than just "secret visible to one container". Perhaps including RBAC steps. If you're interested, review each use case and leave a comment for each agreeing, disagreeing, or providing a different approach to each use case. After we've discussed and settled on an action for these use cases, we can start the actual work! /sig docs /cc
/assign
I think the "Use case: As container environment variables" can be removed as the goal is achieved in too.
Yeah agreed, although I'm separately removing that section and linking it to our existing task page as part of
Let's shift "Use case: Pods with prod/test credentials" and "Use case: secret visible to one container in a Pod" to and attach the link in the use case section as bullet notes.
/triage accepted
Imo the prod/test thing might not even need to move - it can live as an example in the concept but the task steps seem quite basic now that I think about it. Just referencing two Secrets in two different Pods...

Related discussion:
text: Kubernetes imposes on them. | Built-in Type                         | Usage                                   | <del> | ------------------------------------- | --------------------------------------- | | `Opaque`                              | arbitrary user-defined data             | </del> <ins> | ------------------------------------- |---------------------------------------- | | `Opaque`                              | arbitrary user-defined data            | </ins> | `kubernetes.io/service-account-token` | ServiceAccount token                    | | `kubernetes.io/dockercfg`             | serialized `~/.dockercfg` file          | | `kubernetes.io/dockerconfigjson`      | serialized `~/.docker/config.json` file |
Code change:
Umbrella issue: contains multiple "use cases" for Secrets. However, many of these are mini-tasks. In this issue, I'd like to discuss each of these use cases at a high level to see which we can remove, which we can trim, and which we can move to a new or existing task page. That way, the "Use cases section could even be a bulleted list with links to relevant tasks. Use case: As container environment variables Recommendation: Delete Justification: the goal is achieved in . This also isn't a use case, it's a way to use a secret. Use case: Pod with SSH keys Recommendation: Delete content, keep use case as bullet Justification: the steps add no value beyond the existing task to . Use case: Pods with prod / test credentials Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page. Use case: dotfiles in a secret volume Recommendation: Remove steps and keep as bullet point with additional info about why it would be useful. Use case: Secret visible to one container in a Pod Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page with actual steps to achieve more than just "secret visible to one container". Perhaps including RBAC steps. If you're interested, review each use case and leave a comment for each agreeing, disagreeing, or providing a different approach to each use case. After we've discussed and settled on an action for these use cases, we can start the actual work! /sig docs /cc
/assign
I think the "Use case: As container environment variables" can be removed as the goal is achieved in too.
Yeah agreed, although I'm separately removing that section and linking it to our existing task page as part of
Let's shift "Use case: Pods with prod/test credentials" and "Use case: secret visible to one container in a Pod" to and attach the link in the use case section as bullet notes.
/triage accepted
Imo the prod/test thing might not even need to move - it can live as an example in the concept but the task steps seem quite basic now that I think about it. Just referencing two Secrets in two different Pods...

Related discussion:
text: name: mypod spec: containers: <del> - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: </del> <ins> - name: mypod image: redis volumeMounts: </ins> - name: foo <del> secret: secretName: mysecret optional: true </del> <ins> mountPath: "/etc/foo" readOnly: true volumes: - name: foo secret: secretName: mysecret optional: true </ins> ``` By default, Secrets are required. None of a Pod's containers will start until
Code change:
This is a Bug Report <!--Required Information--From k8s v1.24 the and are no longer available as a feature gate in k8s. From v1.25 there is a separate document that contains information on feature gates that have been removed i.e. . In the and feature gate link to the page which is incorrect, instead of that, it should be page. The information for both feature gates is on the Feature Gates (removed) page not on the Feature Gates page. Proposed Solution: SupportNodePidsLimit and SupportPodPidsLimit feature gates should be linked to instead of 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
/kind documentation /assign
For GA'ed feature or deprecated feature, if the gate is removed, we may want to remove the linking texts altogether rather than having existing text pointing to the outdate gate names.
Hi Just want to confirm it: So for this, you want to remove the whole note section for both feature gates, because both feature gates are removed. Am I understanding right?
is it seems good to you?
I meant this: move the "removed" feature to the dedicated page, if this is not done yet. The "removed" features will stay there for the sole purpose of reference. For all texts (including notes) that reference these gates, remove those references. If a feature is deprecated and removed, those texts may well become invalid. If a feature is GA'ed and removed, those texts may be still valid, but the reference to the gate should disappear.
Thanks, for your response.
and both feature gates were graduated in v1.20 and removed in v1.23. Both are present on the dedicated page i.e. . So I will remove the reference to these gates.
I will create PR for it soon.
Fixed it here:

Related discussion:
text: be reserved for the system as a whole and for Kubernetes system daemons respectively. <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting with Node-level reservations required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. {{< /note >}} </del> ## Pod PID limits Kubernetes allows you to limit the number of processes running in a Pod. You
Code change:
This is a Bug Report <!--Required Information--From k8s v1.24 the and are no longer available as a feature gate in k8s. From v1.25 there is a separate document that contains information on feature gates that have been removed i.e. . In the and feature gate link to the page which is incorrect, instead of that, it should be page. The information for both feature gates is on the Feature Gates (removed) page not on the Feature Gates page. Proposed Solution: SupportNodePidsLimit and SupportPodPidsLimit feature gates should be linked to instead of 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
/kind documentation /assign
For GA'ed feature or deprecated feature, if the gate is removed, we may want to remove the linking texts altogether rather than having existing text pointing to the outdate gate names.
Hi Just want to confirm it: So for this, you want to remove the whole note section for both feature gates, because both feature gates are removed. Am I understanding right?
is it seems good to you?
I meant this: move the "removed" feature to the dedicated page, if this is not done yet. The "removed" features will stay there for the sole purpose of reference. For all texts (including notes) that reference these gates, remove those references. If a feature is deprecated and removed, those texts may well become invalid. If a feature is GA'ed and removed, those texts may be still valid, but the reference to the gate should disappear.
Thanks, for your response.
and both feature gates were graduated in v1.20 and removed in v1.23. Both are present on the dedicated page i.e. . So I will remove the reference to these gates.
I will create PR for it soon.
Fixed it here:

Related discussion:
text: to the kubelet, or set `PodPidsLimit` in the kubelet [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting for Pods required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. {{< /note >}} </del> ## PID based eviction You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources.
Code change:
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. --Add description that startupProbe successThreshold must be 1. Why is this needed The limitation has already been mentioned in the English page. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --I checked startupProbe successThreshold must be 1. /language ja
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

Related discussion:
text: * `periodSeconds`: Probeが実行される頻度(秒数)。デフォルトは10秒。最小値は1。 * `timeoutSeconds`: Probeがタイムアウトになるまでの秒数。デフォルトは1秒。最小値は1。 * `successThreshold`: 一度Probeが失敗した後、次のProbeが成功したとみなされるための最小連続成功数。 <del> デフォルトは1。Liveness Probeには1を設定する必要があります。最小値は1。 </del> <ins> デフォルトは1。Liveness ProbeおよびStartup Probeには1を設定する必要があります。最小値は1。 </ins> * `failureThreshold`: Probeが失敗した場合、Kubernetesは`failureThreshold`に設定した回数までProbeを試行します。 Liveness Probeにおいて、試行回数に到達することはコンテナを再起動することを意味します。 Readiness Probeの場合は、Podが準備できていない状態として通知されます。デフォルトは3。最小値は1。
Code change:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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 Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

Related discussion:
text: ... ``` <del> contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But *this* policy: </del> <ins> This policy contains a single `from` element allowing connections from Pods with the label `role=client` in namespaces with the label `user=alice`. But the following policy is different: </ins> ```yaml ...
Code change:
I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
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 Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign

Related discussion:
text: ... ``` <del> contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. </del> <ins> It contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`. </ins> When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy. <a name="behavior-of-ipblock-selectors"></a> <del> __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. </del> <ins> **ipBlock**: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. </ins> Cluster ingress and egress mechanisms often require rewriting the source or destination IP of packets. In cases where this happens, it is not defined whether this happens before or