jiebi/CodeConvo huggingface dataset:
Code change:
<ins> --- title: "后续内容" description: "安装 kubectl 之后，还可以做些什么？" headless: true --- <!-- --- title: "What's next?" description: "What's next after installing kubectl." headless: true --- --> <!-- * [Install Minikube](https://minikube.sigs.k8s.io/docs/start/) * See the [getting started guides](/docs/setup/) for more about creating clusters. * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) --> * [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/) * 有关创建集群的更多信息，请参阅[入门指南](/zh/docs/setup/). * [学习如何启动并对外公开你的应用程序。](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) * 如果你需要访问其他人创建的集群，请参阅 [共享集群接入文档](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * 阅读 [kubectl 参考文档](/zh/docs/reference/kubectl/kubectl/) </ins>

Related discussion:
text: This is a Feature Request translate content/docs/tasks/tools/install-kubectl- into Chinese What would you like to be content/zh/docs/tasks/tools/install-kubectl- /assign /language zh
/triage accepted
Code change:
| | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | | `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | | `Directory` | 주어진 경로에 디렉터리가 있어야 함 | <del> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | </del> <ins> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 파일을 생성한다. | </ins> | `File` | 주어진 경로에 파일이 있어야 함 | | `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | | `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 |

Related discussion:
text: This is a Bug Report Problem: There is incorrectly translated content in docs/concepts/storage/volumes/#hostpath . in English: in Korean: Proposed Solution: Page to Update:
/kind bug /language ko
/triage accepted
Code change:
<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress </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
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. 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:
--- <del> title: v1.19 릴리스 노트 </del> <ins> title: v1.20 릴리스 노트 </ins> weight: 10 card: name: release-notes

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: 1 file changed, 1656 insertions(+), 2119 deletions(-) for Korean is outdated. Proposed Solution: Update according to 1 file changed, 1656 insertions(+), 2119 deletions(-) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
Parent issue :
/milestone dev-1.20-ko.1
/triage accepted
Code change:
drain the node on which the `zk-0` Pod is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data </del> <ins> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data </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: Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. Proposed Solution: Update to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/sig cluster-lifecycle
cc
i see the discussion / PR here: using in the kubeadm docs makes sense. /triage accepted /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 : Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. /help </details
/assign
Code change:
The output of a successful command is: <del> deployment.apps/dns-autoscaler created </del> <ins> deployment.apps/kube-dns-autoscaler created </ins> DNS horizontal autoscaling is now enabled. ## Tune DNS autoscaling parameters {#tuning-autoscaling-parameters} <del> Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </del> <ins> Verify that the kube-dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </ins> ```shell kubectl get configmap --namespace=kube-system

Related discussion:
text: dns-horizontal- kube-dns-autoscaler dns-autoscaler 2
/language zh
please describe the issue in English
page related to the issue:
/triage needs-information
Translate to English: The kube-dns-autoscaler used in dns-horizontal- and the dns-autoscaler used in subsequent commands are confused and out of sync. It seems that the English version also has this problem. /triage accepted /kind bug /retitle Inconsistent name in the DNS horizontal autoscaling example
/language en
/assign
Code change:
SystemdCgroup = true ``` <ins> If you apply this change make sure to restart containerd again: ```shell sudo systemctl restart containerd ``` </ins> When using kubeadm, manually configure the [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).

Related discussion:
text: 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 The documentation for container runtimes at: needs to have a clear warning that by adding the suggested change in , this will actually PREVENT from successfully initializing a cluster (this is my experience multiple times with K8s 1.20.4 on Ubuntu 20.04 with containerd - not Docker). Why is this needed The current wording does not indicate that the suggested change for containerd's will actually break things. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --It is not clear even why that suggestion is there given that it stops from working.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The current text reads: How would you reword this How about: When using kubeadm, you must manually configure the cgroup driver for kubelet. /language en /priority awaiting-more-evidence /sig cluster-lifecycle
Thank you for all the work that you do, related to Kubernetes and all other open source projects you contribute to. Your efforts are really appreciated. My own experience is that the configuration snippet there is actually harmful in the scope of using kubeadm. I realize now that the page is discussing how to use containerd with the systemd cgroup driver in general... but the typical person coming to the "" documentation is there to learn how to use containerd in the context of kubernetes. That makes that configuration snippet a bit out of place since it will actually prevent the usage of kubeadm. For this reason, I believe it is better to be crystal clear and explicitly mention all of that. "To use the systemd cgroup driver... [plugins... ... SystemdCgroup = true However, when using kubeadm to initialize the cluster, the above configuration should NOT be done (it will actually prevent kubelet from bringing up static pods).
Code change:
SystemdCgroup = true ``` <ins> If you apply this change make sure to restart containerd again: ```shell sudo systemctl restart containerd ``` </ins> When using kubeadm, manually configure the [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).

Related discussion:
text: Instead, manually configure the cgroup driver for kubelet."
i don't see anything invalid on the page, but ideas for clarification are welcome. When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager ... ^ the above already explains when the systemd driver is needed. it is the opposite. if you are using kubeadm, you must configure containerd with . and then pass the same driver to the kubelet as explained here: cgroup drivers have been confusing users for a long time and this is really a problem in the CRI spec. there is a plan to automatically handle them but this might take a while to complete.
this area of the docs is seeing some refactor, so you can add comments here too:
This is the source of our difference:. I have tried that setting multiple times (at least 4 times). It does NOT work for me on Ubuntu 20.04. When I do NOT specify that setting in containerd's , then and ONLY THEN does it work... for me.
i just tried following our documentation for installing containerd / installing kubeadm / creating kubeadm cluster. everything works fine for me: also a number of different CI setups are running kubeadm like so, you must be failing something in your setup. i doubt this is a containerd / OS bug of sorts, but it could be. /kind support
did you restart containerd after you : the step here should be after the driver is changed, so that's a documentation problem:
opened PR for this: (it also closes this issue)
Code change:
<ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress spec: podSelector: {} egress: - {} policyTypes: - Egress </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
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. 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:
The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is defined by the states or phases of a Pod. There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. A high-level description of the Pod state is summarized in the [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` field. --> [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod <del> 处于哪个阶段的概述。包含了下面 5 种可能的阶段: Running、Pending、Succeeded、 </del> <ins> 处于哪个阶段的概述。包含了下面 5 种可能的阶段：Running、Pending、Succeeded、 </ins> Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。

Related discussion:
text: Hello, I noticed some punctuation errors on page /language zh
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
Code change:
[authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. <ins> The API credentials are automatically revoked when the Pod is deleted, even if finalizers are in place. In particular, the API credentials are revoked 60 seconds beyond the `.metadata.deletionTimestamp` set on the Pod (the deletion timestamp is typically the time that the **delete** request was accepted plus the Pod's termination grace period). </ins> ### Opt out of API credential automounting If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}

Related discussion:
text: This is a Bug Report The doc about finalizers doesn't give any information about the fact that the API server considers a deleted service account or a deleted pod's token invalid after 1 minute the DeletionTimestamp. ref: <!--Required Information--Problem: Proposed Solution: Document with a note. 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
/sig apps
Code change:
<ins> --- title: Cluster id: cluster date: 2020-08-03 full_link: short_description: > Um conjunto de servidores de processamento, também chamados de nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node). aka: tags: - fundamental - operation --- Um conjunto de servidores de processamento, chamados {{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (_worker node_). <!--more--> O servidor de processamento hospeda os {{< glossary_tooltip text="Pods" term_id="pod" >}} que são componentes de uma aplicação. O {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}} gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, o ambiente de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa em múltiplos nós (_nodes_) , provendo tolerância a falhas e alta disponibilidade. </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: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
Code change:
* Cloning support is only available for dynamic provisioners. * CSI drivers may or may not have implemented the volume cloning functionality. * You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace). <del> * Cloning is only supported within the same Storage Class. - Destination volume must be the same storage class as the source - Default storage class can be used and storageClassName omitted in the spec </del> <ins> * Cloning is supported with a different Storage Class. - Destination volume can be the same or a different storage class as the source. - Default storage class can be used and storageClassName omitted in the spec. </ins> * Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)

Related discussion:
text: Cloning is only supported within the same Storage Class. Cloning has supported different storage class
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
Hello It sounds like you might want to report that a web page is wrong. If that's right, what's the URL of the webpage? Also, could you quote or point out the text in that page that isn't right? /language en /triage needs-information
/sig storage
Hi i would like to explain this issue if i am not wrong wants to update this . As is merged so now users will be able to clone a volume with a different Storage Class. The destination volume no longer has to be the same storage class as the source. But in current documentation we have the behaviour as. Cloning is only supported within the same Storage Class. Destination volume must be the same storage class as the source
I would like to work on this. /assign
Sorry my bad.. Thanks for pointing it.
/remove-triage needs-information
Code change:
</td> </tr> <tr><td><code>requestKind</code><br/> <del> <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.27/#groupversionkind-v1-meta"><code>meta/v1.GroupVersionKind</code></a> </del> <ins> <a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#GroupVersionKind"><code>meta/v1.GroupVersionKind</code></a> </ins> </td> <td> <p>RequestKind is the fully-qualified type of the original API request (for example, v1.Pod or autoscaling.v1.Scale).

Related discussion:
text: Several of the types used in AdmissionRequest does not seem to be documented anywhere. The links point to the general Kubernetes API docs, but the actual types does not seem to be defined there. Searching in the docs does not turn up any obvious references, and neither does web searches. Types missing documentation:
/sig docs /language en
Yes, no documentation for and But for , it should be . The doc is here:
/triage accepted /assign
Code change:
Finally if everything goes well, remove Docker. <del> {{< tabs name="tab-remove-docker-enigine" >}} </del> <ins> {{< tabs name="tab-remove-docker-engine" >}} </ins> {{% tab name="CentOS" %}} ```shell

Related discussion:
text: As part of "Remove Docker Engine", this page should probably also tell the user that may want to clean up space was consumed by docker, e.g. . Otherwise, potentially much space is left used but unmanaged on the node.
Sounds good. We could link to and similar page fragments; if we do, we should caution people that Docker's advice has a risk of trampling on containerd. Ideally, we provide just links to third party docs here. However, neither Docker Engine nor containerd has docs for migrating from one thing to the other (let alone any Kubernetes-specific considerations). I'm happy to treat that as a valid exception from the usual .
/sig node /triage accepted /language en /priority backlog
/assign
Code change:
metadata: name: myapp-pod labels: <del> app: myapp </del> <ins> app.kubernetes.io/name: MyApp </ins> spec: containers: - name: myapp-container

Related discussion:
text: 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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. 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
Code change:
- [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する - Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する <ins> KubernetesのコントロールプレーンでもSecretsは使われています。例えば、[bootstrap token Secrets](#bootstrap-token-secrets)は、ノード登録を自動化するための仕組みです。 </ins> Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。

Related discussion:
text: 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. --About Some corrections need to be made. Why is this needed JSON in .dockerconfigjson dump is strange. Lack of options for kubectl command. And some more correction is needed. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten because the related PR is under reviewing /triage accepted