jiebi/CodeConvo huggingface dataset:
Change:
1. Create the Pod: <del> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </del> <ins> kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/pod-redis.yaml </ins> 1. Verify that the Pod's Container is running, and then watch for changes to the Pod: <del> kubectl get --watch pod redis </del> <ins> kubectl get --watch pod redis </ins> The output looks like this: <del> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </del> <ins> NAME      READY     STATUS    RESTARTS   AGE redis     1/1       Running   0          13s </ins> 1. In another terminal, get a shell to the running Container: <del> kubectl exec -it redis -- /bin/bash </del> <ins> kubectl exec -it redis -- /bin/bash </ins> 1. In your shell, go to `/data/redis`, and create a file: <del> root@redis:/data/redis# echo Hello > test-file </del> <ins> root@redis:/data/redis# echo Hello > test-file </ins> 1. In your shell, list the running processes: <del> root@redis:/data/redis# ps aux </del> <ins> root@redis:/data/redis# ps aux </ins> The output is similar to this: <del> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </del> <ins> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379 root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux </ins> 1. In your shell, kill the redis process: <del> root@redis:/data/redis# kill <pid> </del> <ins> root@redis:/data/redis# kill <pid> </ins> where `<pid>` is the redis process ID (PID). 1. In your original terminal, watch for changes to the redis Pod. Eventually, you will see something like this: <del> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </del> <ins> NAME      READY     STATUS     RESTARTS   AGE redis     1/1       Running    0          13s redis     0/1       Completed  0         6m redis     1/1       Running    1         6m </ins> At this point, the Container has terminated and restarted. This is because the redis Pod has a

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] --- [ ] Feature Request [x] Bug Report Problem: This page has extra spaces before the commands: I am not sure it's a more systemic problem, but this causes commands to not to show up on the bash history (undesirable). Proposed Solution: Page to Update: /assign
A cursory look through the rest of the docs under Configure Pods and Containers showed that one out of four docs also had this issue. I'll make this change as I update the callouts.
Change:
{{< tabs name="k8s_install" >}} {{% tab name="Debian-based distributions" %}} <del> ```bash sudo apt-get update && sudo apt-get install -y apt-transport-https curl curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add - cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list deb https://apt.kubernetes.io/ kubernetes-xenial main EOF sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` </del> <ins> 1. Update the `apt` package index and install packages needed to use the Kubernetes `apt` repository: ```shell sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl ``` 2. Download the Google Cloud public signing key: ```shell sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg ``` 3. Add the Kubernetes `apt` repository: ```shell echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` 4. Update `apt` package index, install kubelet, kubeadm and kubectl, and pin their version: ```shell sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` </ins> {{% /tab %}} {{% tab name="Red Hat-based distributions" %}} ```bash

Discussion:
The current installation instructions for installing the third party Kubernetes Apt repository on Debian/Ubuntu, goes against best security practice. Currently the signing keys are to . The keychain should be downloaded to (file name to match the name used in ) using or (not as this is deprecated and will be last available in Debian 11 and Ubuntu 22.04) and referred to in as such Page to Update: References:
i read the linked pages and this change seems valid. thank you for bringing this up. would you help us by sending a PR for that? /sig cluster-lifecycle
/priority important-longterm /kind cleanup
/triage accepted
Please see
/sig cli
Change:
If the number of backend endpoints falls below 1000, the control plane removes this annotation. <ins> ### endpoints.kubernetes.io/last-change-trigger-time Type: Annotation Example: `endpoints.kubernetes.io/last-change-trigger-time: 2023-07-20T04:45:21Z` Used on: Endpoints This annotation set to an [Endpoints](/docs/concepts/services-networking/service/#endpoints) object that represents the timestamp (stored as RFC 3339 date-time string, e.g. '2018-10-22T19:32:52.1Z'). This is timestamp of the last change in some Pod or Service object, that triggered the endpoints object change. </ins> ### control-plane.alpha.kubernetes.io/leader (deprecated) {#control-plane-alpha-kubernetes-io-leader} Type: Annotation

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: Kubernetes sometimes sets an annotation, , on an Endpoints. However, this annotation is not documented in Proposed Solution: Document this annotation. If it's deprecated, note that (and set a custom fragment identifier). Page to Update: Additional Information: /sig network /language en
/assign
/triage accepted
Help on this issue is welcome.
Change:
これらのリソースを管理するコントローラーに固有のオプションを設定することにより、リソースのガベージコレクションを調整できます。次のページは、ガベージコレクションを設定する方法を示しています。 <del> * [Kubernetesオブジェクトのカスケード削除の設定](/docs/tasks/administer-cluster/use-cascading-deletion/) </del> <ins> * [Kubernetesオブジェクトのカスケード削除の設定](/ja/docs/tasks/administer-cluster/use-cascading-deletion/) </ins> * [完了したジョブのクリーンアップの設定](/ja/docs/concepts/workloads/controllers/ttlafterfinished/) <!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->

Discussion:
This is a Feature Request What would you like to be Translate tasks/administer-cluster/use-cascading-deletion/ into Japanese. Why is this needed This page has not been translated. Comments /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
Change:
value: "The Most Honorable" - name: NAME value: "Kubernetes" <ins> - name: MESSAGE value: "$(GREETING) $(HONORIFIC) $(NAME)" </ins> command: ["echo"] <del> args: ["$(GREETING) $(HONORIFIC) $(NAME)"] </del> <ins> args: ["$(MESSAGE)"] </ins> ``` Upon creation, the command `echo Warm greetings to The Most Honorable Kubernetes` is run on the container.

