jiebi/CodeConvo huggingface dataset:
Change:
Doc link: ` I think it's more understandable by adding to this command the docker server (registry) Current version: kubectl create secret docker-registry secret-tiger-docker --docker-username=tiger --docker-password=pass113 --docker- New version: kubectl create secret docker-registry secret-tiger-docker --docker-username=tiger --docker-password=pass113 --docker- --docker-server=my-registry:5000
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 storage
/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]:
/remove-lifecycle stale

Discussion:
kubectl create secret docker-registry secret-tiger-docker  --docker-username=tiger  --docker-password=pass113  <del> --docker-email=tiger@acme.com </del> <ins> --docker-email=tiger@acme.com  --docker-server=my-registry.example:5000 </ins> ``` This command creates a Secret of type `kubernetes.io/dockerconfigjson`.

```json { <del> "auths": { "https://index.docker.io/v1/": { "username": "tiger", "password": "pass113", "email": "tiger@acme.com", "auth": "dGlnZXI6cGFzczExMw==" } } </del> <ins> "apiVersion": "v1", "data": { ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ==" }, "kind": "Secret", "metadata": { "creationTimestamp": "2021-07-01T07:30:59Z", "name": "secret-tiger-docker", "namespace": "default", "resourceVersion": "566718", "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca" }, "type": "kubernetes.io/dockerconfigjson" </ins> } ``` ### Basic authentication Secret
Change:
Install containerd with powershell do not work with .Install-Containerd.ps1 -ContainerDVersion v1.4.1. The download url is ''. So ".Install-Containerd.ps1 -ContainerDVersion 1.4.1." will work the command.
I think this might be a bug in rather than in the Kubernetes documentation. If so, you could report this via
/triage accepted /assign /sig windows
See

Discussion:
```powershell # Example <del> .Install-Containerd.ps1 -ContainerDVersion v1.4.1 </del> <ins> .Install-Containerd.ps1 -ContainerDVersion 1.4.1 </ins> ``` {{< /note >}}
Change:
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 documentation on Pod Topology Spread Constraints indicates: Proposed Solution: The documentation should read This feature went default-on when it hit Beta in 1.18 per the [Feature Gate Reference] () Page to Update:
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

