jiebi/CodeConvo huggingface dataset:
Change:
## 설치 방법 <del> kubeadm을 설치하려면, [설치 가이드](/docs/setup/production-environment/tools/kubeadm/install-kubeadm)를 참고한다. </del> <ins> kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)를 참고한다. </ins> ## {{% heading "whatsnext" %}} <del> * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다. * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다. * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다. * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token): `kubeadm join` 을 위한 토큰을 관리한다. * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version): kubeadm 버전을 출력한다. * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. </del> <ins> * [kubeadm init](/docs/reference/setup-tools/kubeadm/kubeadm-init/): 쿠버네티스 컨트롤 플레인 노드를 부트스트랩한다. * [kubeadm join](/docs/reference/setup-tools/kubeadm/kubeadm-join/): 쿠버네티스 워커(worker) 노드를 부트스트랩하고 클러스터에 조인시킨다. * [kubeadm upgrade](/docs/reference/setup-tools/kubeadm/kubeadm-upgrade/): 쿠버네티스 클러스터를 새로운 버전으로 업그레이드한다. * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다. * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다. * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. </ins>

Discussion:
<!-- 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 href is (English). The of is recently in . Proposed Solution: In , Before: After: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
/language ko
/triage accepted
Resolved by
Change:
## {{% heading "whatsnext" %}} <ins> * Read the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator White Paper](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md). </ins> * Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case * [Publish](https://operatorhub.io/) your operator for other people to use

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 Update to have an extra link in it's What's Next section, pointing at Why is this needed The is very relevant to people reading about the operator pattern. Comments /language en /kind feature
/good-first-issue /triage accepted
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 : /good-first-issue /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
/assign I can work on this.
Fixed it here
Change:
要确认 hypervisor 和 Minikube 均已成功安装，可以运行以下命令来启动本地 Kubernetes 集群： <del> {{< note >}} </del> <!-- For setting the `--vm-driver` with `minikube start`, enter the name of the hypervisor you installed in lowercase letters where `<driver_name>` is mentioned below. A full list of `--vm-driver` values is available in [specifying the VM driver documentation](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver). --> <del> 通过 `minikube start` 设置 `--vm-driver`。在下面提到 `<driver_name>` 的地方，用小写字母，输入你安装的 hypervisor 的名称。 [指定 VM 驱动程序](https://kubernetes.io/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表 </del> <ins> {{< note >}} 若要为 `minikube start` 设置 `--vm-driver`，在下面提到 `<driver_name>` 的地方，用小写字母输入你安装的 hypervisor 的名称。 [指定 VM 驱动程序](/docs/setup/learning-environment/minikube/#specifying-the-vm-driver) 列举了 `--vm-driver` 值的完整列表。 </ins> {{< /note >}} ```shell

Discussion:
Note shortcode with html comment wont be parsed correctly Problem: After has been updated since , the HTML comment inside will result in markdownify not working correctly. English version docs: ! Chinese version docs: ! Proposed Solution: Move the HTML comment outside the shortcode, it does work correctly. Just like this.
This partially duplicates issue
Change:
| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership | | [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Product Security Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | <ins> ### Security Embargo Policy Some information about releases is subject to embargo and we have defined policy about how those embargos are set. Please refer [Security Embargo Policy](https://github.com/kubernetes/security/blob/master/private-distributors-list.md#embargo-policy) here for more information. </ins> ## Handbooks **NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.**

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 Mention the within , or link to it. Why is this needed Readers might have an interest in knowing how security fixes are planned and communicated. Comments /sig release /sig security /language en /kind feature
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 I can work on this.
Hi Please suggest which option from the following I will go with In this, we will have to make a page for embargo policy(security-embargo-) as we do not mention the link directly. 1) Copy the whole content from the to security-embargo- which seems redudant as it already mention in kubernete/security. 2) Mention the below text and then the link to for more details like:
I can clarify: this issue is about explaining that some information about upcoming releases is subject to embago, and that there is a defined policy about how those embargos are set. I don't see a need to mention how to join the mailing list for distributors within If someone is maintaining a Kubernetes distribution, I hope they're able to follow hyperlinks well enough to work that out. We have readers who might not think to look there. That's why we should refer to it (a hyperlink could be OK).
Thanks for suggestion. will create a pr for it soon.
fixed it here:
Change:
NAME                            READY     STATUS    RESTARTS   AGE frontend-3823415956-k22zn       1/1       Running   0          1h frontend-3823415956-w9gbt       1/1       Running   0          1h <del> mongo-1068406935-3lswp   1/1       Running   0          1h </del> <ins> mongo-1068406935-3lswp          1/1       Running   0          1h </ins> ```

Discussion:
4 ordered lists have wrong indexes. For example, the number below should be 3. ! Page to update: /language en /kind cleanup
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
Change:
# Array of authenticated usernames to exempt. usernames: [] # Array of runtime class names to exempt. <del> runtimeClassNames: [] </del> <ins> runtimeClasses: [] </ins> # Array of namespaces to exempt. namespaces: [] ```

