jiebi/CodeConvo huggingface dataset:
Change:
## Clean up <del> Run `kind delete cluster --name psa-ns-level` to delete the cluster created. </del> <ins> Now delete the cluster which you created above by running the following command: ```shell kind delete cluster --name psa-ns-level ``` </ins> ## {{% heading "whatsnext" %}}

Discussion:
This is a Feature Request What would you like to be Add the commands which are under the Clean up section of the and tutorials into the shell code block snippet. Currently, it is under the triple backticks () as shown in the following screenshot: ! ! Which is not look more prominent. Why is this needed It provides a better structure to the section. and then it will be highlighted on the page. Comments None
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
/sig docs /language en
/assign
Fixed it here:
I'm not sure I agree with the issue description. I was nevertheless happy to merge the actual PR.
thank you, I opened this for the content so that commands under Cleanup should more clear like others command mentioned on the page.
Change:
スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。 <del> 1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための_Predicates_とスコアリングのための_Priorities_の設定することができます。 </del> <ins> 1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。 </ins> 1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。

Discussion:
ref: ! [x] [x] [x] [ ] content/ja/docs/concepts/configuration/manage-resources- [ ] [x] content/ja/docs/concepts/configuration/pod-priority- [x] [x] [ ] content/ja/docs/concepts/containers/runtime- [x] content/ja/docs/concepts/overview/kubernetes- [x] content/ja/docs/concepts/extend-kubernetes/api-extension/custom- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with-objects/common- [x] content/ja/docs/concepts/overview/working-with-objects/field- [x] content/ja/docs/concepts/overview/working-with- [x] content/ja/docs/concepts/overview/working-with- [ ] content/ja/docs/concepts/scheduling-eviction/assign-pod- [ ] content/ja/docs/concepts/scheduling-eviction/kube- [x] content/ja/docs/concepts/scheduling-eviction/taint-and- [x] [x] content/ja/docs/concepts/security/pod-security- [x] content/ja/docs/concepts/services- [x] content/ja/docs/concepts/storage/persistent- [x] [x] content/ja/docs/concepts/workloads/controllers/cron- [x] [x] [x] [x] content/ja/docs/concepts/workloads/pods/pod- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/reference/access-authn- [x] content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster- [x] content/ja/docs/setup/production-environment/tools/kubeadm/troubleshooting- [ ] content/ja/docs/tasks/access-application-cluster/web-ui- [x] content/ja/docs/tasks/debug-application-cluster/get-shell-running- [x] content/ja/docs/tasks/run-application/horizontal-pod-autoscale- [x] content/ja/docs/tasks/run-application/run-single-instance-stateful- [x] content/ja/docs/tutorials/stateful-application/basic-stateful- [x] content/ja/docs/tutorials/stateful- (grep) /language ja
/triage accepted
/assign
/kind bug
I'm facing same issue lol :smiley: Feel free to mention me for review if create PRs for this.
Change:
in the CSR but also verifies the requested IPs and domain names. This would prevent a malicious actor that has access to a kubelet client certificate to create CSRs requesting serving certificates for any IP or domain name. <ins> ## Generating kubeconfig files for additional users {#kubeconfig-additional-users} During cluster creation, kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`. [`system:masters`](/docs/reference/access-authn-authz/rbac/#user-facing-roles) is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). Sharing the `admin.conf` with additional users is **not recommended**! Instead, you can use the [`kubeadm kubeconfig user`](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig) command to generate kubeconfig files for additional users. The command accepts a mixture of command line flags and [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) options. The generated kubeconfig will be written to stdout and can be piped to a file using `kubeadm kubeconfig user ... > somefile.conf`. Example configuration file that can be used with `--config`: ```yaml # example.yaml apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration # Will be used as the target "cluster" in the kubeconfig clusterName: "kubernetes" # Will be used as the "server" (IP or DNS name) of this cluster in the kubeconfig controlPlaneEndpoint: "some-dns-address:6443" # The cluster CA key and certificate will be loaded from this local directory certificatesDir: "/etc/kubernetes/pki" ``` Make sure that these settings match the desired target cluster settings. To see the settings of an existing cluster use: ```shell kubectl get cm kubeadm-config -n kube-system -o=jsonpath="{.data.ClusterConfiguration}" ``` The following example will generate a kubeconfig file with credentials valid for 24 hours for a new user `johndoe` that is part of the `appdevs` group: ```shell kubeadm kubeconfig user --config example.yaml --org appdevs --client-name johndoe --validity-period 24h ``` The following example will generate a kubeconfig file with administrator credentials valid for 1 week: ```shell kubeadm kubeconfig user --config example.yaml --client-name admin --validity-period 168h ``` </ins>

