jiebi/CodeConvo huggingface dataset:
Change:
readinessProbe: tcpSocket: port: 8080 <del> initialDelaySeconds: 5 </del> <ins> initialDelaySeconds: 15 </ins> periodSeconds: 10 livenessProbe: tcpSocket:

Discussion:
‘’ TCP ‘’ ‘initialDelaySeconds: 5’“kubelet 15 ”“kubelet 5 ”
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
It is advisable to raise issues in English language. So, that everyone will be able to understand it. Translation of issue:- In the case of "defining TCP survival detection", the sample code of the readiness probe is configured as 'initialDelaySeconds: 5', but in the subsequent description, it is said that "kubelet will send the first readiness probe 15 seconds after the container starts. Needle", does it need to be changed to "kubelet will send the first readiness probe 5 seconds after the container starts"?
/sig docs /kind support
ok, thanks for translating for me.
/triage needs-information Even with a translation, I don't understand if this is a bug report, a support query, or a feature request. If this is a report of a problem with the Chinese page, and the page in Chinese faithfully localizes an English page where there is room for improvement, then we'd want a report against the English page.
Page related Issue: /language zh-cn
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Page related Issue: /language zh-cn 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
/language zh
I think the issue raised is correct as readinessprobe initialdelayseconds should also be 15 as the description involve 15 sec. So I think it needs to be change. "kubelet 15 " Referring the english documented part I think it needs to be changed.
I think you should raise the issue in English. It will be more useful for contributor to approach the issue. Please try to raise it in English.
Right, the of the readinessProbe should be 15 instead of 5.

Refer to the english documented part and the following description /assign
/retitle Inconsistent between en and zh in an example of tcp-liveness- Hi , please use english to describe your issue instead of a localized language (zh-cn), thanks.
Change:
You can use the `check-expiration` subcommand to check when certificates expire: <del> ``` </del> <ins> ```shell </ins> kubeadm certs check-expiration ``` The output is similar to this: <del> ``` </del> <ins> ```console </ins> CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no

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: Url selector #kubelet-config-k8s-io-v1beta1-KubeletConfiguration doesn't make a difference between: and Proposed Solution: Removing the selector from the URLs 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
/language en
/assign
/retitle Problems with (generated) reference for kubelet configuration
Change:
OpenAPIV3 schema under certain conditions. Users can update to the new schema safely without bumping the version of the object or breaking workflows. <del> While most validations placed in the OpenAPIV3 schema of a CRD are support </del> <ins> While most validations placed in the OpenAPIV3 schema of a CRD support </ins> ratcheting, there are a few exceptions. The following OpenAPIV3 schema validations are not supported by ratcheting under the implementation in Kubernetes {{< skew currentVersion >}} and if violated will continue to throw an error as normally:

Discussion:
simple typo: "The API server is willing accept updates to resources that are not valid after the update" It probably should be "The API server is willing to accept updates to resources that are not valid after the update"
Page related to the issue: /language en
/assign
Hi Thank you for raising the issue please let me know if you want to work on this issue; I will unassign it. Also, make sure to follow the community guidelines by not creating multiple issues on a single page.
Issue could have also been here, instead of a separate issue /remove-kind bug /kind feature /sig docs
The issue is resolved here .
Change:
To be able to create Indexed Jobs, make sure to enable the `IndexedJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) <del> on the [API server](docs/reference/command-line-tools-reference/kube-apiserver/) </del> <ins> on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) </ins> and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <!-- steps -->

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: In there is a table broken with GitHub Markdown renderer. ! BTW, the table is not broken with Hugo Markdown renderer. ! Proposed Solution: Page to Update: No Page on to Update. Just a Markdown file on GitHub to update. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/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
We support viewing the rendered documentation via I don't think this issue is valid.
/priority awaiting-more-evidence /langauge en
Thank for your comment. I will describe a bit more about this issue I opened. [As-is] Yes, although the second row of the Markdown code has 4 columns and other rows have 3 columns, this table is rendered alright by Hugo Markdown renderer. This is a issue about improving consistency of the number of columns in the Markdown code, regardless of the type of Markdown renderer. [To-be]

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: In , the link is broken. Proposed Solution: In Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/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
already logged here: /close /sig cluster-lifecycle
Closing this issue. <detailsIn response to : already logged here: /sig cluster-lifecycle 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:
- start with an alphanumeric character - end with an alphanumeric character <del> ### DNS Label Names </del> <ins> ### RFC 1123 Label Names {#dns-label-names} </ins> Some resource types require their names to follow the DNS label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).

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: Pod / Service names can not start with an alphanumeric character in kubernetes, but should be possible according to RFC1123 Proposed Solution: Change documentation in sections and to: or change kubernetes name check to use the specification in RFC1123. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 19.11 <!--Additional Information:--
Kubernetes does not strictly follow the RFC.
this might be true, but the documentation says otherwise. eg.
According to the validation logic, starting with alphanumeric characters should be okay. Can you paste the error message you have got?
I tried locally, and getting this error !
Just double checked the validation logic for core v1 Service. Its name must be a RFC1035 label rather than a RFC1123 label. This is something we need to fix in the docs. Related code:
/triage accepted /kind bug /assign
Change:
*   If your nodes use Kubernetes v1.23 and earlier and these flags aren't present or if the `--container-runtime` flag is not `remote`, <del> you use the dockershim socket with Docker Engine. </del> <ins> you use the dockershim socket with Docker Engine. The `--container-runtime` command line argument is not available in Kubernetes v1.27 and later. </ins> *   If the `--container-runtime-endpoint` flag is present, check the socket name to find out which runtime you use. For example, `unix:///run/containerd/containerd.sock` is the containerd endpoint.

