jiebi/CodeConvo huggingface dataset:
Code change:
쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, 개별 컨테이너들이 DNS 네임을 해석할 때 <del> DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. </del> <ins> DNS 서비스의 IP를 사용하도록 kubelet을 구성한다. </ins> 클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. 기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와

Related discussion:
text: 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 branch after we complete around 3~4 weeks job. PR Freeze: 01/16 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 01/19 (merge to main branch)  2~3 , main . PR : 01/16 ( PR , PR ) : 01/19 (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 is the current work branch for Korean localization.A Korean localization work branch is merged to branch after we complete around 3~4 weeks job. PR Freeze: 01/16 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 01/19 (merge to main branch) PR : 01/16 ( PR , PR ) : 01/19 (main , k8s.io ) /help </details
/milestone dev-1.26-ko.1
/triage accepted
Outdated Korean contents in the dev-1.26-ko.1
Code change:
body.cid-community .community-section.community-frame { <del> width: 100vw; </del> <ins> width: 100%; </ins> } body.cid-community .community-section.community-frame .twittercol1 {

Related discussion:
text: 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: Proposed Solution: Page to Update: /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
During my browsing of the docs on a mobile device, I came across a similar situation on another page, specifically in the . It seems this issue might be widespread and could be affecting multiple pages, not limited to just the community page. Perhaps we could explore identifying a CSS fix that enhances the rendering of pages with wider elements. This way, we can efficiently resolve the problem and improve the overall user experience.
/area web-development
I tried making some changes on the source, A simple overflow - x in the right places seems to solve the problem. ! However, I'd often come across such problems when the scaling isn't managed properly. I'm sure there are better ways to get this problem fixed.
I see, In that case I'll try to find anymore pages that might be having the same issue.
Similar issue is present in case study
Code change:
--- title: コンテンツの構造化 content_type: concept <del> weight: 40 </del> <ins> weight: 90 </ins> --- <!-- overview -->

Related discussion:
text: This is a Feature Request What would you like to be We need to update /content/ja/docs/contribute/style/content- according to the English text, because it is outdated. Why is this needed /content/ja/docs/contribute/style/content- is outdated. In the English page, a note for localication was in . It needs to be to the Japanese page. 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
Related Issue : ,
Code change:
## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:

Related discussion:
text: In section it is said: The CRD can be either namespaced or cluster-scoped, as specified in the CRD's That text is wrong (a CRD object and the custom resource created from that CRD object are not the same). It should better say: The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's field
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
/wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix?
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix? </details
Thanks Yes, I am raising the PR. It is to be the first one I am creating against kubernetes documentation. Anything I should take care of? (thanks in advance ;-)
I found all details in . I am then following it ;-)
/wg api-expression
you've found the right guide. I hope it covers everything you need to know, but if it doesn't then please feel free to ask questions.
I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign /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?
Code change:
## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:

Related discussion:
text: 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 : I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign 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
Saw this good first issue with no one assigned, I could take it up /assign
Thanks a lot for putting hands on this ... and sorry a lot for not having done it myself as initially proposed (I was disconnected for some long time).
Code change:
<ins> apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-nginx spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: access: "true" </ins>

Related discussion:
text: This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
Code change:
[thirdparty_message] other = """Ta sekcja przekierowuje do projektów osób trzecich, które udostępniają funkcjonalność wymaganą przez Kubernetesa. Autory projektu Kubernetes nie są odpowiedzialni za te projekty. Ta strona podąża za <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">wytycznymi CNCF dla stron internetowych</a> aby pokazać projekty w kolejności alfabetycznej. Aby dodać projekt na tę listę przeczytaj <a href="/docs/contribute/style/content-guide/#third-party-content">wytyczne dla zawartości</a> przed wysyłaniem zmian.""" <ins> [thirdparty_message_edit_disclaimer] other="""Zastrzeżenie dotyczące zawartości zewnętrznej""" [thirdparty_message_single_item] other = """&#128711; Ta pozycja przekierowuje do projektu lub produktu osób trzecich, będących poza projektem Kubernetes. <a class="alert-more-info" href="#third-party-content-disclaimer">Więcej informacji</a>""" [thirdparty_message_disclaimer] other = """<p>Niektóre elementy na tej stronie odnoszą się do zewnętrznych produktów lub projektów, które dostarczają funkcjonalności wymagane przez Kubernetesa. Autorzy projektu Kubernetes nie ponoszą odpowiedzialności za te produkty oraz projekty. Zajrzyj na stronę <a href="https://github.com/cncf/foundation/blob/master/website-guidelines.md" target="_blank">CNCF website guidelines</a> po więcej informacji.</p><p>Zapoznaj się także z  <a href="/docs/contribute/style/content-guide/#third-party-content">content guide</a> zanim zaproponujesz zmianę dodającą odnośnik do zewnętrznej strony.</p>""" </ins> [ui_search_placeholder] other = "Szukaj"

Related discussion:
text: What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language pl
/sig docs
/triage accepted
Code change:
body.cid-community .community-section#meetups p:last-of-type { margin-bottom: 6em; /* extra space for background */ } <ins> } @media only screen and (max-width: 767px) { body.cid-community .community-section h2:before, body.cid-community .community-section h2:after { display: none; } </ins> }  No newline at end of file

Related discussion:
text: 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: Proposed Solution: Page to Update: /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
During my browsing of the docs on a mobile device, I came across a similar situation on another page, specifically in the . It seems this issue might be widespread and could be affecting multiple pages, not limited to just the community page. Perhaps we could explore identifying a CSS fix that enhances the rendering of pages with wider elements. This way, we can efficiently resolve the problem and improve the overall user experience.
/area web-development
I tried making some changes on the source, A simple overflow - x in the right places seems to solve the problem. ! However, I'd often come across such problems when the scaling isn't managed properly. I'm sure there are better ways to get this problem fixed.
I see, In that case I'll try to find anymore pages that might be having the same issue.
Similar issue is present in case study
Code change:
$ kubectl attach <podname> -i                             # Attach to Running Container $ kubectl port-forward <podname> <local-and-remote-port>  # Forward port of Pod to your local machine $ kubectl port-forward <servicename> <port>               # Forward port to service <del> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </del> <ins> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </ins> ```

Related discussion:
text: Does not run under as defined in the docs. This is the fix: I think wanted me to do one work on the cheat anyways ... Just leaving this here for now.
Code change:
$ kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell $ kubectl attach my-pod -i                            # Attach to Running Container <del> $ kubectl port-forward my-pod 5000:6000               # Forward port 6000 of Pod to your to 5000 on your local machine </del> <ins> $ kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod </ins> $ kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers

Related discussion:
text: <!-- 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 port-forward command description is misleading. As a user I would expect the command to forward the complete traffic from port 6000 to 5000 locally, not only the data from both ports like the explanation in the detailed command page mentions. Proposed Solution: You could change the description to something like in the detail command description () or change the command to the version it describes. (kubectl port-forward my-pod 5000:6000 -with colon) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Code change:
[release_date_format] other = "2006-01-02" <ins> # Deprecated. Planned for removal in a future release. # Use [release_full_details_initial_text] instead. [release_complete] other = "完整的" # Replace [release_complete] with [release_full_details_initial_text] [release_full_details_initial_text] other = "完整的" [release_schedule] other = "排期表" [release_changelog] other = "变更记录" </ins> [seealso_heading] other = "另请参见"

Related discussion:
text: What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language zh-cn
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /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
/sig-docs
/language zh
/triage accepted /assign
Code change:
<del> You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. </del> <ins> You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. </ins>

Related discussion:
text: 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 are some redirection rules with wildcard(``). Expectation: Netlify redirects to Reality: gives Instead, Netlify redirects (literally) to (literally) Expectation: Netlify redirects to Reality: Netlify redirects to (with trailing slash) which is not a valid anchor URL (because of the trailing slash). Proposed Solution: File 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
I would like to give this a try /assign
how can I test these redirect things after I made the changes? Do I have to make a PR to get the netlify link to test the things?
Are you working on this issue?
Ya I was trying but couldn't figure out how can I test these redirects after making the changes
Thanks, I will unassign myself. Please consider commenting before. It helps others to know about the progress of issue. /unassign
/assign
It was my bad.
I think the problem is with the link itself. Here may be is the splat. Maybe that's why it's unable to redirect. If I change the redirect to something like below without the .md it works fine And for this link , the splat is get/ and hence it redirects to This can be resolve if we remove the trailing slash from this link So, where are all these links present if we want to modify the link itself?
What a great research! I think so.
Code change:
<del> You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. </del> <ins> You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. </ins>

Related discussion:
text: To do tests, you should changes on  file, a PR, and the redirection rules on the deploy preview: https://deploy-preview-xxxxx--kubernetes-io-main- And regarding your research, I suggest to make changes like these: and test on the deploy preview of the PR you will post. I did some searching and found these: content/en/blog/posts/2016-08-00-Kubernetes-Namespaces-Use-Cases- content/en/blog/posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-
I have made the PR. Let me know if I have to do some more changes or anything
Code change:
Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. <del> In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [Deployments](/docs/concepts/workloads/controllers/deployment/)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management. </del> <ins> In general, users shouldn't need to create pods directly. They should almost always use controllers even for singletons, for example, [Deployments](/docs/concepts/workloads/controllers/deployment/)). Controllers provide self-healing with a cluster scope, as well as replication and rollout management. Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) can also provide support to stateful pods. </ins> The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).

Related discussion:
text: This is a... [ ] Feature Request [x] Bug Report Problem: There is a link missing that was supposed to be in section Differences between alpha PetSets and beta StatefulSets under it in the second point StatefulSet guards against split brain which ends with following text TODO: Link to doc about fencing. Change it and add the link that is required. Proposed Solution: Add link which is missing Page to Update:
PetSet has long been replaced by StatefuSet and StatefulSet has been GA'ed in 1.9. So we are going to remove this page to avoid further confusion.