Discussion:
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization. {{< note >}} <del> In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread` </del> <ins> In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread` </ins> [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/concepts/overview/components/#kube-apiserver) and the [scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod
Change:
In kubernetes documentation page: There is an obsolete link to addon Flannel - (v1.15-16) The latest documentation is in main README -- (v1.17+)
/retitle Installing Addons has outdated link to Flannel network plugin /kind cleanup /language en /triage accepted /good-first-issue I agree with the fix that suggests
This request has been marked as suitable for new contributors. 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 : /retitle Installing Addons has outdated link to Flannel network plugin /kind cleanup /language en /triage accepted /good-first-issue </details
/assign

Discussion:
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. * [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. <del> * [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. </del> <ins> * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes. </ins> * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
Change:
This is a Feature Request translate /docs/concepts/scheduling-eviction/api- into Chinese What would you like to be /zh/docs/concepts/scheduling-eviction/api- /language zh /assign
/triage accepted

Discussion:
<ins> --- title: API 发起的驱逐 content_type: concept weight: 70 --- <!-- --- title: API-initiated Eviction content_type: concept weight: 70 --- --> {{< glossary_definition term_id="api-eviction" length="short" >}} </br> <!-- You can request eviction by directly calling the Eviction API using a client of the kube-apiserver, like the `kubectl drain` command. This creates an `Eviction` object, which causes the API server to terminate the Pod. API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). --> 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。 API 发起的驱逐将遵从你的 [`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) 和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) 配置。 ## {{% heading "whatsnext" %}} <!-- * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) --> * 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/) * 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) </ins>

<ins> --- title: API 发起的驱逐 id: api-eviction date: 2021-04-27 full_link: /zh/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction short_description: > API 发起的驱逐是一个先调用 Eviction API 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 aka: tags: - operation --- <!-- --- title: API-initiated eviction id: api-eviction date: 2021-04-27 full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction short_description: > API-initiated eviction is the process by which you use the Eviction API to create an Eviction object that triggers graceful pod termination. aka: tags: - operation --- --> <!-- API-initiated eviction is the process by which you use the [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/#create-eviction-pod-v1-core) to create an `Eviction` object that triggers graceful pod termination. --> API 发起的驱逐是一个先调用 [Eviction API](/docs/reference/generated/kubernetes-api/{{<param "version">}}/create-eviction-pod-v1-core) 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 <!--more--> <!-- You can request eviction either by directly calling the Eviction API using a client of the kube-apiserver, like the `kubectl drain` command. When an `Eviction` object is created, the API server terminates the Pod. API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction). --> 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 当 `Eviction` 对象创建出来之后，该对象将驱动 API 服务器终止选定的Pod。 API 发起的驱逐不同于 [节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 </ins>
Change:
WordPress wordpress wordpress-abcxzy
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh
/assign

Discussion:
应用可以在 Kubernetes 集群中安装一次或多次。在某些情况下，可以安装在同一命名空间中。例如，可以不止一次地为不同的站点安装不同的 WordPress。 <del> 应用的名称和实例的名称是分别记录的。例如，某 WordPress 实例的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称表现为 `app.kubernetes.io/instance` 的属性值 `wordpress-abcxzy`。这使应用程序和应用程序的实例成为可能是可识别的。应用程序的每个实例都必须具有唯一的名称。 </del> <ins> 应用的名称和实例的名称是分别记录的。例如，WordPress 应用的 `app.kubernetes.io/name` 为 `wordpress`，而其实例名称 `app.kubernetes.io/instance` 为 `wordpress-abcxzy`。 这使得应用和应用的实例均可被识别，应用的每个实例都必须具有唯一的名称。 </ins> <!-- ## Examples
Change:
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

Discussion:
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
Change:
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 reference/glossary/cloud-controller- is wrong Proposed Solution: In , In : In : and so on... Page to Update: [No webpage should be affected by the changes which this issue is suggesting.] <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh
/triage accepted /language zh /kind bug /assign

Discussion:
title: 云控制器管理器（Cloud Controller Manager） id: cloud-controller-manager date: 2018-04-12 <del> full_link: /zh/docs/tasks/administer-cluster/running-cloud-controller/ </del> <ins> full_link: /zh/docs/concepts/architecture/cloud-controller/ </ins> short_description: > <del> 云控制器管理器是 1.8 的 alpha 特性。在未来发布的版本中，这是将 Kubernetes 与任何其他云集成的最佳方式。 </del> <ins> 将 Kubernetes 与第三方云提供商进行集成的控制面组件。 </ins> aka: tags:

- architecture - operation --- <!-- <del> --- </del> title: Cloud Controller Manager id: cloud-controller-manager date: 2018-04-12 full_link: /docs/concepts/architecture/cloud-controller/ short_description: > <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Control plane component that integrates Kubernetes with third-party cloud providers. </ins> aka: tags: - core-object - architecture - operation <del> --- </del> --> <!-- A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster. --> 云控制器管理器是指嵌入特定云的控制逻辑的 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。 <del> 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。 </del> <ins> 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 </ins> <!--more-->

features at a different pace compared to the main Kubernetes project. --> 通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑， <del> 云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的速度进行发布新特征。 </del>  No newline at end of file <ins> 云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的 步调发布新特征。 </ins>
Change:
! ! There is a problem with the Chinese version translated here, it should be in the "development" namespace.
/triage accepted /kind bug /assign
/language zh

Discussion:
```yaml apiVersion: rbac.authorization.k8s.io/v1 <del> # 此角色绑定使得用户 "dave" 能够读取 "default" 名字空间中的 Secrets </del> <ins> # 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets </ins> # 你需要一个名为 "secret-reader" 的 ClusterRole kind: RoleBinding metadata: name: read-secrets # RoleBinding 的名字空间决定了访问权限的授予范围。 <del> # 这里仅授权在 "development" 名字空间内的访问权限。 </del> <ins> # 这里隐含授权仅在 "development" 名字空间内的访问权限。 </ins> namespace: development subjects: - kind: User

1. A binding to a different role is a fundamentally different binding. Requiring a binding to be deleted/recreated in order to change the `roleRef` ensures the full list of subjects in the binding is intended to be granted <del> the new role (as opposed to enabling accidentally modifying just the roleRef </del> <ins> the new role (as opposed to enabling or accidentally modifying only the roleRef </ins> without verifying all of the existing subjects should be given the new role's permissions). 2. Making `roleRef` immutable allows giving `update` permission on an existing binding object to a user, which lets them manage the list of subjects, without being able to change the role that is granted to those subjects. --> 1. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`, <del> 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许修改 `roleRef` 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。 </del> <ins> 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改 了 `roleRef` 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。 </ins> 1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限， 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。

or aggregated API servers, to extend the default roles. For example: the following ClusterRoles let the "admin" and "edit" default roles manage the custom resource <del> named CronTab, whereas the "view" role can perform just read actions on CronTab resources. </del> <ins> named CronTab, whereas the "view" role can perform only read actions on CronTab resources. </ins> You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server. --> 默认的[面向用户的角色](#default-roles-and-role-bindings) 使用 ClusterRole 聚合。
Change:
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 should use a glossary tooltip for “affinity” Why is this needed Kubernetes uses the term “affinity” to mean a specific thing. A tooltip (and the hyperlink it implies) helps a reader learn more about this term if they are not sure. Comments /language en
/triage accepted
Hey, I will like to work on this !! Please let me know how can I proceed with this !! !!
/assign

Discussion:
the Node is not considered for preemption. {{< /note >}} <del> If a pending Pod has inter-pod affinity to one or more of the lower-priority Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence of those lower-priority Pods. In this case, the scheduler does not preempt any Pods on the Node. Instead, it looks for another Node. The scheduler might find a suitable Node or it might not. There is no guarantee that the pending Pod can be scheduled. </del> <ins> If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}} to one or more of the lower-priority Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence of those lower-priority Pods. In this case, the scheduler does not preempt any Pods on the Node. Instead, it looks for another Node. The scheduler might find a suitable Node or it might not. There is no guarantee that the pending Pod can be scheduled. </ins> Our recommended solution for this problem is to create inter-Pod affinity only towards equal or higher priority Pods.

<ins> --- title: Affinity id: affinity date: 2019-01-11 full_link: /docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity short_description: > Rules used by the scheduler to determine where to place pods aka: tags: - fundamental --- In Kubernetes, _affinity_ is a set of rules that give hints to the scheduler about where to place pods. <!--more--> There are two kinds of affinity: * [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) * [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) The rules are defined using the Kubernetes {{< glossary_tooltip term_id="label" text="labels">}}, and {{< glossary_tooltip term_id="selector" text="selectors">}} specified in {{< glossary_tooltip term_id="pod" text="pods" >}}, and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them. </ins>
Change:
Hi, the header url of Privileged mode for containers in Chinese version doc misses a . Best regards.
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
/kind bug /language zh
/assign /retitle [zh] Wrong custom heading ID in zh/docs/concepts/workloads/pods

Discussion:
the [security context](/docs/tasks/configure-pod-container/security-context/) of the container spec. This is useful for containers that want to use operating system administrative capabilities such as manipulating the network stack or accessing hardware devices. Processes within a privileged container get almost the same privileges that are available to processes outside a container. --> <del> ## 容器的特权模式     {#rivileged-mode-for-containers} </del> <ins> ## 容器的特权模式     {#privileged-mode-for-containers} </ins> Pod 中的任何容器都可以使用容器规约中的 [安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
Change:
Hello, I installed Kubernetes using this method "Install kubectl binary with curl on MacOS". In step 5, I get the error "kubectl: command not found". MacOS version: 10.12.6 Could you please give a solution? Regards, Myat
Can you send me the reference document?
/kind support
reference document:
You can run . Check if is in the PATH. !
Let's mention that must be in your . This was a support request, but it's also a hint about how to improve the docs /remove-kind support /language en
/assign
Let me improve it.
/sig node
/remove-sig node
/sig cli
/triage accepted

Discussion:
sudo chown root: /usr/local/bin/kubectl ``` <ins> {{< note >}} Make sure `/usr/local/bin` is in your PATH environment variable. {{< /note >}} </ins> 1. Test to ensure the version you installed is up-to-date: ```bash
Change:
In ; waitForFirstConsumer is spelt. Correct spelling is WaitForFirstConsumer
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
Issue solved with

Discussion:
to see its supported topology keys and examples. {{< note >}} <del> If you choose to use `waitForFirstConsumer`, do not use `nodeName` in the Pod spec </del> <ins> If you choose to use `WaitForFirstConsumer`, do not use `nodeName` in the Pod spec </ins> to specify node affinity. If `nodeName` is used in this case, the scheduler will be bypassed and PVC will remain in `pending` state. Instead, you can use node selector for hostname in this case as shown below.