Discussion:
The command only has Cobra (CLI) documentation and there are no pointers on what fields are relevant in the configuration passed with --config to it: Add a minimal example + config for the command usage on this page: /sig cluster-lifecycle /kind feature xref
/triage accepted
/language en
Change:
<!-- 1. Choose a directory, say `/etc/kubernetes/manifests` and place a web server Pod definition there, for example `/etc/kubernetes/manifests/static-web.yaml`: <ins> # Run this command on the node where kubelet is running </ins> --> 2. 选择一个目录，比如在 `/etc/kubernetes/manifests` 目录来保存 Web 服务 Pod 的定义文件，例如 `/etc/kubernetes/manifests/static-web.yaml`： <del> <!-- # Run this command on the node where kubelet is running --> </del> ```shell # 在 kubelet 运行的节点上执行以下命令 mkdir -p /etc/kubernetes/manifests/

Discussion:
There is something wrong with this format
Please mention issue title and description in Primary (English) language.
/triage needs-information
Page:
chinese
/language zh Yes, there is a format issue in Chinese translation page under metadata and spec secession. English website content is having accurate format. I think we should sync this page with English translation.
/kind bug Below is the correct format:
/remove-triage needs-information /assign
/retitle [zh] Incorrect YAML format in example in "Create static Pods" page
/triage accepted
Seems there are some other changes also present in page. better someone who knows zh language can pick this issue to resolve. /unassign
/assign
Change:
content_type: concept weight: 30 --- <!-- reviewers: - pweil-

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: page garbled. ! /language zh
I suddenly saw this page showing garbled characters today. Can you take a look?
Looking into this.
raised a PR for diagnosis looks like the cached version of the HTML is corrupted. It is not treated as HTML media type. Dummy PR for this:
/triage accepted
Change:
<!-- image source for flowchart: https://docs.google.com/drawings/d/1sdviU6lDz4BpnzJNHfNpQrqI9F19QZ07KnhnxVrp2yg/edit --> <del> {{< figure src="/docs/concepts/extend-kubernetes/flowchart.png" </del> <ins> {{< figure src="/docs/concepts/extend-kubernetes/flowchart.svg" </ins> alt="Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no." class="diagram-large" caption="Flowchart guide to select an extension approach" >}}

Discussion:
In the "Extension point choice flowchart", answering yes to the first questions leads to: Go the "Adding APIs" Section" There's a grammar error and a punctuation error, but major problem is that there is no such section on that page. It should read: Go to "API extensions"
Page related issue /language en /sig docs
This issue is talking about the first section of this diagram at given page ! /kind feature
Thank you for your reply but basically this approach is not the good practice The issue has been defined by the and the link to redirect to that page is not been provided so it has been provided by and you are giving the screenshot of that issue means it does not looks good. Requesting you for the good approach. Its asking like the issue is denoted by the description and then by link and then by image.
When i saw this issue, it was having relevant explanation, and link of the page by niranjan but i felt an image is missing to understand the issue better like - where this "Go the adding API server is written" in whole page and where we need to make change. So, i just one image. Generally, i don't put pic of an issue like this. When i approach an issue i first try to understand it, then verify it then label it and then try to discuss about its causes and possible solutions in proper way that won't look odd to anyone. But here forgive me if this looked odd to you, thank you for your feedback. Now i will take care even more.
/priority backlog /triage accepted For more tips about diagram improvements, see
/retitle Wrong wording in diagram at
Hi! I think I'll be able to solve this one. Also, I think this diagram's made using instead of I should remake it using the same tool, right? /assign
Using is fine It'd be nice to also use Kubernetes colors - maybe a second PR?
That sounds good! Sure, I can create a second PR after this one. And just to clarify, should I open a new issue for it, or can I proceed directly with the pull request? I'm a new contributor to the Kubernetes project :)
You can proceed directly with a PR, no need to raise a new issue for it.
Change:
Check your pods' IPs: ```shell <del> kubectl get pods -l run=my-nginx -o yaml | grep podIP podIP: 10.244.3.4 podIP: 10.244.2.5 </del> <ins> kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs POD_IP [map[ip:10.244.3.4]] [map[ip:10.244.2.5]] </ins> ``` You should be able to ssh into any node in your cluster and use a tool such as `curl` to make queries against both IPs. Note that the containers are *not* using port 80 on the node, nor are there any special NAT rules to route traffic to the pod. This means you can run multiple nginx pods on the same node all using the same `containerPort`, and access them from any other pod or node in your cluster using the assigned IP address for the Service. If you want to arrange for a specific port on the host Node to be forwarded to backing Pods, you can - but the networking model should mean that you do not need to do so.

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 section tells to run the following command: kubectl get pods -l run=my-nginx -o yaml | grep podIP When I run this command, I get the following output: % kubectl get pods -l run=my-nginx -o yaml | grep podIP f:podIP: {} f:podIPs: podIP: 172.17.0.6 podIPs: f:podIP: {} f:podIPs: podIP: 172.17.0.7 podIPs: Proposed Solution: I'd use -custom-columns rather than grep to obtain the pods IP: kubectl get pods -l run=my-nginx -o custom- 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
/assign
Change:
<ins> --- title: CIDR id: cidr date: 2019-11-12 full_link: short_description: > CIDRは、IPアドレスの範囲を記述するための表記法であり、さまざまなネットワークを構成するために使用されています。 aka: tags: - networking --- CIDR(Classless Inter-Domain Routing)はIPアドレスの範囲を記述するための表記法であり、さまざまなネットワークを構成するために使用されています。 <!--more--> Kubernetesでは、各{{< glossary_tooltip text="Node" term_id="node" >}}に対して、CIDRで記述されている開始アドレスとサブネットマスクを通してIPアドレスの範囲が割り当てられます。これにより、Nodeは各{{< glossary_tooltip text="Pod" term_id="pod" >}}に一意のIPアドレスを割り当てることができます。CIDRはもともとIPv4の概念でしたが、IPv6もサポートされるように拡張されています。 </ins>