Discussion:
Documentation for external etcd cluster for kubernetes 1.27 is not up to date That the documentation doesn't take into consideration the fact that was removed in version 1.27 of kubelet: Restart=always Just try to install kubernetes with an external etcd cluster (which right now doesn't work anyway also for other reasons related to this ) with version 1.27.2 and you'll get: No response <details27.2 </details<detailsself-hosted </details<details</details<detailskubeadm </details<detailscontainerd </details<detailscalico </details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/transfer website /assign
removed the comment in v1.27. is not re-generated. I opened to fix it.
/retitle flag still in the documentation for external etcd in version 1.27 despite removal /language en /triage accepted
Change:
<!-- Number of nodes per second on which pods are deleted in case of node failure when a zone is healthy (see --unhealthy-zone-threshold for definition of healthy/unhealthy). Zone refers to entire cluster in non-multizone clusters. --> <del> 当某区域变得不健康，节点失效时，每秒钟可以从此标志所设定的节点 个数上删除 Pods。请参阅 <code>--unhealthy-zone-threshold</code> </del> <ins> 当某区域健康时，在节点故障的情况下每秒删除 Pods 的节点数。 请参阅 <code>--unhealthy-zone-threshold</code> </ins> 以了解“健康”的判定标准。这里的区域（zone）在集群并不跨多个区域时 指的是整个集群。 </td>

Discussion:
The Chinese document of "when a zone is healthy" is completely the opposite meaning. it should be
/triage /kind bug /language zh
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /triage /kind bug /language zh </details
/triage accepted
/assign
Change:
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/{{< param "version" >}}/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list ``` <del> {{< note >}} To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/apt/sources.list.d/kubernetes.list` before running `apt-get update` and `apt-get upgrade`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/). {{< /note >}} </del> <ins> {{< note >}} To upgrade kubectl to another minor release, you'll need to bump the version in `/etc/apt/sources.list.d/kubernetes.list` before running `apt-get update` and `apt-get upgrade`. This procedure is described in more detail in [Changing The Kubernetes Package Repository](/docs/tasks/administer-cluster/kubeadm/change-package-repository/). {{< /note >}} </ins> 4. Update `apt` package index, then install kubectl:

Discussion:
The following tab has missing or duplicate content: Install using native package management
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 related to issue: /language en
/kind bug
The tabs don't seem to be working right in that page. Fixes are welcome. I am wary to triage this as Accepted though as I'm worried that the bug description is unclear.
In addition to the tab content, there seems to be an issue with the overall layout, which appears to be disrupted. This might have been unintentionally caused by the changes introduced in It's possible that this occurred because the release documentation deadline was approaching, leading us to merge it based on an older Netlify build preview instead of verifying it with the latest Netlify preview build.
I've opened to address and rectify this layout. /assign
There's a shortcoming around merges and Netlify. The preview from Netlify shows how the branch renders; it doesn't show (merge train style) how the site would look after the merge.
/assign
Change:
- The `--control-plane` flag tells `kubeadm join` to create a new control plane. - The `--certificate-key ...` will cause the control plane certificates to be downloaded <del> from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. </del> <ins> from the `kubeadm-certs` Secret in the cluster and be decrypted using the given key. </ins> ## External etcd nodes