Discussion:
The "Using environment variables inside of your config" feature is great and has been very useful. Thanks! I have two minor suggestions: would also be useful to document which fields of a container spec this interpolation applies (or if it applies to almost all fields, what the exceptions are.) , the example is slightly confusing / misleading. The key feature that is documented here is the ability to statically use env vars defined in the config in other config fields. While the example is calling with a single string, it may look at a glance like a shell command which would do the interpolation itself (note notation and not or ). Perhaps a clearer example would be using env vars inside of other env vars: This shows more clearly that environment variable is configured statically from previously set environment variables - before the Pod is created, no shell interpolation involved.
/triage accepted /language en
/assign
As per my understanding, you are expecting here to add where this environment variable applies inside the configuration file like below. To set environment variables, include the env or envFrom field in the configuration file under .spec.containers[*]. Please confirm if i wrongly understood.
PR Raised here .
Change:
|    node-1 *drained*  |       node-2        |       node-3       | *no node*          | |:--------------------:|:-------------------:|:------------------:|:------------------:| <del> |                      | pod-b *available*   | pod-c *available*  | pod-e *pending*    | </del> <ins> |                      | pod-b *terminating* | pod-c *available*  | pod-e *pending*    | </ins> |                      | pod-d *available*   | pod-y              |                    | <!--

Discussion:
There are some bugs: ,node%2D1%20drained,no%20node,-pod%2Db%20available "pod-b available" should be changed to "pod-b terminating". "node-2" should be changed to "node-2 draining".
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign
Change:
* [Node Metrics Data](/docs/reference/instrumentation/node-metrics). <ins> * [CRI Pod & Container Metrics](/docs/reference/instrumentation/cri-pod-container-metrics). </ins>  No newline at end of file

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 feature gate amends node behavior around cAdvisor, but is not properly documented. Proposed Solution: Update to ~include~ hyperlink to a new page about the changes from For example, add a new page into Ideally, write those docs to be finished before the feature moves the beta, so that the only change needed for graduation there is to mark the feature as being stable. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en
Aim to title and frame the new reference page as describing the situation after the enhancement is complete. For example, the title could be “Metrics About Containers And Pods” rather than “Migration from cAdvisor”.
/triage accepted /priority important-soon
Not sure this will make 1.25, but good to track early.
/cc
/assign yeah I agree this is good criteria for beta. This kep having missed an alpha update in 1.25, it's not clear to me which release it will arrive in
We can document this at any time. We should push back on graduation to stable if there's not been any movement on documenting the changes. It's definitely better to have good docs ready to accompany actual graduation to beta, and it's nice to have at least some docs as soon as a feature goes alpha.
Relevant to
PR helps with this.
This issue is related to this
PR helps with this too.
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
/triage accepted We should do this. The more releases this slips, the more we're letting down end users.
/retitle Document feature gate / implications
Change:
namespace of that ServiceAccount (this is the same as the namespace of the Pod) and acts against that namespace. This is different from what happens outside of a cluster; when kubectl runs outside a cluster and you don't specify a namespace, <del> the kubectl command acts against the `default` namespace. </del> <ins> the kubectl command acts against the namespace set for the current context in your client configuration. To change the default namespace for your kubectl you can use the following command: ```shell kubectl config set-context --current --namespace=<namespace-name> ``` </ins> ## Operations