Discussion:
In the v1beta1 admission config example, I had to use rather than See
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
Page:
/sig auth /language en /assign
Change:
1. You use the `kubectl` tool to manually delete a specific Pod, with the default grace period (30 seconds). 1. The Pod in the API server is updated with the time beyond which the Pod is considered "dead" <del> along with the grace period. </del> <ins> along with the grace period. </ins> If you use `kubectl describe` to check on the Pod you're deleting, that Pod shows up as <del> "Terminating". </del> <ins> "Terminating". </ins> On the node where the Pod is running: as soon as the kubelet sees that a Pod has been marked as terminating (a graceful shutdown duration has been set), the kubelet begins the local Pod shutdown process.

Discussion:
Second sentence of the second paragraph is obviously incomplete. It reads like this . ! It would be good to restore missing bit.
Page is PR introduced the regression; I suggest the second “handles” should instead read “determines what action to take to make the Pod healthy again”. /kind bug /language en /triage accepted /priority backlog Thanks
/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 : /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
Change:
## 金丝雀部署 {#canary-deployment} 如果要使用 Deployment 向用户子集或服务器子集上线版本， <del> 则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 所描述的金丝雀模式，创建多个 Deployment，每个版本一个。 </del> <ins> 则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)所描述的金丝雀模式， 创建多个 Deployment，每个版本一个。 </ins> <!-- ## Writing a Deployment Spec

Discussion:
There are some bugs: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" "image updated to 1.9.1" should be changed to "image updated to 1.16.1" The content of this article has many "", it could be changed to "deployment". For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
/language zh
/triage accepted
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
looks like docs is already updated to nginx:1.16.1. Do you mind closing this issue?
There should still be a few places left unfinished.
Could you please edit the issue which needs to be still updated?
Bug1: ,nginx%3Dnginx%3A1.9.1,-%2D%2Drecord%3Dtrue%0A3 "nginx=nginx:1.9.1" should be changed to "nginx=nginx:1.16.1" Bug2: ,nginx%3Dnginx%3A1.91,-%2D%2Drecord%3Dtrue "nginx=nginx:1.91" should be changed to "nginx=nginx:1.161" Bug3: "image updated to 1.9.1" should be changed to "image updated to 1.16.1" Bug4: The content of this article has many "", it could be changed to "deployment".

For example: ,,-%E8%BE%93%E5%87%BA%E7%B1%BB%E4%BC%BC%E4%BA%8E "kubectl rollout history " could be changed to "kubectl rollout history deployment/nginx-deployment"
Thanks for clarifying. /assign
/retitle [zh] Localization bugs / work required for Deployment concept
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
/triage accepted
Change:
1. There is not yet an easy way to generate a `kubeconfig` file which can be used to authenticate to the cluster remotely with `kubectl` on, for example, your workstation. Workaround: copy the kubelet's `kubeconfig` from the master: use `scp root@<master>:/etc/kubernetes/admin.conf .` and then e.g. `kubectl --kubeconfig ./admin.conf get nodes` from your workstation. <ins> 1. If you are using VirtualBox (directly or via Vagrant), you will need to ensure that `hostname -i` returns a routable IP address (i.e. one on the second network interface, not the first one). By default, it doesn't do this and kubelet ends-up using first non-loopback network interface, which is usually NATed. Workaround: Modify `/etc/hosts`, take a look at this [`Vagrantfile`][ubuntu-vagrantfile] for how you this can be achieved. [ubuntu-vagrantfile]: https://github.com/errordeveloper/k8s-playground/blob/22dd39dfc06111235620e6c4404a96ae146f26fd/Vagrantfile#L11), </ins>

