Question: 1. Create `example-ingress.yaml` from the following file: <del> ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 spec: rules: - host: hello-world.info http: paths: - path: / pathType: Prefix backend: service: name: web port: number: 8080 ``` </del> <ins> {{< codenew file="ingress/example-ingress.yaml" >}} </ins> 1. Create the Ingress resource by running the following command: ```shell <del> kubectl apply -f example-ingress.yaml </del> <ins> kubectl apply -f https://k8s.io/examples/ingress/example-ingress.yaml </ins> ``` Output:

This is a Bug Report Problem: it seems that there is wrong indentation example- Proposed Solution: change to: path: / backend: serviceName: web servicePort: 8080 instead of: path: / backend: serviceName: web servicePort: 8080 Page to Update: Additional Information: This is the error thrown: $ kubectl apply -f example- error: error validating "example-": error validating data: [ValidationError([0]): unknown field "backend" in , ValidationError([0][0]): missing required field "backend" in ]; if you choose to ignorethese errors, turn validation off with --validate=false $
Thank you for your submission and have tried to fix it. /kind bug /language en /assign


Question: what that means, check out the blog post [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). <ins> Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does. </ins> ### Why is dockershim being deprecated? Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.

cc: Task docs referencing how to check if dockershim removal affects users to be to the discussions. Link to be : (/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
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 raised per
/sig docs /language en


Question: After you initialize your control-plane, the kubelet runs normally. {{< /note >}} <ins> #### Network setup kubeadm similarly to other Kubernetes components tries to find a usable IP on the network interface associated with the default gateway on a host. Such an IP is then used for the advertising and/or listening performed by a component. To find out what this IP is on a Linux host you can use: ```shell ip route show # Look for a line starting with "default via" ``` Kubernetes components do not accept custom network interface as an option, therefore a custom IP address must be passed as a flag to all components instances that need such a custom configuration. To configure the API server advertise address for control plane nodes created with both `init` and `join`, the flag `--apiserver-advertise-address` can be used. Preferably, this option can be set in the [kubeadm API](/docs/reference/config-api/kubeadm-config.v1beta3) as `InitConfiguration.localAPIEndpoint` and `JoinConfiguration.controlPlane.localAPIEndpoint`. For kubelets on all nodes, the `--node-ip` option can be passed in `.nodeRegistration.kubeletExtraArgs` inside a kubeadm configuration file (`InitConfiguration` or `JoinConfiguration`). For dual-stack see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support). {{< note >}} IP addresses become part of certificates SAN fields. Changing these IP addresses would require signing new certificates and restarting the affected components, so that the change in certificate files is reflected. See [Manual certificate renewal](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#manual-certificate-renewal) for more details on this topic. {{</ note >}} {{< warning >}} The Kubernetes project recommends against this approach (configuring all component instances with custom IP addresses). Instead, the Kubernetes maintainers recommend to setup the host network, so that the default gateway IP is the one that Kubernetes components auto-detect and use. On Linux nodes, you can use commands such as `ip route` to configure networking; your operating system might also provide higher level network management tools. If your node's default gateway is a public IP address, you should configure packet filtering or other security measures that protect the nodes and your cluster. {{< /warning >}} {{< note >}} If the host does not have a default gateway, it is recommended to setup one. Otherwise, without passing a custom IP address to a Kubernetes component, the component will exit with an error. If two or more default gateways are present on the host, a Kubernetes component will try to use the first one it encounters that has a suitable global unicast IP address. While making this choice, the exact ordering of gateways might vary between different operating systems and kernel versions. {{< /note >}} </ins> ### Preparing the required container images This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`

I have a catastrophic problem with my production control-plane just because I naive believe in the instruction of the output of . My control-plane was gone and I couldn't recover from the failure because could not restart. After some tests, I found that need to be so that it tell the to use the correct internal IP that allow both new control plane and the current plane to talk to each other. Specifically, those IPs should allow etcd to communicate throw both servers. Without the default IP interface was used, but the firewall that I set on the default IP did not allow etcd to connect through. At this point, I would like to make a change to the document in a way that it emphasize the importance of in the command.
/language en /sig docs /kind feature
Page reported in issue: /sig cluster-lifecycle
/retitle Highlight the significance of in kubeadm join for HA cluster setup
all k8s components work like that. not only kubeadm. if you want custom IP from a different interface you need to pass it to the advertise address flag, but also as --node-ip to the kubelet. overall this setup with private IPs is not recommended and is difficult to manage. instead you should make the setup so that the public IP is the default route. then firewall the cluster properly. PRs for the above "create cluster" page with a note fix are welcome. the note can talk about "init" and "join", public IPs and firewall. /help /sig network
/triage accepted
actually, let me try to send the note. /remove-help
/assign


Question: The output displays 0 in the DESIRED and CURRENT columns: <del> NAME                                 DESIRED   CURRENT   READY   AGE </del> <ins> NAME                                  DESIRED   CURRENT   READY   AGE </ins> ... <del> dns-autoscaler-6b59789fc8            0         0         0       ... </del> <ins> kube-dns-autoscaler-6b59789fc8        0         0         0       ... </ins> ... <del> ### Option 2: Delete the dns-autoscaler deployment </del> <ins> ### Option 2: Delete the kube-dns-autoscaler deployment </ins> <del> This option works if dns-autoscaler is under your own control, which means </del> <ins> This option works if kube-dns-autoscaler is under your own control, which means </ins> no one will re-create it: ```shell <del> kubectl delete deployment dns-autoscaler --namespace=kube-system </del> <ins> kubectl delete deployment kube-dns-autoscaler --namespace=kube-system </ins> ``` The output is: <del> deployment.apps "dns-autoscaler" deleted </del> <ins> deployment.apps "kube-dns-autoscaler" deleted </ins> <del> ### Option 3: Delete the dns-autoscaler manifest file from the master node </del> <ins> ### Option 3: Delete the kube-dns-autoscaler manifest file from the master node </ins> <del> This option works if dns-autoscaler is under control of the (deprecated) </del> <ins> This option works if kube-dns-autoscaler is under control of the (deprecated) </ins> [Addon Manager](https://git.k8s.io/kubernetes/cluster/addons/README.md), and you have write access to the master node. Sign in to the master node and delete the corresponding manifest file. <del> The common path for this dns-autoscaler is: </del> <ins> The common path for this kube-dns-autoscaler is: </ins> /etc/kubernetes/addons/dns-horizontal-autoscaler/dns-horizontal-autoscaler.yaml After the manifest file is deleted, the Addon Manager will delete the <del> dns-autoscaler Deployment. </del> <ins> kube-dns-autoscaler Deployment. </ins>

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


Question:
 --- api_metadata: apiVersion: "autoscaling/v1" import: "k8s.io/api/autoscaling/v1" kind: "HorizontalPodAutoscaler" content_type: "api_reference" description: "水平 Pod 自动缩放器的配置。" title: "HorizontalPodAutoscaler" weight: 11 --- <-- api_metadata: apiVersion: "autoscaling/v1" import: "k8s.io/api/autoscaling/v1" kind: "HorizontalPodAutoscaler" content_type: "api_reference" description: "configuration of a horizontal pod autoscaler." title: "HorizontalPodAutoscaler" weight: 11 auto_generated: true --> `apiVersion: autoscaling/v1` `import "k8s.io/api/autoscaling/v1"`  ## HorizontalPodAutoscaler {#HorizontalPodAutoscaler} 水平 Pod 自动缩放器的配置。
  - **apiVersion**: autoscaling/v1 - **kind**: HorizontalPodAutoscaler  - **metadata** (<a href="{{< ref "../common-definitions/object-meta#ObjectMeta" >}}">ObjectMeta) 标准的对象元数据。 更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata  - **spec** (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscalerSpec" >}}">HorizontalPodAutoscalerSpec) 自动缩放器的规约。 更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status.  - **status** (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscalerStatus" >}}">HorizontalPodAutoscalerStatus) 自动缩放器的当前信息。  ## HorizontalPodAutoscalerSpec {#HorizontalPodAutoscalerSpec} 水平 Pod 自动缩放器的规约。
  - **maxReplicas** (int32)，必填 自动扩缩器可以设置的 Pod 数量上限； 不能小于 minReplicas。  - **scaleTargetRef** (CrossVersionObjectReference)，必填 对被扩缩资源的引用； 水平 Pod 自动缩放器将了解当前的资源消耗，并使用其 scale 子资源设置所需的 Pod 数量。   **CrossVersionObjectReference 包含足够的信息来让你识别出所引用的资源。**  - **scaleTargetRef.kind** (string)，必填 被引用对象的类别； 更多信息： https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds"  - **scaleTargetRef.name** (string)，必填 被引用对象的名称； 更多信息： http://kubernetes.io/docs/user-guide/identifiers#names  - **scaleTargetRef.apiVersion** (string) 被引用对象的 API 版本。  - **minReplicas** (int32) minReplicas 是自动缩放器可以缩减的副本数的下限。 它默认为 1 个 Pod。 如果启用了 alpha 特性门禁 HPAScaleToZero 并且配置了至少一个 Object 或 External 度量标准， 则 minReplicas 允许为 0。 只要至少有一个度量值可用，缩放就处于活动状态。  - **targetCPUUtilizationPercentage** (int32) 所有 Pod 的目标平均 CPU 利用率（以请求 CPU 的百分比表示）； 如果未指定，将使用默认的自动缩放策略。  ## HorizontalPodAutoscalerStatus {#HorizontalPodAutoscalerStatus} 水平 Pod 自动缩放器的当前状态
  - **currentReplicas** (int32)，必填 此自动缩放器管理的 Pod 的当前副本数。  - **desiredReplicas** (int32)，必填 此自动缩放器管理的 Pod 副本的所需数量。  - **currentCPUUtilizationPercentage** (int32) 当前所有 Pod 的平均 CPU 利用率， 以请求 CPU 的百分比表示， 例如：70 表示平均 Pod 现在正在使用其请求 CPU 的 70%。  - **lastScaleTime** (Time) 上次 HorizontalPodAutoscaler 缩放 Pod 的数量； 自动缩放器用它来控制 Pod 数量的更改频率。   **Time 是 time.Time 的包装类，支持正确地序列化为 YAML 和 JSON。 为 time 包提供的许多工厂方法提供了包装类。**  - **observedGeneration** (int64) 此自动缩放器观察到的最新一代。  ## HorizontalPodAutoscalerList {#HorizontalPodAutoscalerList} 水平 Pod 自动缩放器对象列表。
  - **apiVersion**: autoscaling/v1 - **kind**: HorizontalPodAutoscalerList  - **metadata** (<a href="{{< ref "../common-definitions/list-meta#ListMeta" >}}">ListMeta) 标准的列表元数据。  - **items** ([]<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler), required 水平 Pod 自动缩放器对象的列表。  ## 操作 {#Operations}
  ### `get` 读取特定的 HorizontalPodAutoscaler  #### HTTP 请求 GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称。  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 401: Unauthorized  ### `get` 读取特定 HorizontalPodAutoscaler 的状态 #### HTTP 请求 GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称。  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 401: Unauthorized  ### `list` 列出或监视 HorizontalPodAutoscaler 类别的对象  #### HTTP 参数 GET /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers  #### 参数  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **allowWatchBookmarks** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks  - **continue** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue  - **fieldSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector  - **labelSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector  - **limit** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **resourceVersion** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion  - **resourceVersionMatch** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch  - **timeoutSeconds** (*查询参数**): integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  - **watch** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscalerList" >}}">HorizontalPodAutoscalerList): OK 401: Unauthorized  ### `list` 列出或监视 HorizontalPodAutoscaler 类别的对象 #### HTTP 请求 GET /apis/autoscaling/v1/horizontalpodautoscalers  #### 参数  - **allowWatchBookmarks** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#allowWatchBookmarks" >}}">allowWatchBookmarks  - **continue** (*查询参数**): string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue  - **fieldSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector  - **labelSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector  - **limit** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **resourceVersion** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion  - **resourceVersionMatch** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch  - **timeoutSeconds** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  - **watch** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#watch" >}}">watch  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscalerList" >}}">HorizontalPodAutoscalerList): OK 401: Unauthorized  ### `create` 创建一个 HorizontalPodAutoscaler #### HTTP 请求 POST /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers  #### 参数  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler，必填  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 201 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Created 202 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Accepted 401: Unauthorized  ### `update` 替换特定的 HorizontalPodAutoscaler #### HTTP 请求 PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler，必填  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 201 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Created 401: Unauthorized  ### `update` 替换特定 HorizontalPodAutoscaler 的状态 #### HTTP 请求 PUT /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler，必填  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 201 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Created 401: Unauthorized  ### `patch` 部分更新特定的 HorizontalPodAutoscaler #### HTTP 请求 PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch，必填  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **force** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 201 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Created 401: Unauthorized  ### `patch` 部分更新特定 HorizontalPodAutoscaler 的状态 #### HTTP 请求 PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}/status  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../common-definitions/patch#Patch" >}}">Patch，必填  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldManager** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldManager" >}}">fieldManager  - **fieldValidation** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldValidation" >}}">fieldValidation  - **force** （**查询参数**）: boolean <a href="{{< ref "../common-parameters/common-parameters#force" >}}">force  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  #### 响应 200 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): OK 201 (<a href="{{< ref "../workload-resources/horizontal-pod-autoscaler-v1#HorizontalPodAutoscaler" >}}">HorizontalPodAutoscaler): Created 401: Unauthorized  ### `delete` 删除一个 HorizontalPodAutoscaler #### HTTP 请求 DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name}  #### 参数  - **name** （**路径参数**）: string，必填 HorizontalPodAutoscaler 的名称  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **gracePeriodSeconds** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **propagationPolicy** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 202 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): Accepted 401: Unauthorized  ### `deletecollection` 删除 HorizontalPodAutoscaler 的集合 #### HTTP 请求 DELETE /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers  #### 参数  - **namespace** （**路径参数**）: string，必填 <a href="{{< ref "../common-parameters/common-parameters#namespace" >}}">namespace  - **body**: <a href="{{< ref "../common-definitions/delete-options#DeleteOptions" >}}">DeleteOptions  - **continue** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#continue" >}}">continue  - **dryRun** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#dryRun" >}}">dryRun  - **fieldSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#fieldSelector" >}}">fieldSelector  - **gracePeriodSeconds** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#gracePeriodSeconds" >}}">gracePeriodSeconds  - **labelSelector** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#labelSelector" >}}">labelSelector  - **limit** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#limit" >}}">limit  - **pretty** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#pretty" >}}">pretty  - **propagationPolicy** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#propagationPolicy" >}}">propagationPolicy  - **resourceVersion** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersion" >}}">resourceVersion  - **resourceVersionMatch** （**查询参数**）: string <a href="{{< ref "../common-parameters/common-parameters#resourceVersionMatch" >}}">resourceVersionMatch  - **timeoutSeconds** （**查询参数**）: integer <a href="{{< ref "../common-parameters/common-parameters#timeoutSeconds" >}}">timeoutSeconds  #### 响应 200 (<a href="{{< ref "../common-definitions/status#Status" >}}">Status): OK 401: Unauthorized   No newline at end of file

Problem: do not have chinese docs: Proposed Solution: add chinese docs in website Comments /language zh /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
/close New tracked in
Closing this issue. <detailsIn response to : /close 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


Question: このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ <ins> - [ドキュメントに貢献する](#contributing-to-the-docs) - [翻訳された`README.md`一覧](#localization-readmemds) </ins> # リポジトリの使い方 Hugo(Extended version)を使用してWebサイトをローカルで実行することも、コンテナランタイムで実行することもできます。コンテナランタイムを使用することを強くお勧めします。これにより、本番Webサイトとのデプロイメントの一貫性が得られます。

This is a Feature Request What would you like to be Update README- Why is this needed has been updated after translated Comments /language ja
/triage accepted


Question: `zk-1` is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned </del> <ins> kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned </ins> ``` ```

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


Question: check the documentation for that version. {{< /note >}} <!-- body --> ## Install and configure prerequisites <del> The following steps apply common settings for Kubernetes nodes on Linux. </del> <ins> The following steps apply common settings for Kubernetes nodes on Linux. </ins> You can skip a particular setting if you're certain you don't need it. <del> For more information, see [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) or the documentation for your specific container runtime. </del> <ins> For more information, see [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) or the documentation for your specific container runtime. </ins> ### Forwarding IPv4 and letting iptables see bridged traffic

This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/triage accepted
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]:
/assign


Question: ## Version skew policy {#version-skew-policy} <del> The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}. `kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}. </del> <ins> While kubeadm allows version skew against some components that it manages, it is recommended that you match the kubeadm version with the versions of the control plane components, kube-proxy and kubelet. </ins> <del> Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters. </del> <ins> ### kubeadm's skew against the Kubernetes version </ins> <del> These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components: </del> <ins> kubeadm can be used with Kubernetes components that are the same version as kubeadm or one version older. The Kubernetes version can be specified to kubeadm by using the `--kubernetes-version` flag of `kubeadm init` or the [`ClusterConfiguration.kubernetesVersion`](/docs/reference/config-api/kubeadm-config.v1beta3/) field when using `--config`. This option will control the versions of kube-apiserver, kube-controller-manager, kube-scheduler and kube-proxy. </ins> <del> * Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/) * Kubeadm-specific [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl) </del> <ins> Example: * kubeadm is at {{< skew latestVersion >}} * `kubernetesVersion` must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}} ### kubeadm's skew against the kubelet Similarly to the Kubernetes version, kubeadm can be used with a kubelet version that is the same version as kubeadm or one version older. Example: * kubeadm is at {{< skew latestVersion >}} * kubelet on the host must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}} ### kubeadm's skew against kubeadm There are certain limitations on how kubeadm commands can operate on existing nodes or whole clusters managed by kubeadm. If new nodes are joined to the cluster, the kubeadm binary used for `kubeadm join` must match the last version of kubeadm used to either create the cluster with `kubeadm init` or to upgrade the same node with `kubeadm upgrade`. Similar rules apply to the rest of the kubeadm commands with the exception of `kubeadm upgrade`. Example for `kubeadm join`: * kubeadm version {{< skew latestVersion >}} was used to create a cluster with `kubeadm init` * Joining nodes must use a kubeadm binary that is at version {{< skew latestVersion >}} Nodes that are being upgraded must use a version of kubeadm that is the same MINOR version or one MINOR version newer than the version of kubeadm used for managing the node. Example for `kubeadm upgrade`: * kubeadm version {{< skew prevMinorVersion >}} was used to create or upgrade the node * The version of kubeadm used for upgrading the node must be at {{< skew prevMinorVersion >}} or {{< skew latestVersion >}} To learn more about the version skew between the different Kubernetes component see the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). </ins> ## Limitations {#limitations}

in this section: we document the kubeadm skew against the control plane, but we do not mention the skew of kubeadm against: the kubelet kubeadm itself replace the section with the following to clarify all points:
/sig cluster-lifecycle /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 : /sig cluster-lifecycle /help </details
/assign
thanks for assigning your self. i've some quick edits to the text a couple of minutes ago.
found them
/triage accepted


Question: <ins> --- title: Tutoriais main_menu: true no_list: true weight: 60 content_type: concept --- <!-- overview --> Essa seção da documentação contém tutoriais (em inglês). Um tutorial mostra como realizar um objetivo mais complexo que uma simples [tarefa](/docs/tasks/). Eles podem ser divididos em diversas seções, cada uma com uma sequência de passos e etapas a serem seguidos. Antes de iniciar um tutorial, é interessante que vocẽ salve a página de [Glossário](/pt/docs/reference/glossary/) para futuras referências. <!-- body --> ## Básicos * [Kubernetes básico](/docs/tutorials/kubernetes-basics/) é um tutorial interativo que auxilia no entendimento do ecossistema Kubernetes, bem como te permite testar algumas funcionalidades básicas do Kubernetes. * [Introdução ao Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) é um curso gratuíto da edX que te guia no entendimento do Kubernetes, seus conceitos, bem como na execução de tarefas mais simples. * [Hello Minikube](/docs/tutorials/hello-minikube/) é um "Hello World" que te permite testar rapidamente o Kubernetes em sua estação com o uso do Minikube ## Configuração * [Configurando o Redis usando um ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) ## Aplicações stateless * [Expondo um Endereço de IP externo para acessar uma aplicação no Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) * [Exemplo: Implantando a aplicação de Livro de Visitas (Guestbook) em  PHP com Redis](/docs/tutorials/stateless-application/guestbook/) ## Aplicações stateful * [Básicos sobre StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) * [Exemplo: WordPress e MySQL com Volumes Persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) * [Exemplo: Implantando Cassandra com Stateful Sets](/docs/tutorials/stateful-application/cassandra/) * [Executando ZooKeeper no Kubernetes](/docs/tutorials/stateful-application/zookeeper/) ## Pipelines de CI/CD * [Configurando um Pipeline CI/CD com Kubernetes Parte 1: Visão Geral](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/5/set-cicd-pipeline-kubernetes-part-1-overview) * [Configurando um Pipeline CI/CD com um Pod Jenkins no Kubernetes (Parte 2)](https://www.linux.com/blog/learn/chapter/Intro-to-Kubernetes/2017/6/set-cicd-pipeline-jenkins-pod-kubernetes-part-2) * [Executando e escalando um aplicativo distribuído de palavras cruzadas com CI/CD no Kubernetes (Parte 3)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/run-and-scale-distributed-crossword-puzzle-app-cicd-kubernetes-part-3) * [Configurando um CI/CD para um aplicativo distribuído de palavras cruzadas no Kubernetes (Parte 4)](https://www.linux.com/blog/learn/chapter/intro-to-kubernetes/2017/6/set-cicd-distributed-crossword-puzzle-app-kubernetes-part-4) ## Clusters * [AppArmor](/docs/tutorials/clusters/apparmor/) ## Serviços / "Services" * [Usando IP de origem](/docs/tutorials/services/source-ip/) ## {{% heading "whatsnext" %}} Se você desejar escrever um tutorial, veja a página [Utilizando templates](/docs/home/contribute/page-templates/) para informações sobre o tipo de página e o formato a ser utilizado. </ins>

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


Question: The value for this annotation must be **true** to take effect. This annotation indicates that pods running as this service account may only reference Secret API objects specified in the service account's `secrets` field. <ins> ### node.kubernetes.io/exclude-from-external-load-balancer Example: `node.kubernetes.io/exclude-from-external-load-balancer` Used on: Node Kubernetes automatically enables the `ServiceNodeExclusion` feature gate on the clusters it creates. With this feature gate enabled on a cluster, you can add labels to particular worker nodes to exclude them from the list of backend servers. The following command can be used to exclude a worker node from the list of backend servers in a backend set- `kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true` </ins> ### controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} Example: `controller.kubernetes.io/pod-deletion-cost: "10"`

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: I have a node in Minikube that's labelled with the key . This looks intended, but doesn't document that label. Proposed Solution: Document that label; as a side effect, this registers it. I can guess what this label does but I don't actually know. If you pick this issue up, part of your task is to find out that detail. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en /priority backlog PS. If this label isn't supposed to be used any more, we should also mark it as deprecated.
/triage accepted
/assign


Question: | Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) | <del> | DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | </del>

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: Client Libraries lists 3rd party software. Kubernetes docs allow content for third-party projects only when: Content documents software in the Kubernetes project Content documents software that’s out of project but necessary for Kubernetes to function Content is canonical on , or links to canonical content elsewhere Proposed Solution: ~Remove links to 3rd party client libraries~ Sort list alphabetically Page to Update: Additional Information: Part of umbrella issue /language en
There was some discussion in about this. What was the outcome?
This is also relevant to
We discussed this in the 2020-06-23 SIG Docs weekly meeting. proposed flagging the third party client libraries with an cautionary note about quality. recommended ensuring that all client projects within are linked to notes that this is strictly content as outside what's allowed in the but that it is useful to a wide user base also points out that client libraries in general (whether in-project or otherwise) are useful to make Kubernetes work as you want it to? This content is unique (there's not a good alternative page elsewhere on the web). What's important is to identifying an owning SIG and having some means to keep the list live and relevant. Removal is held until the end of the v1.19 release cycle, so positive discussion before that date is helpful and I encourage it. /sig community /sig api-machinery we are conflicted about where to put this; we're not sure it fits inside documentation any more - would SIG Community be interested in hosting this list? what are your views on this list, in light of
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : We discussed this in the 2020-06-23 SIG Docs weekly meeting. proposed flagging the third party client libraries with an cautionary note about quality. recommended ensuring that all client projects within are linked to notes that this is strictly content as outside what's allowed in the but that it is useful to a wide user base also points out that client libraries in general (whether in-project or otherwise) are useful to make Kubernetes work as you want it to?


Question: | Scala                | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala                | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift                | [github.com/swiftkube/client](https://github.com/swiftkube/client) | <del> | DotNet               | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | DotNet (RestSharp)   | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | | Elixir               | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | | Elixir               | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | </del>

/sig api-machinery we are conflicted about where to put this; we're not sure it fits inside documentation any more - would SIG Community be interested in hosting this list? what are your views on this list, in light of 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
Raised visibility in
sadly some projects under the org is not actively maintained. those libraries (go/java/python/dotnet/js) already linked are fairly active. can we consider to append a new link for C/C++ which is newly & active months ago? i wonder if the community-maintained list is stale b/c it seems rarely updated. also i noticed there's a number of repos stopped maintaining for 1-2 years or even longer period of time: am slighting leaning on keeping the community list as most of these projects are driven by individuals instead of dedicated vendors -- the more we have the better?
Should this issue remain open? Thanks!
I can see one thing that still needs doing /retitle Sort third party client library links so the link text is clearly in alphabetical order. Order by language then by URI.
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
/remove-lifecycle stale
The remaining sorting is straightforward; if it weren't for the issue history I'd say it's a good first issue. /help /kind cleanup
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 : The remaining sorting is straightforward; if it weren't for the issue history I'd say it's a good first issue. /help /kind cleanup 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


Question: ## Letting iptables see bridged traffic <ins> Make sure that the `br_netfilter` module is loaded. This can be done by running `lsmod | grep br_netfilter`. To load it explicitly call `sudo modprobe br_netfilter`. </ins> As a requirement for your Linux Node's iptables to correctly see bridged traffic, you should ensure `net.bridge.bridge-nf-call-iptables` is set to 1 in your `sysctl` config, e.g. ```bash

This paragraph is a bit backwards. It would be more intuitive to start with the "Make sure that the br_netfilter module is loaded before this step..." phrases.
/language en /kind cleanup /priority backlog /good-first-issue Thanks
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 : /language en /kind cleanup /priority backlog /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
/sig cluster-lifecycle


Question:
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!


Question:
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.


Question:
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.


Question:
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs


Question:
The Master is responsible for managing the cluster. The master coordinates all activities in your cluster, such as scheduling applications, maintaining applications' desired state, scaling applications, and rolling out new updates.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rtk. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

A node is a VM or a physical computer that serves as a worker machine in a Kubernetes cluster. Each node has a Kubelet, which is an agent for managing the node and communicating with the Kubernetes master. The node should also have tools for handling container operations, such as Docker or rkt. A Kubernetes cluster that handles production traffic should have a minimum of three nodes.

I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.


Question: 1. Run the following: <del> ```sh ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </del> <ins> ```sh etcd --listen-client-urls=http://$PRIVATE_IP:2379  --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </ins> <del> 2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </del> <ins> 2. Start the Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </ins> <del> Replace `PRIVATE_IP` with your etcd client IP. </del> <ins> Make sure `PRIVATE_IP` is set to your etcd client IP. </ins> ### Multi-node etcd cluster <del> For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ Documentation](https://github.com/coreos/etcd/blob/master/Documentation/faq.md#what-is-failure-tolerance). </del> <ins> For durability and high availability, run etcd as a multi-node cluster in production and back it up periodically. A five-member cluster is recommended in production. For more information, see [FAQ documentation](https://etcd.io/docs/current/faq/#what-is-failure-tolerance). </ins> <del> Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd Clustering Documentation](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md). </del> <ins> Configure an etcd cluster either by static member information or by dynamic discovery. For more information on clustering, see [etcd clustering documentation](https://etcd.io/docs/current/op-guide/clustering/). </ins> <del> For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: </del> <ins> For an example, consider a five-member etcd cluster running with the following client URLs: `http://$IP1:2379`, `http://$IP2:2379`, `http://$IP3:2379`, `http://$IP4:2379`, and `http://$IP5:2379`. To start a Kubernetes API server: </ins> 1. Run the following: <del> ```sh ./etcd --listen-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 --advertise-client-urls=http://$IP1:2379, http://$IP2:2379, http://$IP3:2379, http://$IP4:2379, http://$IP5:2379 ``` </del> <ins> ```shell etcd --listen-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 --advertise-client-urls=http://$IP1:2379,http://$IP2:2379,http://$IP3:2379,http://$IP4:2379,http://$IP5:2379 ``` </ins> <del> 2. Start Kubernetes API servers with the flag `--etcd-servers=$IP1:2379, $IP2:2379, $IP3:2379, $IP4:2379, $IP5:2379`. </del> <ins> 2. Start the Kubernetes API servers with the flag `--etcd-servers=$IP1:2379,$IP2:2379,$IP3:2379,$IP4:2379,$IP5:2379`. </ins> <del> Replace `IP` with your client IP addresses. </del> <ins> Make sure the `IP<n>` variables are set to your client IP addresses. </ins> <del> ###  Multi-node etcd cluster with load balancer </del> <ins> ### Multi-node etcd cluster with load balancer </ins> To run a load balancing etcd cluster:

Links to github on this page seems to be broken
/triage accepted /assign
Also see issue


Question: <!--script src="https://unpkg.com/split.js/dist/split.min.js"></script--> <script src="/js/split-1.6.0.js" intregrity="sha384-0blL3GqHy6+9fw0cyY2Aoiwg4onHAtslAs4OkqZY7UQBrR65/K4gI+hxLdWDrjpz"></script> <ins> <!--Script for dismissing banners/notices--> <script defer src="{{ "js/dismiss_banner.js" | relURL }}"></script> </ins> {{- if or (.HasShortcode "table")  (.HasShortcode "feature-gate-table") -}} <script defer src="{{ "js/sortable-table.js" | relURL }}"></script> {{- end -}}

This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
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
/retitle Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!


Question: <!--script src="https://unpkg.com/split.js/dist/split.min.js"></script--> <script src="/js/split-1.6.0.js" intregrity="sha384-0blL3GqHy6+9fw0cyY2Aoiwg4onHAtslAs4OkqZY7UQBrR65/K4gI+hxLdWDrjpz"></script> <ins> <!--Script for dismissing banners/notices--> <script defer src="{{ "js/dismiss_banner.js" | relURL }}"></script> </ins> {{- if or (.HasShortcode "table")  (.HasShortcode "feature-gate-table") -}} <script defer src="{{ "js/sortable-table.js" | relURL }}"></script> {{- end -}}

The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs


Question: - `Count`: Podがデフォルトの方法で処理されるべきであることを示します。`.spec.backoffLimit`のカウンターが加算されます。 {{< note >}} <del> `PodFailurePolicy`を使用すると、Jobコントローラは`Failed`フェーズのPodのみにマッチします。削除タイムスタンプを持つPodで、終了フェーズ(`Failed`または`Succeeded`)にないものは、まだ終了中と見なされます。これは、終了中Podは終了フェーズに達するまで[追跡ファイナライザー](#job-tracking-with-finalizers)を保持することを意味します。Kubernetes 1.27以降、Kubeletは削除されたPodを終了フェーズに遷移させます(参照:[Podのフェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))。これにより、削除されたPodはJobコントローラーによってファイナライザーが削除されます。 </del> <ins> `PodFailurePolicy`を使用すると、Jobコントローラーは`Failed`フェーズのPodのみにマッチします。削除タイムスタンプを持つPodで、終了フェーズ(`Failed`または`Succeeded`)にないものは、まだ終了中と見なされます。これは、終了中Podは終了フェーズに達するまで[追跡ファイナライザー](#job-tracking-with-finalizers)を保持することを意味します。Kubernetes 1.27以降、Kubeletは削除されたPodを終了フェーズに遷移させます(参照:[Podのフェーズ](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase))。これにより、削除されたPodはJobコントローラーによってファイナライザーが削除されます。 </ins> {{< /note >}} ## Jobの終了とクリーンアップ  {#job-termination-and-cleanup}

This is a Bug Report Problem: In the Japanese localization of k/website, it is necessary to express "controller" as "" (not ""). In , it is expressed as "". ref. ref. Proposed Solution: fix "" to "" Page to Update:
/assign /area localization /language ja
ref.
/triage accepted


Question: } ``` <ins> ## Create Pod that uses the container runtime default seccomp profile Most container runtimes provide a sane set of default syscalls that are allowed or not. You can adopt these defaults for your workload by setting the seccomp type in the security context of a pod or container to `RuntimeDefault`. {{< note >}} If you have the `SeccompDefault` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled, then Pods use the `RuntimeDefault` seccomp profile whenever no other seccomp profile is specified. Otherwise, the default is `Unconfined`. {{< /note >}} Here's a manifest for a Pod that requests the `RuntimeDefault` seccomp profile for all its containers: {{< codenew file="pods/security/seccomp/ga/default-pod.yaml" >}} Create that Pod: ```shell kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml ``` ```shell kubectl get pod default-pod ``` The Pod should be showing as having started successfully: ``` NAME        READY   STATUS    RESTARTS   AGE default-pod 1/1     Running   0          20s ``` Finally, now that you saw that work OK, clean up: ```shell kubectl delete pod default-pod --wait --now ``` </ins> ## Create a Pod with a seccomp profile for syscall auditing To start off, apply the `audit.json` profile, which will log all syscalls of the

This is a Feature Request Hi, I would like to request a change made in doc page: It would make more sense if the "Create Pod that uses the container runtime default seccomp profile" section was after "Enable the use of RuntimeDefault as the default seccomp profile for all workloads" section, and not the very last option of creating pods with seccomp profiles. I feel like it would improve the flow.
Page: /language en
I am new to the kubernetes website project, Can I work on this issue ?
/retitle Improve flow for Seccomp security tutorial
Anyone can work on this issue, providing that they follow our .
Hi Are you working on this issue?
/triage accepted
if no one is working on this then I'm up for it.
/assign
Hi will this seems valid to you?
yeah I think having a slightly different order of the sections would make understanding the topic better. I'm in favor of that! :)
thanks for your views on this. I will soon create the PR for it.
Fixed it here:


Question: [the design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md). ### Summary API Source <del> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and omits them in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </del> <ins> The [Kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at node, volume, pod and container level, and emits their statistics in the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) </ins> for consumers to read. Pre-1.23, these resources have been primarily gathered from [cAdvisor](https://github.com/google/cadvisor). However, in 1.23 with the

<!-- 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: When I was reading this , I felt very confused. The meaning of this sentence is to explain that the node, volume, pod and container level information cannot be obtained from the summary API? But I read and code implementation: My understanding is: The node, volume, pod and container level information can be obtained from the summary API. So is an expression error? Proposed Solution: Enhanced description to avoid ambiguity or misrepresentation. Suggested modification: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--The English version of the original PR: /assign
Hi agree it needs fixing per I have a bunch of notes, please add your thoughts so we can clarify this matter. It is confusing.
/language en The best place to add more notes is issue
Thanks for the reminder, I've comment to
it sounds like the original author intended instead. Outputs definitely works too.
Use as the word makes sense, thanks for the reply!
/triage accepted


Question: <ins> --- title: "从 dockershim 迁移" weight: 10 content_type: task --- <!-- title: "Migrating from dockershim" weight: 10 content_type: task --> <!-- overview --> <!-- This section presents information you need to know when migrating from dockershim to other container runtimes. --> 本节提供从 dockershim 迁移到其他容器运行时的必备知识。 <!-- Since the announcement of [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) in Kubernetes 1.20, there were questions on how this will affect various workloads and Kubernetes installations. You can find this blog post useful to understand the problem better: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) --> 自从 Kubernetes 1.20 宣布 [弃用 dockershim](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)， 各类疑问随之而来：这对各类工作负载和 Kubernetes 部署会产生什么影响。 你会发现这篇博文对于更好地理解此问题非常有用： [弃用 Dockershim 常见问题](/zh/blog/2020/12/02/dockershim-faq/) <!-- It is recommended to migrate from dockershim to alternative container runtimes. Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) section to know your options. Make sure to [report issues](https://github.com/kubernetes/kubernetes/issues) you encountered with the migration. So the issue can be fixed in a timely manner and your cluster would be ready for dockershim removal. --> 建议从 dockershim 迁移到其他替代的容器运行时。 请参阅[容器运行时](/zh/docs/setup/production-environment/container-runtimes/) 一节以了解可用的备选项。 当在迁移过程中遇到麻烦，请[上报问题](https://github.com/kubernetes/kubernetes/issues)。 那么问题就可以及时修复，你的集群也可以进入移除 dockershim 前的就绪状态。 </ins>

This is a Feature Request translate /docs/tasks/administer-cluster/migrating-from- into Chinese What would you like to be /zh/docs/tasks/administer-cluster/migrating-from-dockershim/index.m /assign /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


Question: <ins> --- layout: blog title: "dl.k8s.io 采用内容分发网络（CDN）" date: 2023-06-09 slug: dl-adopt-cdn --- <!-- layout: blog title: "dl.k8s.io to adopt a Content Delivery Network" date: 2023-06-09 slug: dl-adopt-cdn --> <!-- **Authors**: Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) --> **作者**：Arnaud Meukam (VMware), Hannah Aubry (Fast Forward), Frederico Muñoz (SAS Institute) **译者**：[Xin Li](https://github.com/my-git9) (Daocloud) <!-- We're happy to announce that dl.k8s.io, home of the official Kubernetes binaries, will soon be powered by [Fastly](https://www.fastly.com). Fastly is known for its high-performance content delivery network (CDN) designed to deliver content quickly and reliably around the world. With its powerful network, Fastly will help us deliver official Kubernetes binaries to users faster and more reliably than ever before. --> 我们很高兴地宣布，官方 Kubernetes 二进制文件的主页 dl.k8s.io 很快将由 [Fastly](https://www.fastly.com) 提供支持。 Fastly 以其高性能内容分发网络（CDN）而闻名， 该网络旨在全球范围内快速可靠地分发内容。凭借其强大的网络，Fastly 将帮助我们实现比以往更快、更可靠地向用户分发官方 Kubernetes 二进制文件。 <!-- The decision to use Fastly was made after an extensive evaluation process in which we carefully evaluated several potential content delivery network providers. Ultimately, we chose Fastly because of their commitment to the open internet and proven track record of delivering fast and secure digital experiences to some of the most known open source projects (through their [Fast Forward](https://www.fastly.com/fast-forward) program). --> 使用 Fastly 是在经过广泛的评估过程后做出的决定， 在该过程中我们仔细评估了几个潜在的内容分发网络提供商。最终，我们选择 Fastly 是因为他们对开放互联网的承诺以及在为一些著名的开源项目（通过他们的 [Fast Forward](https://www.fastly.com/fast-forward) 计划）提供快速和安全的数字体验方面的良好记录。 <!-- ## What you need to know about this change - On Monday, July 24th, the IP addresses and backend storage associated with the dl.k8s.io domain name will change. - The change will not impact the vast majority of users since the domain name will remain the same. - If you restrict access to specific IP ranges, access to the dl.k8s.io domain could stop working. --> ## 关于本次更改你需要了解的信息 - 7 月 24 日星期一，与 dl.k8s.io 域名关联的 IP 地址和后端存储将发生变化。 - 由于域名将保持不变，因此更改不会影响绝大多数用户。 - 如果你限制对特定 IP 范围的访问，则对 dl.k8s.io 域的访问可能会停止工作。 <!-- If you think you may be impacted or want to know more about this change, please keep reading. --> 如果你认为你可能会受到影响或想了解有关此次更改的更多信息，请继续阅读。 <!-- ## Why are we making this change The official Kubernetes binaries site, dl.k8s.io, is used by thousands of users all over the world, and currently serves _more than 5 petabytes of binaries each month_. This change will allow us to improve access to those resources by leveraging a world-wide CDN. --> ## 我们为什么要进行此更改 官方 Kubernetes 二进制文件网站 dl.k8s.io 被全世界成千上万的用户使用， 目前**每月提供超过 5 PB 的二进制文件服务**。本次更改将通过充分利用全球 CDN 来改善对这些资源的访问。 <!-- ## Does this affect dl.k8s.io only, or are other domains also affected? Only dl.k8s.io will be affected by this change. --> ## 这只影响 dl.k8s.io，还是其他域也受到影响？ 只有 dl.k8s.io 会受到本次变更的影响。 <!-- ## My company specifies the domain names that we are allowed to be accessed. Will this change affect the domain name? No, the domain name (`dl.k8s.io`) will remain the same: no change will be necessary, and access to the Kubernetes release binaries site should not be affected. --> ## 我公司规定了允许我们访问的域名，此更改会影响域名吗？ 不，域名（`dl.k8s.io`）将保持不变：无需更改，不会影响对 Kubernetes 发布二进制文件站点的访问。 <!-- ## My company uses some form of IP filtering. Will this change affect access to the site? If IP-based filtering is in place, it’s possible that access to the site will be affected when the new IP addresses become active. --> ## 我的公司使用某种形式的 IP 过滤，此更改会影响对站点的访问吗？ 如果已经存在基于 IP 的过滤，则当新 IP 地址变为活动状态时，对站点的访问可能会受到影响。 <!-- ## If my company doesn’t use IP addresses to restrict network traffic, do we need to do anything? No, the switch to the CDN should be transparent. --> ## 如果我的公司不使用 IP 地址来限制网络流量，我们需要做些什么吗？ 不，切换到 CDN 的过程应该是透明的。 <!-- ## Will there be a dual running period? **No, it is a cutover.** You can, however, test your networks right now to check if they can route to the new public IP addresses from Fastly.  You should add the new IPs to your network's `allowlist` before July 24th. Once the transfer is complete, ensure your networks use the new IP addresses to connect to the `dl.k8s.io` service. --> ## 会有双运行期吗？ **不，这是切换。**但是，你现在可以测试你的网络，检查它们是否可以从 Fastly 路由到新的公共 IP 地址。 你应该在 7 月 24 日之前将新 IP 添加到你网络的 `allowlist`（白名单）中。 切换完成后，确保你的网络使用新的 IP 地址连接到 `dl.k8s.io` 服务。 <!-- ## What are the new IP addresses? If you need to manage an allow list for downloads, you can get the ranges to match from the Fastly API, in JSON: [public IP address ranges](https://api.fastly.com/public-ip-list).  You don't need any credentials to download that list of ranges. --> ## 新 IP 地址是什么？ 如果你需要管理下载允许列表，你可以从 Fastly API 中获取需要匹配的范围， JSON 格式地址：[公共 IP 地址范围](https://api.fastly.com/public-ip-list)。 你不需要任何凭据即可下载该范围列表。 <!-- ## What next steps would you recommend? If you have IP-based filtering in place, we recommend the following course of action **before July, 24th**: --> ## 推荐哪些后续操作？ 如果你已经有了基于 IP 的过滤，我们建议你**在 7 月 24 日**之前采取以下行动： <!-- - Add the new IP addresses to your allowlist. - Conduct tests with your networks/firewall to ensure your networks can route to the new IP addresses. After the change is made, we recommend double-checking that HTTP calls are accessing dl.k8s.io with the new IP addresses. --> - 将新的 IP 地址添加到你的白名单。 - 对你的网络/防火墙进行测试，以确保你的网络可以路由到新的 IP 地址。 进行更改后，我们建议仔细检查 HTTP 调用是否正在使用新 IP 地址访问 dl.k8s.io。 <!-- ## What should I do if I detect some abnormality after the cutover date? If you encounter any weirdness during binaries download, please [open an issue](https://github.com/kubernetes/k8s.io/issues/new/choose). --> ## 切换后发现异常怎么办？ 如果你在二进制文件下载过程中遇到任何异常， 请[提交 Issue](https://github.com/kubernetes/k8s.io/issues/new/choose)。 </ins>

This blog has not zh version yet. I will localize it. Open the issue to avoid possible dup. /assign /language zh
/triage accepted


Question: {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} is being created from a VolumeSnapshot. <del> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </del> <ins> Refer to [Converting the volume mode of a Snapshot](/docs/concepts/storage/volume-snapshots/#convert-volume-mode) </ins> and the [Kubernetes CSI Developer Documentation](https://kubernetes-csi.github.io/docs/) for more information. ## Annotations used for audit

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: I have a node in Minikube that's labelled with the key . This looks intended, but doesn't document that label. Proposed Solution: Document that label; as a side effect, this registers it. I can guess what this label does but I don't actually know. If you pick this issue up, part of your task is to find out that detail. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en /priority backlog PS. If this label isn't supposed to be used any more, we should also mark it as deprecated.
/triage accepted
/assign


Question: #### Creating a Secret with a Docker config <ins> You need to know the username, registry password and client email address for authenticating to the registry, as well as its hostname. </ins> Run the following command, substituting the appropriate uppercase values: ```shell

Ref: needs a rewrite. It mentions Docker (and Podman!) all over the place, which is a good indication that the docs are old enough to need a rewrite. At a minimum, remove mentions of Docker in these topics: /triage accepted /milestone 1.24
/assign
/assign
Reasked folks in Slack for correct disposition
Asked in the SIG Node slack channel:
To summarize the consensus from talking with folks about this issue, specifically the examples in Using a Private Registry section: The steps in the Using a Private Registry section are still valid. However, as written, it makes it sound like Docker is the only/recommended way to do this-which we dont want. We should be able to remove the docker examples and point folks to this page , which covers most of the same content with third party disclaimers already written into the examples. I plan to open a PR later this week with these changes!
Has anyone opened a PR for this issue? It seems to be referring to


Question: ## IBM Cloud Kubernetes Service ### Compute nodes <del> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters). </del> <ins> By using the IBM Cloud Kubernetes Service provider, you can create clusters with a mixture of virtual and physical (bare metal) nodes in a single zone or across multiple zones in a region. For more information, see [Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes). </ins> The name of the Kubernetes Node object is the private IP address of the IBM Cloud Kubernetes Service worker node instance.

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: At Line 398, The link for "Planning your cluster and worker node setup" might seems to be changed from Proposed Solution: The link has to be changed as "". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /assign


Question: Auditing allows cluster administrators to answer the following questions: --> <del> Kubernetes**审计（Auditing）**功能提供了与安全相关的、按时间顺序排列的记录集， </del> <ins> Kubernetes **审计（Auditing）** 功能提供了与安全相关的、按时间顺序排列的记录集， </ins> 记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。 审计功能使得集群管理员能够回答以下问题：

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 Bold isn't effect in "Auditing", as shown below: ! Proposed Solution: Modify the format to make the bold effective. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
If this issue been triage/accepted, I think I can fix this. /assign
/sig docs /language zh
/triage accepted
Thanks for the catch! You can fix it if you want.
Sure, let me fix it.


Question: the configurations portable. Service accounts are different from user accounts, which are authenticated <del> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </del> <ins> human users in the cluster. By default, user accounts don't exist in the Kubernetes API server; instead, the API server treats user identities as opaque </ins> data. You can authenticate as a user account using multiple methods. Some Kubernetes distributions might add custom extension APIs to represent user accounts in the API server.

No navigation panel says anything about bound service account tokens. describes service accounts and their non-bound tokens. mentions them in a 4-th level subsection under automation in the admission controller (which omits the fact that the kubelet is also involved in automating bound tokens, see ), but that subsection is omitted from the TOC because it is 4th level. Apparently that 3rd-level branch is only taking responsibility for describing service account automation in the admission controller. Bound service account tokens are an aspect of the authentication functionality that should be described on their own right, in the page on authentication.
/triage accepted
/sig auth
There isn't really a concept page on ServiceAccount. If there were, we could migrate the content to that concept page, and then hyperlink to that new section from its previous home.
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
In fact: /lifecycle frozen
/priority backlog
/sig security
is somewhat relevant
…until now:
I reckon will close this issue.


Question: <ins> --- title: Tarefas main_menu: true weight: 50 content_type: concept --- <!-- overview --> Essa seção da documentação contém páginas que mostram como executar tarefas individuais. Essas tarefas são organizadas em uma curta sequência de etapas e passos que te auxiliam a entender conceitos básicos. Se você desejar adicionar uma tarefa, verifique como [criar um Pull Request para a documentação](/docs/contribute/new-content/open-a-pr/). </ins>

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


Question: * [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) is a dashboard web interface for Kubernetes. <del> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for graphically visualizing your containers, pods, services etc. Use it in conjunction with a [Weave Cloud account](https://cloud.weave.works/) or host the UI yourself. </del> <ins> * [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) is a tool for visualizing your containers, Pods, Services and more. </ins> ## Infrastructure

Problem: The text on is not working, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. Page to Update: Suggested Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link to and not to this . /assign /language en 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
I'd change: to
/triage accepted
/sig docs
/assign


Question: ### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. What would you like to be should mention field Why is this needed This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. Comments We might use a warning from as a draft and modify it accordingly. /sig auth /kind documentation
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. should mention field This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. We might use a warning from as a draft and modify it accordingly. 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
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
/remove-lifecycle stale
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
/remove-lifecycle stale
/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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .


Question: ### hostPath {#hostpath} <ins> {{< warning >}} HostPath volumes present many security risks, and it is a best practice to avoid the use of HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the required file or directory, and mounted as ReadOnly. If restricting HostPath acccess to specific directories through AdmissionPolicy, `volumeMounts` MUST be required to use `readOnly` mounts for the policy to be effective. {{< /warning >}} </ins> A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications.

/lifecycle rotten
/remove-lifecycle rotten Still working on this?
/sig security
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-contributor-experience at . /lifecycle stale
Adding the PSS as is the future as K8S 1.21 is deprecating PSP. All Documentation for mention Read Only should also be covered in this docf from now on.
/sig storage /remove-sig auth
does this mean that readonly for hostpath is allowed and working but just not documented ?
yes, exactly
that is ownsome I was just going to rule out this solution because of the security issue. Thanks for your answer I'll test it right away.
well, I am using this manifest but I get this error
the VolumeMount on the pod spec allows a readonly setup but not on the Volume definition.
You're right and that's what I meant. Perhaps, I explained it a little vague.
well in that case I think you should close this issue as it is not an issue? the hostpath volume type does not support readonly but the container volume mount supports it and is documented here :
My point was that we can promote best practices by adding a hint to the documentation. Most of the people, don't read API specifications, they google and find a page with documentation. In this case, an advise of other options might be useful.
/remove-lifecycle stale
Would very much have appreciated if suggestion had been implemented; would have saved me a bunch of time looking for a way to mount a hostPath readonly.
/assign I can add a note in


Question: sudo sysctl --system ``` <del> Verify that the `br_netfilter`, `overlay` modules are loaded by running below instructions: </del> <ins> Verify that the `br_netfilter`, `overlay` modules are loaded by running the following commands: </ins> ```bash lsmod | grep br_netfilter lsmod | grep overlay ``` <del> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, `net.ipv4.ip_forward` system variables are set to 1 in your `sysctl` config by running below instruction: </del> <ins> Verify that the `net.bridge.bridge-nf-call-iptables`, `net.bridge.bridge-nf-call-ip6tables`, and `net.ipv4.ip_forward` system variables are set to `1` in your `sysctl` config by running the following command: </ins> ```bash sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables net.ipv4.ip_forward ``` <del> ## Cgroup drivers </del> <ins> ## cgroup drivers </ins> On Linux, {{< glossary_tooltip text="control groups" term_id="cgroup" >}} are used to constrain resources that are allocated to processes. <del> Both {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </del> <ins> Both the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and the </ins> underlying container runtime need to interface with control groups to enforce <del> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </del> <ins> [resource management for pods and containers](/docs/concepts/configuration/manage-resources-containers/) and set resources such as cpu/memory requests and limits. To interface with control </ins> groups, the kubelet and the container runtime need to use a *cgroup driver*. <del> It's critical that the kubelet and the container runtime uses the same cgroup </del> <ins> It's critical that the kubelet and the container runtime use the same cgroup </ins> driver and are configured the same. There are two cgroup drivers available:

This section: I would add information like here: Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd.
this section: already links to: PRs welcome with proposed improvements. /help /sig cluster-lifecycle
If someone wants to help here, I'm not sure what steps they should follow to assist. Because of that: /remove-help
/language en
I think the suggestion is to add something about to container-runtimes pages but I don't think that fits well on that page because it only covers the container runtime side. What could be though is that there's a note/reminder to ensure they are always the same. I can work on that if we agree what's what we want here.
hmm, looks like this is already covered too.
some additional feedback in
/triage accepted
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]:
/assign


Question: Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond <del> the lifetime of a pod. Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. </del> <ins> the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not destroy persistent volumes. For any kind of volume in a given pod, data is preserved across container restarts. </ins> At its core, a volume is just a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the

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: Through the progress with many contributors, the content of got a little bit unclear. ] (Most of the sentences are updated about 3 years ago.) ] Let's call the sentence Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. "the sentence A". In the paragraphs of the current version, the sentences ahead of the sentence A is not a basis or reason of the sentence A. Proposed Solution: Page to Update: /assign
/triage accepted
/sig storage


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