Discussion:
This is a Feature Request What would you like to be Translate into Japanese Why is this needed There is no Japanese translation for this page Comments File to translate: Original: Japanese Localization document:
/area localization /language ja /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 : /area localization /language ja /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
/triage accepted
/assign
Change:
these Pod Security Standards: ```shell <del> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml </del> <ins> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml </ins> ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️

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: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign
Change:
### Security <del> Enabling the GenericEphemeralVolume feature allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </del> <ins> Using generic ephemeral volumes allows users to create PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they should use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) </ins> that rejects objects like Pods that have a generic ephemeral volume. The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota)

Discussion:
It is quite unclear from that the feature "GenericEphemeralVolume" is a feature gate because its design does not follow the guideline. The following steps should be done: write the feature gate name as inline code, e.g. change the wording from "feature" to "feature gate" Also there is no information about the components on which this feature gate can be enabled. But! This feature gate is only in . Looks like it's not a feature gate now. Consider removing it from the page.
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
/retitle "Ephemeral Volumes" page references the usage of a deprecated feature gate
/sig storage
feature gate has been removed in , the text needs to be updated.
/assign
Change:
--- title: 使用命令式的方式管理 Kubernetes 对象 <del> redirect_from: - "/docs/concepts/tools/kubectl/object-management-using-imperative-commands/" - "/docs/concepts/tools/kubectl/object-management-using-imperative-commands.html" </del> --- {% capture overview %}

Discussion:
This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This link: redirects to this page: The link is found here: Proposed Solution: Fix the redirect for /docs/user-guide/working-with-resources Page to Update: Redirect for
Yeah, it's confusing. Why it's P3? How hard to fix it? How I can help?
I know what the problem is and will submit a PR shortly. None of the pages in the /cn directory should have the directive at the top of the page. For example, currently, /cn/docs/tutorials/object-management-kubectl/object- has this set at the top of the page:
Wow! Thank you!!
Ok, nothing should be redirected to the /cn pages anymore. Cheers
Change:
更改 `/var/lib/kubelet/config.conf` 或 `/var/lib/kubelet/kubeadm-flags.env` 后需要重启 kubelet。 <del> {{% heading "whatsnext" %}} </del> <ins> ## {{% heading "whatsnext" %}} </ins> <!-- - [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) - [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags) - [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) <ins> - [Find more about kubeadm set-up](/docs/reference/setup-tools/kubeadm/) </ins> --> - [升级 kubeadm 集群](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) - [使用 kubeadm API 自定义组件](/zh-cn/docs/setup/production-environment/tools/kubeadm/control-plane-flags) <del> - [使用 kubeadm 管理证书](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) </del>  No newline at end of file <ins> - [使用 kubeadm 管理证书](/zh-cn/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) - [进一步了解 kubeadm 设置](/zh-cn/docs/reference/setup-tools/kubeadm/) </ins>

Discussion:
Path: content/zh cn/docs/tasks/administrator cluster/kubeadm/kubeadm
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
In the submission, the English document was updated, but the Chinese document was not updated
/language zh
/assign
I want to synchronize this update to content/zh cn/docs/tasks/administrator cluster/kubeadm/kubeadm and translate it
/kind document
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind document 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
/remove-kind bug
Change:
However, if the Pod has a `restartPolicy` of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed. --> 如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 <del> 然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，Kubernetes 不会重新启动 Pod。 </del> <ins> 然而，如果 Pod 对应的 `restartPolicy` 值为 "Never"，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。 </ins> <!-- To specify an init container for a Pod, add the `initContainers` field into

Discussion:
If a Pod's init container fails, the kubelet repeatedly restarts that init container until it succeeds. However, if the Pod has a restartPolicy of Never, and an init container fails during startup of that Pod, Kubernetes treats the overall Pod as failed. Pod Init kubelet Init Pod restartPolicy "Never"Kubernetes Pod “restartPolicy” podPodKuneletPodFailedInit container
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
/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
/language chinese
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language chinese 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
/assign