Discussion:
<!-- 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: The other day I was informed that when interracting with the Kubernetes Developer Community on slack I should change my Slack display name to be the same as my github handle. The person telling me then wondered if we had this documented in the new developer guide. I checked and this does not appear to be mentioned in the new developer guide. Proposed Solution: Add a section to the new developer guide () to mention that when interracting with the Kubernetes Developer Community on slack all contributors should make sure their Slack display name is the same as their github handle. Page to Update:
Great! I'll add this one to my todo list. Thanks!
It'd also be good to keep the icon the same between GH and slack. I think that's more recognizable. But that's okay, it depends on guys' wish.
Change:
Different kinds of object can also have different `.status`; again, the API reference pages detail the structure of that `.status` field, and its content for each different type of object. <ins> ## Server side field validation Starting with Kubernetes v1.25, the API server offers server side [field validation](/docs/reference/using-api/api-concepts/#field-validation) that detects unrecognized or duplicate fields in an object. It provides all the functionality of `kubectl --validate` on the server side. The `kubectl` tool uses the `--validate` flag to set the level of field validation. It accepts the values `ignore`, `warn`, and `strict` while also accepting the values `true` (equivalent to `strict`) and `false` (equivalent to `ignore`). The default validation setting for `kubectl` is `--validate=true`. `Strict` : Strict field validation, errors on validation failure `Warn` : Field validation is performed, but errors are exposed as warnings rather than failing the request `Ignore` : No server side field validation is performed When `kubectl` cannot connect to an API server that supports field validation it will fall back to using client-side validation. Kubernetes 1.27 and later versions always offer field validation; older Kubernetes releases might not. If your cluster is older than v1.27, check the documentation for your version of Kubernetes. </ins> ## {{% heading "whatsnext" %}} If you're new to Kubernetes, read more about the following:

Discussion:
The docs on currently make no mention of field validation. Now that of unknown and duplicate fields is graduating to GA, we should mention it briefly here.
/cc
/triage accepted
/wg api-expression /language en /priority important-longterm /sig api-machinery
/assign
Change:
### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG_SAVED </del> <ins> export KUBECONFIG="$KUBECONFIG_SAVED" </ins> ``` ### Windows PowerShell

Discussion:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
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 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]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign
Change:
## Taint Nodes by Condition <del> The node lifecycle controller automatically creates taints corresponding to Node conditions with `NoSchedule` effect. Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations. </del> <ins> The control plane, using the node {{<glossary_tooltip text="controller" term_id="controller">}}, automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/pod-eviction#node-conditions). The scheduler checks taints, not node conditions, when it makes scheduling decisions. This ensures that node conditions don't directly affect scheduling. For example, if the `DiskPressure` node condition is active, the control plane adds the `node.kubernetes.io/disk-pressure` taint and does not schedule new pods onto the affected node. If the `MemoryPressure` node condition is active, the control plane adds the `node.kubernetes.io/memory-pressure` taint. You can ignore node conditions for newly created pods by adding the corresponding Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure` toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}} other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed` or `Burstable` QoS classes (even pods with no memory request set) as if they are able to cope with memory pressure, while new `BestEffort` pods are not scheduled onto the affected node. </ins> The DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from breaking.

Discussion:
Page to update: Blocked by Based on in PR , we should add the following information about node conditions to the Taint Nodes by Condition section of this page. The API server also respects when making scheduling decisions. For example, If the node condition is active, the system doesn't allow any new Pods to schedule on the node. If the node condition is active on a node, the system doesn't allow new pods on the node. What is "the system"? The API server? /cc /assign /sig docs /language en
"The system" is a mix of components: the kube-controller-manager sets the taints via the node controller. apiserver sets the toleration for DiskPressure for non-BestEffort pods. scheduler checks if pods have tolerations for the taint But that's too much implementation detail. "The system" or "the control plane" should be enough. WDYT ?
Ah, if it's the control plane then we can say that haha I thought it was something else :P
/triage accepted
Change:
<ins> {{/* If a 404 occurs and the referrer is a different version of the Kubernetes documentation, don't show the regular 404 error page, but instead redirect to the site root */}} <script type="text/javascript"> var sameBaseUrlRegExp = new RegExp("^" + location.protocol + "//" + location.host.replace(".", ".") + "/.*", "i"); var kubernetesDocumentationUrlRegExp = new RegExp("^https?://(.+.)?kubernetes.io/.*", "i"); if (!sameBaseUrlRegExp.test(document.referrer) && kubernetesDocumentationUrlRegExp.test(document.referrer)) { location.replace("/"); } </script> </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: Current page is lost when switching between documentation versions. Steps to reproduce to some page in the docs, for example the version selector at the top of the page to change to 1.17. that it it sends me to the instead of showing me the . Proposed Solution: Keep the relative path when switching versions Page to Update: All <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: Am I wrong that it used to preserve the page you are on when switching versions? I feel like it used to do that, but I'm not 100% sure.
Yes, at some point the site kept the same page when switching between versions.
/kind bug /priority backlog (I think this is a low-priority-backlog sort of issue; it's a frustration, but we have other places where it makes sense to focus effort first).
/area web-development