Discussion:
This is a Bug Report Formatting is off (broken HTML rendering) on page since earlier this week (Wednesday sometime?) per my comment in - I'm adding as a separate ticket for tracking. Some fixes to Hugo were made in and but the issues on this page are persisting. Problem: Seeing poor formatting and plaintext HTML due to some incorrect syntax on the page: ! - screenshot taken in FireFox, but replicated in Chromium (Brave) as well. Page to Update: Thank you! [EDIT] heh - I switched GitHub accounts - the comments I was referring to were by my other account
thanks for the report. cc possibly caused by the hugo bump too? /sig docs cluster-lifecycle /kind bug
Relates to tracking issue
This is almost fixed. There are some leftovers related to the ordered list. /assign
Change:
over the package builds. This means that anything before v1.24.0 will only be available in the Google-hosted repository. - There's a dedicated package repository for each Kubernetes minor version. <del> When upgrading to to a different minor release, you must bear in mind that </del> <ins> When upgrading to a different minor release, you must bear in mind that </ins> the package repository details also change. {{< /note >}}

Discussion:
This is a Bug Report Problem: Repetitive word in Installing section under Note. Proposed Solution: Remove the repetitive word 'to' Page to Update:
/sig docs /language en /good-first-issue
This request has been marked as suitable for new contributors. 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 : /sig docs /language en /good-first-issue 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
/retitle Repeated word in Install kubeadm page /triage accepted
I will sumbit fix for this plzz /assign
I have attempt to make change for this inf
Change:
<td colspan="2">--experimental-mounter-path string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>mount</code></td> </tr> <tr> <del> <td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default <code>mount</code>. (DEPRECATED: will be removed in 1.23, in favor of using CSI.)</td> </del> <ins> <td></td><td style="line-height: 130%; word-wrap: break-word;">[Experimental] Path of mounter binary. Leave empty to use the default <code>mount</code>. (DEPRECATED: will be removed in 1.24 or later, in favor of using CSI.)</td> </ins> </tr> <tr>

Discussion:
As per the Kubernetes documentation option is deprecated and removed in v1.23. The link for the documentation. But this parameter is still valid. I got the confiramation. Kublet code : configured the kubelet with in my test K8s v1.23 environment. validated in the # sig-cloud-provider. Document should reflect the correct details: The link for the documentation. Configure the kubelet with the option. No response <details</details<detailsopenstack </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. 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
/sig node /sig cloud-provider
This pr has fixed this, waiting website docs to be published.
/kind documentation /remove-kind bug /transfer-issue website
/assign
Change:
The kubelet in Kubernetes v{{< skew currentVersion >}} collects spans from the garbage collection, pod synchronization routine as well as every gRPC <del> method. Connected container runtimes like CRI-O and containerd can link the traces to their exported spans to provide additional context of information. </del> <ins> method. The kubelet propagates trace context with gRPC requests so that container runtimes with trace instrumentation, such as CRI-O and containerd, can associate their exported spans with the trace context from the kubelet. The resulting traces will have parent-child links between kubelet and container runtime spans, providing helpful context when debugging node issues. </ins> Please note that exporting spans always comes with a small performance overhead on the networking and CPU side, depending on the overall configuration of the

Discussion:
This sentence is unclear because of the word "link", which calls into question the early notion of data flows between the Kubernetes components, container runtime and OpenTelemetry collector. You're trying to rethink how data flows and where traces might be linked. Connected [to kubelet?] container runtimes like CRI-O and containerd can link [how?] the traces [traces from Kubernetes?] to their exported spans [exported to whom?] to provide additional context of information. Does this mean that if tracing is enabled for kubelet, it forces the container runtime to send its traces to kubelet? But how can a container runtime link its traces with external traces without receiving them, since kubelet is the initiator, not the container runtime? Or are the kubelet and container traces independently sent to the trace backend (using collectors) where they can be linked somehow? So many assumptions, please add clarification. UPDATE: I was wrong about the initiator, according to I think a container runtime might be it.
/language en
/sig-docs /area docs /retitle Unclear documentation on system traces
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig-docs /area docs /retitle Unclear documentation on system traces 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
Re-titling can only be requested by trusted users, like repository collaborators. <detailsIn response to : /sig-docs /area docs /retitle Unclear documentation on system traces 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
/sig docs
/retitle Unclear documentation about trace linking between Kubernetes components, container runtime and OpenTelemetry collector
/sig node /sig instrumentation
/priority backlog /triage accepted If this rots out, I recommend not removing the staleness marker. We may not have enough volunteers to cover every improvement. Help is, of course, very welcome!
/triage accepted /assign