Discussion:
This is different from what happens outside of a cluster; when kubectl runs outside a cluster and you don't specify a namespace, the kubectl command acts against the default namespace. On the above documentation, the kubectl does not act against 'default' namespace but the one assigned to the current-context. The kubeconfig files default context may be pointed to 'default' namespace, but that is not the default namespace all the time.
Hey, I had to search to retrieve where the context of what you mentioned, for further info. This is indeed a simplification but might be correct most of the time with default configured kubeconfig contexts. It could be more precise, mentioning the kubeconfig file (keeping in mind that this section is about in-cluster config). /sig cli /triage accepted /priority backlog /language en
/retitle kubectl default namespace not always 'default' but depends on kubeconfig If you can find a better title, just needed to make something a bit more precise than just an issue on kubectl
/assign
Change:
### Dead link issues Depending on where the dead link is reported, different actions are required to resolve the issue. Dead links in the API and Kubectl docs are automation issues and should be assigned a P1 until the problem can be fully understood. All other dead links are issues that need to be manually fixed and can be assigned a P3. <ins> ### Support requests or code bug reports Some issues that are opened for docs are actually issues with the underlying code, or requests for assistance when something (such as a tutorial) didn't work. Since these issues aren't related to documentation requests or problems, it is appropriate to respond directing the requester to potential support avenues, and if relevant, where an appropriate issue can be filed if the problem is a bug report. - example support request response ``` Thank you for this report, This sounds more like a request for support and less like an issue specifically for docs. I encourage you to bring your question to the `#kubernetes-users` channel in [Kubernetes slack](http://slack.k8s.io/). You can also search resources like [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes) for answers  to similar questions. You can also open issues for Kubernetes functionality in https://github.com/kubernetes/kubernetes. If this is a documentation issue, please re-open this issue. ``` - example code bug report response ``` Thank you for this report, This sounds more like an issue with the code than an issue with the documentation. Please open an issue at https://github.com/kubernetes/kubernetes/issues. If this is a documentation issue, please re-open this issue. ``` </ins> {% endcapture %}

Discussion:
<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:
Change:
1. API server内のPodは、猶予期間を越えるとPodが「死んでいる」と見なされるように更新される。 削除中のPodに対して`kubectl describe`コマンドを使用すると、Podは「終了中」と表示される。 Podが実行されているNode上で、Podが終了しているとマークされている(正常な終了期間が設定されている)とkubeletが認識するとすぐに、kubeletはローカルでPodの終了プロセスを開始します。 <del> 1. Pod内のコンテナの1つが`preStop`[フック](/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 </del> <ins> 1. Pod内のコンテナの1つが`preStop`[フック](/ja/docs/concepts/containers/container-lifecycle-hooks/#hook-details)を定義している場合は、コンテナの内側で呼び出される。猶予期間が終了した後も `preStop`フックがまだ実行されている場合は、一度だけ猶予期間を延長される(2秒)。 </ins> {{< note >}} `preStop`フックが完了するまでにより長い時間が必要な場合は、`terminationGracePeriodSeconds`を変更する必要があります。 {{< /note >}}

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 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update some links and fix some expressions. Why is this needed Some of the links have already been translated Also, some expressions were not official. 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
Change:
PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. PodSecurityPolicy replacements are still under discussion, but current use can be migrated to <del> [3rd-party admission webhooks](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) now. </del> <ins> [3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now. </ins> #### RuntimeClass {#runtimeclass-v125}

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 href of contains unwanted . A slash () is missing in the href of . Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
/triage accepted
Change:
value: "windows" ``` <del> 1. Run `kubectl create -f runtimeClasses.yml` using as a cluster administrator 1. Add `runtimeClassName: windows-2019` as appropriate to Pod specs </del> <ins> 1. クラスター管理者として使用する`kubectl create -f runtimeClasses.yml`を実行します 1. Podの仕様に応じて`runtimeClassName: windows-2019`を追加します </ins> <del> For example: </del> <ins> 例: </ins> ```yaml apiVersion: apps/v1

Discussion:
This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/user-guide-windows-containers/ into Japanese Why is this needed This page has not been translated. Comments /language ja /assign
Change:
See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. <del> ### Automatic mounting of manually created Secrets Manually created secrets (for example, one containing a token for accessing a GitHub account) can be automatically attached to pods based on their service account. </del> ## Details ### Restrictions

Discussion:
This is a Bug Report <!--Required Information--Problem: It appears as if the Secret documentation references a feature that isn't currently implemented. Specifically, it includes the following: Prior to this was accompanied by the text: However, PodPresets have been dropped from Kubernetes. Accordingly, this section should reference a different mechanism to achieve the same goal if such a mechanism exists. If it doesn't it should be dropped. From my research, it looks like no such alternate mechanism exists. In another previous revision of that section, the section read: states that PodPresets should be used for secret automounting. It does not mention other options. It also does not imply that ServiceAccounts are relevant. It seems like the ServiceAccount association was back around 2015-2017. Proposed Solution: Unless a mechanism exists which associates Secrets with ServiceAccounts for the purpose of automounting Secrets in Pods associated with a specific ServiceAccount, this section should be dropped. If such a mechanism does exist, the section should be updated to reflect its use or refer to other docs that do. Page to Update:
/kind bug Relevant SIG is SIG Service Catalog, but anyone can tidy up (remove the mention of PodPreset). /triage accepted /language en /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 : /kind bug Relevant SIG is SIG Service Catalog, but anyone can tidy up (remove the mention of PodPreset). /language en /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