Question: <ins> --- layout: blog title: "Kubernetes 1.24: 节点非体面关闭特性进入 Alpha 阶段" date: 2022-05-20 slug: kubernetes-1-24-non-graceful-node-shutdown-alpha --- <!-- layout: blog title: "Kubernetes 1.24: Introducing Non-Graceful Node Shutdown Alpha" date: 2022-05-20 slug: kubernetes-1-24-non-graceful-node-shutdown-alpha --> <!-- **Authors** Xing Yang and Yassine Tijani (VMware) --> **作者**：Xing Yang 和 Yassine Tijani (VMware) <!-- Kubernetes v1.24 introduces alpha support for [Non-Graceful Node Shutdown](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown). This feature allows stateful workloads to failover to a different node after the original node is shutdown or in a non-recoverable state such as hardware failure or broken OS. --> Kubernetes v1.24 引入了对[节点非体面关闭](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2268-non-graceful-shutdown) （Non-Graceful Node Shutdown）的 Alpha 支持。 此特性允许有状态工作负载在原节点关闭或处于不可恢复状态（如硬件故障或操作系统损坏）后，故障转移到不同的节点。 <!-- ## How is this different from Graceful Node Shutdown --> ## 这与节点体面关闭有何不同 <!-- You might have heard about the [Graceful Node Shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown) capability of Kubernetes, and are wondering how the Non-Graceful Node Shutdown feature is different from that. Graceful Node Shutdown allows Kubernetes to detect when a node is shutting down cleanly, and handles that situation appropriately. A Node Shutdown can be "graceful" only if the node shutdown action can be detected by the kubelet ahead of the actual shutdown. However, there are cases where a node shutdown action may not be detected by the kubelet. This could happen either because the shutdown command does not trigger the systemd inhibitor locks mechanism that kubelet relies upon, or because of a configuration error (the `ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are not configured properly). --> 你可能听说过 Kubernetes 的[节点体面关闭](/zh-cn/docs/concepts/architecture/nodes/#graceful-node-shutdown)特性， 并且想知道节点非体面关闭特性与之有何不同。节点体面关闭允许 Kubernetes 检测节点何时完全关闭，并适当地处理这种情况。 只有当 kubelet 在实际关闭之前检测到节点关闭动作时，节点关闭才是“体面（graceful）”的。 但是，在某些情况下，kubelet 可能检测不到节点关闭操作。 这可能是因为 shutdown 命令没有触发 kubelet 所依赖的 systemd 抑制锁机制， 或者是因为配置错误（`ShutdownGracePeriod` 和 `ShutdownGracePeriodCriticalPods` 配置不正确）。 <!-- Graceful node shutdown relies on Linux-specific support. The kubelet does not watch for upcoming shutdowns on Windows nodes (this may change in a future Kubernetes release). --> 节点体面关闭依赖于特定 Linux 的支持。 kubelet 不监视 Windows 节点上即将关闭的情况（这可能在未来的 Kubernetes 版本中会有所改变）。 <!-- When a node is shutdown but without the kubelet detecting it, pods on that node also shut down ungracefully. For stateless apps, that's often not a problem (a ReplicaSet adds a new pod once the cluster detects that the affected node or pod has failed). For stateful apps, the story is more complicated. If you use a StatefulSet and have a pod from that StatefulSet on a node that fails uncleanly, that affected pod will be marked as terminating; the StatefulSet cannot create a replacement pod because the pod still exists in the cluster. As a result, the application running on the StatefulSet may be degraded or even offline. If the original, shut down node comes up again, the kubelet on that original node reports in, deletes the existing pods, and the control plane makes a replacement pod for that StatefulSet on a different running node. If the original node has failed and does not come up, those stateful pods would be stuck in a terminating status on that failed node indefinitely. --> 当一个节点被关闭但 kubelet 没有检测到时，该节点上的 Pod 也会非体面地关闭。 对于无状态应用程序，这通常不是问题（一旦集群检测到受影响的节点或 Pod 出现故障，ReplicaSet 就会添加一个新的 Pod）。 对于有状态的应用程序，情况要复杂得多。如果你使用一个 StatefulSet， 并且该 StatefulSet 中的一个 Pod 在某个节点上发生了不干净故障，则该受影响的 Pod 将被标记为终止（Terminating）； StatefulSet 无法创建替换 Pod，因为该 Pod 仍存在于集群中。 因此，在 StatefulSet 上运行的应用程序可能会降级甚至离线。 如果已关闭的原节点再次出现，该节点上的 kubelet 会执行报到操作，删除现有的 Pod， 并且控制平面会在不同的运行节点上为该 StatefulSet 生成一个替换 Pod。 如果原节点出现故障并且没有恢复，这些有状态的 Pod 将处于终止状态且无限期地停留在该故障节点上。 ``` $ kubectl get pod -o wide NAME    READY   STATUS        RESTARTS   AGE   IP           NODE                      NOMINATED NODE   READINESS GATES web-0   1/1     Running       0          100m   10.244.2.4   k8s-node-876-1639279816   <none>           <none> web-1   1/1     Terminating   0          100m   10.244.1.3   k8s-node-433-1639279804   <none>           <none> ``` <!-- ## Try out the new non-graceful shutdown handling To use the non-graceful node shutdown handling, you must enable the `NodeOutOfServiceVolumeDetach` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the `kube-controller-manager` component. --> ## 尝试新的非体面关闭处理 要使用节点非体面关闭处理，你必须为 `kube-controller-manager` 组件启用 `NodeOutOfServiceVolumeDetach` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 <!-- In the case of a node shutdown, you can manually taint that node as out of service. You should make certain that the node is truly shutdown (not in the middle of restarting) before you add that taint. You could add that taint following a shutdown that the kubelet did not detect and handle in advance; another case where you can use that taint is when the node is in a non-recoverable state due to a hardware failure or a broken OS. The values you set for that taint can be `node.kubernetes.io/out-of-service=nodeshutdown: "NoExecute"` or `node.kubernetes.io/out-of-service=nodeshutdown:" NoSchedule"`. Provided you have enabled the feature gate mentioned earlier, setting the out-of-service taint on a Node means that pods on the node will be deleted unless if there are matching tolerations on the pods. Persistent volumes attached to the shutdown node will be detached, and for StatefulSets, replacement pods will be created successfully on a different running node. --> 在节点关闭的情况下，你可以手动为该节点标记污点，标示其已停止服务。 在添加污点之前，你应该确保节点确实关闭了（不是在重启过程中）。 你可以在发生了节点关闭事件，且该事件没有被 kubelet 提前检测和处理的情况下，在节点关闭之后添加污点； 你可以使用该污点的另一种情况是当节点由于硬件故障或操作系统损坏而处于不可恢复状态时。 你可以为该污点设置的值是 `node.kubernetes.io/out-of-service=nodeshutdown: "NoExecute"` 或 `node.kubernetes.io/out-of-service=nodeshutdown: "NoSchedule"`。 如果你已经启用了前面提到的特性门控，在节点上设置 out-of-service 污点意味着节点上的 Pod 将被删除， 除非 Pod 上设置有与之匹配的容忍度。原来挂接到已关闭节点的持久卷（Persistent volume）将被解除挂接， 对于 StatefulSet，系统将在不同的运行节点上成功创建替换 Pod。 ``` $ kubectl taint nodes <node-name> node.kubernetes.io/out-of-service=nodeshutdown:NoExecute $ kubectl get pod -o wide NAME    READY   STATUS    RESTARTS   AGE    IP           NODE                      NOMINATED NODE   READINESS GATES web-0   1/1     Running   0          150m   10.244.2.4   k8s-node-876-1639279816   <none>           <none> web-1   1/1     Running   0          10m    10.244.1.7   k8s-node-433-1639279804   <none>           <none> ``` <!-- Note: Before applying the out-of-service taint, you **must** verify that a node is already in shutdown or power off state (not in the middle of restarting), either because the user intentionally shut it down or the node is down due to hardware failures, OS issues, etc. --> 注意：在应用 out-of-service 污点之前，你**必须**确认节点是否已经处于关闭或断电状态（不是在重新启动过程中）， 节点关闭的原因可能是用户有意将其关闭，也可能是节点由于硬件故障、操作系统问题等而关闭。 <!-- Once all the workload pods that are linked to the out-of-service node are moved to a new running node, and the shutdown node has been recovered, you should remove that taint on the affected node after the node is recovered. If you know that the node will not return to service, you could instead delete the node from the cluster. --> 一旦关联到无法提供服务的节点的所有工作负载 Pod 都被移动到新的运行中的节点，并且关闭了的节点也已恢复， 你应该在节点恢复后删除受影响节点上的污点。如果你知道该节点不会恢复服务，则可以改为从集群中删除该节点。 <!-- ## What’s next? Depending on feedback and adoption, the Kubernetes team plans to push the Non-Graceful Node Shutdown implementation to Beta in either 1.25 or 1.26. --> ## 下一步是什么？ 根据反馈和采用情况，Kubernetes 团队计划在 1.25 或 1.26 版本中将节点非体面关闭实现推送到 Beta 阶段。 <!-- This feature requires a user to manually add a taint to the node to trigger workloads failover and remove the taint after the node is recovered. In the future, we plan to find ways to automatically detect and fence nodes that are shutdown/failed and automatically failover workloads to another node. --> 此功能需要用户手动向节点添加污点以触发工作负载故障转移，并要求用户在节点恢复后移除污点。 未来，我们计划寻找方法来自动检测和隔离已关闭的或已失败的节点，并自动将工作负载故障转移到另一个节点。 <!-- ## How can I learn more? Check out the [documentation](/docs/concepts/architecture/nodes/#non-graceful-node-shutdown) for non-graceful node shutdown. --> ## 怎样才能了解更多？ 查看节点非体面关闭相关[文档](/zh-cn/docs/concepts/architecture/nodes/#non-graceful-node-shutdown)。 <!-- ## How to get involved? --> ## 如何参与？ <!-- This feature has a long story. Yassine Tijani ([yastij](https://github.com/yastij)) started the KEP more than two years ago. Xing Yang ([xing-yang](https://github.com/xing-yang)) continued to drive the effort. There were many discussions among SIG Storage, SIG Node, and API reviewers to nail down the design details. Ashutosh Kumar ([sonasingh46](https://github.com/sonasingh46)) did most of the implementation and brought it to Alpha in Kubernetes 1.24. --> 此功能特性由来已久。Yassine Tijani（[yastij](https://github.com/yastij)）在两年多前启动了这个 KEP。 Xing Yang（[xing-yang](https://github.com/xing-yang)）继续推动这项工作。 SIG-Storage、SIG-Node 和 API 评审人员们进行了多次讨论，以确定设计细节。 Ashutosh Kumar（[sonasingh46](https://github.com/sonasingh46)） 完成了大部分实现并在 Kubernetes 1.24 版本中将其引进到 Alpha 阶段。 <!-- We want to thank the following people for their insightful reviews: Tim Hockin  ([thockin](https://github.com/thockin)) for his guidance on the design, Jing Xu ([jingxu97](https://github.com/jingxu97)), Hemant Kumar ([gnufied](https://github.com/gnufied)), and Michelle Au ([msau42](https://github.com/msau42)) for reviews from SIG Storage side, and Mrunal Patel ([mrunalp](https://github.com/mrunalp)), David Porter ([bobbypage](https://github.com/bobbypage)), Derek Carr ([derekwaynecarr](https://github.com/derekwaynecarr)), and Danielle Endocrimes ([endocrimes](https://github.com/endocrimes)) for reviews from SIG Node side. --> 我们要感谢以下人员的评审：Tim Hockin（[thockin](https://github.com/thockin)）对设计的指导； 来自 SIG-Storage 的 Jing Xu（[jingxu97](https://github.com/jingxu97)）、 Hemant Kumar（[gnufied](https://github.com/gnufied)） 和 Michelle Au（[msau42](https://github.com/msau42)）的评论； 以及 Mrunal Patel（[mrunalp](https://github.com/mrunalp)）、 David Porter（[bobbypage](https://github.com/bobbypage)）、 Derek Carr（[derekwaynecarr](https://github.com/derekwaynecarr)） 和 Danielle Endocrimes（[endocrimes](https://github.com/endocrimes)）来自 SIG-Node 方面的评论。 <!-- There are many people who have helped review the design and implementation along the way. We want to thank everyone who has contributed to this effort including the about 30 people who have reviewed the [KEP](https://github.com/kubernetes/enhancements/pull/1116) and implementation over the last couple of years. --> 在此过程中，有很多人帮助审查了设计和实现。我们要感谢所有为此做出贡献的人， 包括在过去几年中审核 [KEP](https://github.com/kubernetes/enhancements/pull/1116) 和实现的大约 30 人。 <!-- This feature is a collaboration between SIG Storage and SIG Node. For those interested in getting involved with the design and development of any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). For those interested in getting involved with the design and development of the components that support the controlled interactions between pods and host resources, join the [Kubernetes Node SIG](https://github.com/kubernetes/community/tree/master/sig-node). --> 此特性是 SIG-Storage 和 SIG-Node 之间的协作。 对于那些有兴趣参与 Kubernetes Storage 系统任何部分的设计和开发的人， 请加入 [Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)（SIG-Storage）。 对于那些有兴趣参与支持 Pod 和主机资源之间受控交互的组件的设计和开发的人， 请加入 [Kubernetes Node SIG](https://github.com/kubernetes/community/tree/master/sig-node)。 </ins>

This is a Feature Request This page blog/2022-05-20-non-graceful-node- has no Chinese version What would you like to be Translate Chinese version for blog/2022-05-20-non-graceful-node- Comments /language zh /assign
/triage accepted


Question: • [VirtualBox](https://www.virtualbox.org/wiki/Downloads) <del> {{< note >}} minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 </del> <ins> Minikubeは、VMではなくホストでKubernetesコンポーネントを実行する`--vm-driver=none`オプションもサポートしています。 </ins> このドライバーを使用するには、[Docker](https://www.docker.com/products/docker-desktop)とLinux環境が必要ですが、ハイパーバイザーは不要です。 <del> noneドライバーを使用する場合は、[Docker](https://www.docker.com/products/docker-desktop)からdockerのaptインストールを使用することをおすすめします。 dockerのsnapインストールは、minikubeでは機能しません。 {{< /note >}} </del> <ins> Debian系のLinuxで`none`ドライバーを使用する場合は、snapパッケージではなく`.deb`パッケージを使用してDockerをインストールしてください。snapパッケージはMinikubeでは機能しません。 [Docker](https://www.docker.com/products/docker-desktop)から`.deb`パッケージをダウンロードできます。 {{< caution >}} `none` VMドライバーは、セキュリティとデータ損失の問題を引き起こす可能性があります。 `--vm-driver=none`を使用する前に、詳細について[このドキュメント](https://minikube.sigs.k8s.io/docs/reference/drivers/none/) を参照してください。 {{< /caution >}} MinikubeはDockerドライバーと似たような`vm-driver=podman`もサポートしています。Podmanを特権ユーザー権限(root user)で実行することは、コンテナがシステム上の利用可能な機能へ完全にアクセスするための最もよい方法です。 {{< caution >}} `podman` ドライバーは、rootでコンテナを実行する必要があります。これは、通常のユーザーアカウントが、コンテナの実行に必要とされるすべてのOS機能への完全なアクセスを持っていないためです。 {{< /caution >}} </ins> ### パッケージを利用したMinikubeのインストール

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 Update tasks/tools/install- to follow v1.17 of the original (Englist) text. Why is this needed content/ja/docs/tasks/tools/install- is outdated. Comments /language ja /good-first-issue File to update Original https://v1- diff between translated and v1.17 Note Currently, we use branch. Please open a PR targeting the branch. ref If you have a question, feel free to ask us at #kubernetes-docs-ja channel.
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 : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update tasks/tools/install- to follow v1.17 of the original (Englist) text. content/ja/docs/tasks/tools/install- is outdated. /language ja /good-first-issue Currently, we use branch. Please open a PR targeting the branch. 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
/assign
/close
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:
message: | 5 days of incredible opportunites to collaborate, learn + share with the entire community!
 May 16 - 20, 2022.  - name: Kubecon 2022 NA startTime: 2022-10-17T00:00:00 # Added in https://github.com/kubernetes/website/pull/36107 endTime: 2022-10-29T00:00:00 style: >- background: linear-gradient(135deg,rgb(2,3,129) 0%,rgb(114,114,255) 100%); color: #fff; title: |  KubeCon + CloudNativeCon NA 2022 Detroit, Michigan + Virtual. message: | 5 days of incredible opportunites to collaborate, learn + share with the entire community!
 October 24 - 28, 2022.

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 An announcement banner for KubeCon NA 2022 <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed KubeCon NA 2022 is around the corner. It is important we start informing the community about this amazing event by displaying a banner on the Kubernetes website. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --This change will need steering committee approval. I would set the banner to start on the 22nd of August and end on the 28th of October, 2022 at 18:00 CEST /priority important-soon
Thanks for filing this I think the banner should start on the 15th of October. How does that sound? /priority important-longterm /remove-priority important-soon
15th sounds great!
/triage accepted
/assign


Question: sudo apt-get update sudo apt-get install -y kubectl ``` <ins> {{< note >}} In releases older than Debian 12 and Ubuntu 22.04, `/etc/apt/keyrings` does not exist by default. You can create this directory if you need to, making it world-readable but writeable only by admins. {{< /note >}} </ins> {{% /tab %}}

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The documentation recommends installing the repository signing key to . This is contrary to the recommendation in the Debian documentation : There is no keyring package in the k8s repository that would replace and (when necessary) update a keyring installed to , so the keyring should go to . Proposed Solution: Replace with in the instructions for setting up the apt package repository. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This is a reasonable change. We could also mention that and document how to make sure it exists. /language en /sig cluster-lifecycle /remove-kind bug It's not exactly a bug, and it's not a feature either. Let's not choose. /triage accepted /priority backlog /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 : This is a reasonable change. We could also mention that In releases older than Debian 12 and Ubuntu 22.04, does not exist by default. /sig cluster-lifecycle /priority backlog /help 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
please update the issue description to not mention updating the localized versions. Localization teams pick those changes up and will file their own issues if needed.
I've removed the mention of localization.
I will give a try on this. /assign
Thank you very much! :slightlysmilingface:


Question: - [cgroups](https://man7.org/linux/man-pages/man7/cgroups.7.html)についてもっと学習しましょう。 - [コンテナランタイム](/ja/docs/concepts/architecture/cri)についてもっと学習しましょう。 <del> - [cgroupドライバー](/docs/setup/production-environment/container-runtimes#cgroup-drivers)についてもっと学習しましょう。 </del> <ins> - [cgroupドライバー](/ja/docs/setup/production-environment/container-runtimes#cgroup-drivers)についてもっと学習しましょう。 </ins>

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. --Update Japanese translation Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref. /language ja
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I want to work on this. Have you already started working on it? It seems that some pages linked from here are not translated yet: dockershim-removal template For now, I'm going to start working on dockershim related contents. Feel free to notify me if this conflicts with your work.
I'll assign myself since you haven't assigned youself to this issue. Please tell me if this conflicts with you work. /assign


Question: communicates with). 1. (Recommended) If you have plans to upgrade this single control-plane `kubeadm` cluster <del> to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer. </del> <ins> to [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) you should specify the `--control-plane-endpoint` to set the shared endpoint for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer. </ins> 1. Choose a Pod network add-on, and verify whether it requires any arguments to be passed to `kubeadm init`. Depending on which third-party provider you choose, you might need to set the `--pod-network-cidr` to

Please note: This issue is not suitable for new contributors since you need some familiarity with how Kubernetes works. The Kubernetes website currently lacks a guide on creating Windows/Linux nodes. See for more details. SIG Windows opted to remove the guide that did exist for creating Windows nodes, in PR Write a new task page about creating nodes for all operating systems. This could, potentially, be in a tabbed format as mentions in the issue referenced above. We would also need the entry reflected on the creates the Linux task page by moving / refactoring the existing "join node" contents from the "create a cluster" page: creates the Windows task page by taking the content from at the end of the Windows page we add note/disclaimer whatever that says that CNI on Windows needs special handling and we link to the various CNI choices at: adds tabs in the to choose between OS for joining nodes. /priority backlog /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 : Problem Statement: /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted Thank you for filing this
/sig cluster-lifecycle
If you know how to set up new nodes (with, at least, the tool): you can work on this issue. You don't need anyone's permission to open a pull request. All we ask is that you read our and that you abide by the project's code of conduct.
/assign
Relevant to
Are you still working on this issue?
/assign sending PR soon.


Question: communicates with). 1. (Recommended) If you have plans to upgrade this single control-plane `kubeadm` cluster <del> to high availability you should specify the `--control-plane-endpoint` to set the shared endpoint for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer. </del> <ins> to [high availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) you should specify the `--control-plane-endpoint` to set the shared endpoint for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer. </ins> 1. Choose a Pod network add-on, and verify whether it requires any arguments to be passed to `kubeadm init`. Depending on which third-party provider you choose, you might need to set the `--pod-network-cidr` to

/priority important-longterm
Relevant to
/retitle Write new task pages about creating Kubernetes nodes
/cc
Done in PR /close
Closing this issue. <detailsIn response to : Done in PR 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: } body.cid-community .community-section#meetups { <del> width: 100vw; </del> <ins> width: 100%; </ins> max-width: initial; margin-top: 0;

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Proposed Solution: Page to Update: /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
During my browsing of the docs on a mobile device, I came across a similar situation on another page, specifically in the . It seems this issue might be widespread and could be affecting multiple pages, not limited to just the community page. Perhaps we could explore identifying a CSS fix that enhances the rendering of pages with wider elements. This way, we can efficiently resolve the problem and improve the overall user experience.
/area web-development
I tried making some changes on the source, A simple overflow - x in the right places seems to solve the problem. ! However, I'd often come across such problems when the scaling isn't managed properly. I'm sure there are better ways to get this problem fixed.
I see, In that case I'll try to find anymore pages that might be having the same issue.
Similar issue is present in case study


Question: sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl ``` <ins> {{< note >}} In releases older than Debian 12 and Ubuntu 22.04, `/etc/apt/keyrings` does not exist by default. You can create this directory if you need to, making it world-readable but writeable only by admins. {{< /note >}} </ins> {{% /tab %}} {{% tab name="Red Hat-based distributions" %}}


Question: [permalinks] blog = "/:section/:year/:month/:day/:slug/" <ins> [sitemap] filename = "sitemap.xml" priority = 0.75 </ins> # Be explicit about the output formats. We (currently) only want an RSS feed for the home page. [outputs] home = [ "HTML", "RSS", "HEADERS" ]

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The Kubernetes website generates a sitemap. Let's highlight specific pages using priority weighting: (and any localization that copies the priority weight) (and any localization that copies the priority weight) (and any localization that copies the priority weight) Why is this needed: Making this change helps search engines understand what pages the Kubernetes project sees as important. Comments /kind feature


Question: performed periodically by the [kubelet](/docs/admin/kubelet/) on a Container. To perform a diagnostic, the kubelet calls a <del> [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler) implemented by </del> <ins> [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core) implemented by </ins> the Container. There are three types of handlers: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core):

This is a Bug Report <!--Required Information--Problem: The page has a section. This section contains link to a Handler documentation. This link does not work: Proposed Solution: Update the link to the handler documentation on the page in the section of the page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/kind bug /language en
/assign I'm going to fix the link to the correct one.


Question: 쿠버네티스는 CNCF의 행동 강령을 따르고 있습니다.  커밋 71b12a2   커밋 fff715fb0  에 따라 CNCF 행동 강령의 내용이 아래에 복제됩니다. 만약 최신 버전이 아닌 경우에는 이슈를 제기해 주세요.

This is a Feature Request Korean Localization for branch. What would you like to be Any localization contributions for Korean. Comments This issue is to notify the schedule of Korean localization to contributors. is the current work branch for Korean localization. Important dates A Korean localization work branch is merged to branch after we complete around 3~4 weeks job. PR Freeze: 01/16 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 01/19 (merge to main branch)  2~3 , main . PR : 01/16 ( PR , PR ) : 01/19 (main , k8s.io ) /language ko /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : ## In English is the current work branch for Korean localization.A Korean localization work branch is merged to branch after we complete around 3~4 weeks job. PR Freeze: 01/16 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 01/19 (merge to main branch) PR : 01/16 ( PR , PR ) : 01/19 (main , k8s.io ) /help </details
/milestone dev-1.26-ko.1
/triage accepted
Outdated Korean contents in the dev-1.26-ko.1


Question: nc 127.0.0.1 6443 ``` <del> The pod network plugin you use (see below) may also require certain ports to be </del> <ins> The pod network plugin you use may also require certain ports to be </ins> open. Since this differs with each pod network plugin, please see the documentation for the plugins about what port(s) those need.

Under the , this following statement is misleading because nothing about pod network plugin was discussed on that page: The text in parenthesis should be taken out to avoid confusion.
I think it makes sense to remove the text. /help /sig cluster-lifecycle
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 : The text in parenthesis (see below) should be taken out to avoid confusion. /sig cluster-lifecycle </details
/language en /kind bug /priority backlog Anyone is welcome to open a PR that omits the text “(see below)”.
/triage accepted
I'll open a PR for it.


Question: other = "否" [feedback_question] <del> other = "此页是否对您有帮助？" </del> <ins> other = "此页是否对你有帮助？" </ins> [feedback_yes] other = "是"

What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language zh-cn
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language zh-cn Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig-docs
/language zh
/triage accepted /assign


Question: <!-- overview --> <del> In Kubernetes, some objects are *owners* of other objects. For example, a {{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of Pods. These owned objects are *dependents* </del> <ins> In Kubernetes, some {{< glossary_tooltip text="objects" term_id="Object" >}} are *owners* of other objects. For example, a {{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of {{<glossary_tooltip text="Pods" term_id="pod">}}. These owned objects are *dependents* </ins> of their owner. Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/) mechanism that some resources also use. For example, consider a Service that <del> creates `EndpointSlice` objects. The Service uses labels to allow the control plane to </del> <ins> creates `EndpointSlice` objects. The Service uses {{<glossary_tooltip text="labels" term_id="label">}} to allow the control plane to </ins> determine which `EndpointSlice` objects are used for that Service. In addition to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid

This is a Feature Request What would you like to be There are terms that can use the addition of a glossary tooltip to show the meaning of the said term. Some terms can add into What's next section like: ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, and ReplicationControllers. Why is this needed This will enhance user experience and bring more clarity and less confusion. Comments Page to update:
/sig docs /language en /assign
This issue is fixed here .
IMO this is an acceptable change but I'd like another org member to chime in
/triage accepted
Hi Thanks for sharing your feedback and triage accepted.


Question: Issues should be sorted into different buckets of work using the following labels and definitions. If an issue doesn't have enough information to identify a problem that can be researched, reviewed, or worked on (i.e. the issue doesn't fit into any of the categories below) you should close the issue with a comment explaining why it is being closed. ### Needs Clarification <del> * Issues that need more information from the original submitter to make them actionable.  Issues with this label that aren't followed up within a week may be closed. </del> <ins> * Issues that need more information from the original submitter to make them actionable.  Issues with this label that aren't followed up within a week may be closed. </ins> ### Actionable * Issues that can be worked on with current information (or may need a comment to explain what needs to be done to make it more clear)

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:


Question: response for the `/api` and `/apis` endpoint is an unaggregated discovery document. <del> The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2.json) </del> <ins> The [discovery document](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2beta1.json) </ins> for the built-in resources can be found in the Kubernetes GitHub repository. This Github document can be used as a reference of the base set of the available resources if a Kubernetes cluster is not available to query.

As per title the following page contains a broken link to discovery document. See highlight here:
Page reported in issue: /language en /kind bug
/sig docs
I want to work on that. /assign
fixed this issue in PTAL!!


Question: sudo install minikube /usr/local/bin/ ``` <ins> ### Homebrewを利用したMinikubeのインストール 別の選択肢として、Linux [Homebrew](https://docs.brew.sh/Homebrew-on-Linux)を利用してインストールできます。 ```shell brew install minikube ``` </ins> {{% /tab %}} {{% tab name="macOS" %}} ### kubectlのインストール


Question: # List Names of Pods that belong to Particular RC # "jq" command useful for transformations that are too complex for jsonpath <del> $ sel=$(./kubectl get rc <rc-name> --output=json | jq -j '.spec.selector | to_entries | .[] | "(.key)=(.value),"') </del> <ins> $ sel=$(kubectl get rc <rc-name> --output=json | jq -j '.spec.selector | to_entries | .[] | "(.key)=(.value),"') </ins> $ sel=${sel%?} # Remove trailing comma <del> $ pods=$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})` </del> <ins> $ pods=$(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name}) $ echo $pods </ins> # Check which nodes are ready <del> $ kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'| tr ';' "n"  | grep "Ready=True" </del> <ins> $ kubectl get nodes -o jsonpath='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}'| tr ';' "n"  | grep "Ready=True" </ins> ``` ## Modifying and Deleting Resources

Does not run under as defined in the docs. This is the fix: I think wanted me to do one work on the cheat anyways ... Just leaving this here for now.


Question:
 {{< note >}}
If you are trying this after the previous section, you may have deleted the Service exposing the Deployment. In that case, please expose the Deployment again using the following command:

kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080

If you are trying this after the previous section , then you may have deleted the service you created, or have created a Service of <tt>type: NodePort</tt>. In this section, it is assumed that a service with <tt>type: LoadBalancer</tt> is created for the kubernetes-bootcamp Deployment.

If you have not deleted the Service created in the previous section, first delete that Service and then run the following command to create a new Service with its <tt>type</tt> set to <tt>LoadBalancer</tt>:

kubectl expose deployment/kubernetes-bootcamp --type="LoadBalancer" --port 8080
  {{< /note >}}

I find this small bit in the scale-intro a bit confusing: and then directly under that paragraph, there is this highlighted "Note" section, that states: TL;DR; Paragraph instructs me to delete the "NodePort" service, because this sections expects a "Loadbalancer" service to be active. Highlighted Note instructs me to re-create the "NodePort" service after the "Loadbalancer" service was created.
Page reported in issue (based on the issue title): /language en
/retitle Conflicting guidance regarding Service creation in "Scale Your App" tutorial /kind bug
Removing this ambiguity will improve the tutorial's usability. /priority backlog /triage accepted
I will try to help with this. /assign


Question: 尽管 Daemon Pods 遵循[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration) 规则，根据相关特性，控制器会自动将以下容忍度添加到 DaemonSet Pod： <del> | 容忍度键名                               | 效果       | 版本   | 描述                                                          | </del> <ins> | 容忍度键名                               | 效果       | 版本    | 描述                                                         | </ins> | ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | | `node.kubernetes.io/not-ready`           | NoExecute  | 1.13+   | 当出现类似网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 | <del> | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+    | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 | </del> <ins> | `node.kubernetes.io/unreachable`         | NoExecute  | 1.13+   | 当出现类似于网络断开的情况导致节点问题时，DaemonSet Pod 不会被逐出。 | </ins> | `node.kubernetes.io/disk-pressure`       | NoSchedule | 1.8+    | | | `node.kubernetes.io/memory-pressure`     | NoSchedule | 1.8+    | | | `node.kubernetes.io/unschedulable`       | NoSchedule | 1.12+   | DaemonSet Pod 能够容忍默认调度器所设置的 `unschedulable` 属性.  |

“ DaemonSet spec.template.“ “”“”
Mind propose a fix?
/triage accepted
/language zh (I presume)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /language zh (I presume) 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
yes,this is chinese languge,“”change to“”
/assign


Question: [main_read_more] other = "Przeczytaj więcej" <ins> [not_applicable] # Localization teams: it's OK to use a longer text here other = "nie dotyczy" </ins> [note] other = "Informacja:"

What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language pl
/sig docs
/triage accepted


Question: In general, Pods remain until a human or {{< glossary_tooltip term_id="controller" text="controller" >}} process explicitly removes them. <del> The control plane cleans up terminated Pods (with a phase of `Succeeded` or </del> <ins> The control plane cleans up terminated Pods (with a phase of `Succeeded` or </ins> `Failed`), when the number of Pods exceeds the configured threshold (determined by `terminated-pod-gc-threshold` in the kube-controller-manager). This avoids a resource leak as Pods are created and terminated over time.


Question: Install and configure prerequisites: ```shell <ins> # Create the .conf file to load the modules at bootup cat <<EOF | sudo tee /etc/modules-load.d/crio.conf overlay br_netfilter EOF </ins> sudo modprobe overlay sudo modprobe br_netfilter

Problem: The documentation references loading the overlay and brnetfilter kernel modules at both of these locations: Modules do not persist reboots Documentation states that they will persist across reboots. Cluster will fail pre-flight if modules are not loaded Proposed Solution: In installation prerequisites add: cat <<EOF | sudo tee /etc/modules- overlay brnetfilter EOF This is correct in the containerd installation prerequisites but appears missing from CRI-O. Modules do not appear to persist across reboots unless /etc/modules-load.d has a config reference to load at boot. In the example given at add: cat <<EOF | sudo tee /etc/modules- br_netfilter EOF
a PR with the fix is welcome. /sig node cluster-lifecycle /triage accepted
Thank you PRs submitted.
please close this once the PRs merge. or add in one of the PR descriptions.


Question: other = "suggest an improvement" [layouts_docs_partials_feedback_issue] <del> other = "Open an issue in the GitHub repo if you want to " </del> <ins> other = """Open an issue in the [GitHub Repository](https://www.github.com/kubernetes/website/) if you want to """ </ins> [layouts_docs_partials_feedback_or] other = "or"

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. --I want to add a hyperlink to the "GitHub repo". ! Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Link to be :
/sig docs
/language en /triage needs-information
Hi Could you please describe on which page of the documentation you are facing issue?
This is under the feedback section of too many pages. We have to change all of them.
I think we need not change much here, A slight change in i18n markdown should do the trick
/assign I'll do that
/remove-triage needs-information
Thanks for raising the PR . Also, Please focus on those issues first which have label.
/triage accepted /priority backlog


Question: * GCEPersistentDisk * AWSElasticBlockStore <ins> * AzureFile * FC (Fibre Channel) </ins> * NFS * iSCSI * RBD (Ceph Block Device) <ins> * CephFS * Cinder (OpenStack block storage) </ins> * Glusterfs <ins> * VsphereVolume </ins> * HostPath (single node testing only -- local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: The command to create the sock-shop application error out (it's also not necessary to create the namespace beforehand as that is already define in ): Proposed Solution: Change the command to: Page to Update: Kubernetes Version: 1.6.1
I think this is an issue that needs to be fixed in socks shop.
This merged PR should resolve the issue


Question: ```shell sudo apt-get update <del> sudo apt-get install -y apt-transport-https ca-certificates curl </del> <ins> sudo apt-get install -y ca-certificates curl </ins> ``` <ins> {{< note >}} If you use Debian 9 (stretch) or earlier you would also need to install `apt-transport-https`: ```shell sudo apt-get install -y apt-transport-https ``` {{< /note >}} </ins> 2. Download the Google Cloud public signing key: ```shell

Hi, apt-transport-https is a dummy package since apt 1.5, means it's not needed anymore as of Debian 10 and Ubuntu 18.04.
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 Linux kubectl package install instructions recommend dummy package This issue is about /kind cleanup /language en The fix would be to omit mentioning , provided that we are confident that all readers are using at least Debian 10. I think the Ubuntu side of things we can take for granted. /priority awaiting-more-evidence
We can also rather add a piece of text, something like: sh sudo apt-get install -y apt-transport-https '``
- would you be willing to update the issue description to incorporate the idea from ?
I have this PR raised. I hope that helps.
/assign
Sorry, didn't see this earlier. However, looks like already did exactly this in .


Question: it is required by kubectl. When present, the value of this annotation must be a comma separated list of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`. <ins> ### applyset.kubernetes.io/contains-group-resources (deprecated) {#applyset-kubernetes-io-contains-group-resources} Type: Annotation Example: `applyset.kubernetes.io/contains-group-resources: "certificates.cert-manager.io,configmaps,deployments.apps,secrets,services"` Used on: Objects being used as ApplySet parents. For Kubernetes version {{< skew currentVersion >}}, you can use this annotation on Secrets, ConfigMaps, or custom resources if the CustomResourceDefinition defining them has the `applyset.kubernetes.io/is-parent-type` label. Part of the specification used to implement [ApplySet-based pruning in kubectl](/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune). This annotation is applied to the parent object used to track an ApplySet to optimize listing of ApplySet member objects. It is optional in the ApplySet specification, as tools can perform discovery or use a different optimization. However, in Kubernetes version {{< skew currentVersion >}}, it is required by kubectl. When present, the value of this annotation must be a comma separated list of the group-kinds, in the fully-qualified name format, i.e. `<resource>.<group>`. {{< note >}} This annotation is currently deprecated and replaced by [`applyset.kubernetes.io/contains-group-kinds`](#applyset-kubernetes-io-contains-group-kinds), support for this will be removed in applyset beta or GA. {{< /note >}} </ins> ### applyset.kubernetes.io/id (alpha) {#applyset-kubernetes-io-id} Type: Label

I'm not entirely sure if this is a bug, or if the documentation is just inaccurate/lacking some context, but it's at the very least a bit confusing. If you check the documentation for the well-known labels, etc., you can find the documentation for the annotation . ! However, when I try to reference a parent object with the option to without this annotation, it complains about the annotation missing: At this point my parent resource is declared as: It appears that I can set either one of the two ( or ) on the resource and will accept it; only in the latter case it appears to be copying the "resources" annotation to the add the "kinds" annotation. To phrase it another way: Setting the "kinds" annotation seems like the right way to go (but not what the documentation suggests), and setting the "resources" annotation works as well but you'll also end up with the "kinds" annotation afterwards. I expect the documentation and kubectl to align. Point at a resource that doesn't have the required annotations. No response <details</detailsnocloud No response No response No response No response
/sig docs /sig cli
This was changed in the code by and it seems that document needs changes to reflect this. Thank you bringing this issue /triage accepted
I think this should be transferred to the k/website so that the right annotation is recorded. /transfer wbsite
Something went wrong or the destination repo kubernetes/wbsite does not exist. <detailsIn response to : I think this should be transferred to the k/website so that the right annotation is recorded. /transfer wbsite 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
my bad !! /transfer website
/assign
Due to an implementation error with , in k8s v1.29 release this annotation was deprecated and the same is replaced by annotation. made this changes.
PR Raised .


Question: hostNetwork: true containers: - name: konnectivity-server-container <del> image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16 </del> <ins> image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.32 </ins> command: ["/proxy-server"] args: [ "--logtostderr=true",

This is a Bug Report Problem: The current documentation is still referring to the non-official Kubernetes container image repository introduced starting from v1.25 () and referring to an outdated version. Proposed Solution: I can take care of the PR updating the content. Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: <ins> apiVersion: apps/v1 kind: Deployment metadata: name: retainkeys-demo spec: selector: matchLabels: app: nginx strategy: rollingUpdate: maxSurge: 30% template: metadata: labels: app: nginx spec: containers: - name: retainkeys-demo-ctr image: nginx </ins>

This is a Feature Request What would you like to be Localize to Spanish Why is this needed There is no Spanish localization for this file. Comments /triage accepted /kind feature /language es /sig docs /area localization
/assign
/unassign


Question: #### Terminating <del> {{< feature-state for_k8s_version="v1.20" state="alpha" >}} </del> <ins> {{< feature-state for_k8s_version="v1.22" state="beta" >}} </ins> `Terminating` is a condition that indicates whether an endpoint is terminating. For pods, this is any pod that has a deletion timestamp set.

This is a Bug Report <!--Required Information--The FEATURE STATE for and is mentioned under which is wrong, As per mention in the the correct Feature state for is . Proposed Solution: Update the Feature State of Serving and Terminating from to . Page to Update: <!--Additional Information:--EndpointSliceTerminatingCondition: Enables EndpointSlice and condition fields.
/assign
Fixed it here:
/language en /triage accepted


Question: $ kubectl get services --sort-by=.metadata.name # List pods Sorted by Restart Count <del> $ kubectl get pods --sort-by=.status.containerStatuses[0].restartCount </del> <ins> $ kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' </ins> # Get the version label of all pods with label app=cassandra $ kubectl get pods --selector=app=cassandra rc -o 'jsonpath={.items[*].metadata.labels.version}'


Question: <ins> --- title: リース content_type: concept weight: 30 --- <!-- overview --> しばしば分散システムでは共有リソースをロックしたりノード間の活動を調整する機構として"リース"が必要になります。 Kubernetesでは、"リース"のコンセプトは`coordination.k8s.io`APIグループの`Lease`オブジェクトに表されていて、ノードのハートビートやコンポーネントレベルのリーダー選出といったシステムにとって重要な機能に利用されています。 <!-- body --> ## ノードハートビート Kubernetesでは、kubeletのノードハートビートをKubernetes APIサーバーに送信するのにLease APIが使われています。 各`Node`ごとに、`kube-node-lease`名前空間にノードとマッチする名前の`Lease`オブジェクトが存在します。 内部的には、kubeletのハートビートはこの`Lease`オブジェクトに対するUPDATEリクエストであり、Leaseの`spec.renewTime`フィールドを更新しています。 Kubernetesのコントロールプレーンはこのフィールドのタイムスタンプを見て、`Node`が利用可能かを判断しています。 詳しくは[Node Leaseオブジェクト](/ja/docs/concepts/architecture/nodes/#heartbeats)をご覧ください。 ## リーダー選出 Kubernetesでは、あるコンポーネントのインスタンスが常に一つだけ実行されていることを保証するためにもリースが利用されています。 これは`kube-controller-manager`や`kube-scheduler`といったコントロールプレーンのコンポーネントで、一つのインスタンスのみがアクティブに実行され、その他のインスタンスをスタンバイ状態とする必要があるような冗長構成を組むために利用されています。 ## APIサーバーのアイデンティティー {{< feature-state for_k8s_version="v1.26" state="beta" >}} Kubernetes v1.26から、各`kube-apiserver`はLease APIを利用して自身のアイデンティティーをその他のシステムに向けて公開するようになりました。 それ自体は特に有用ではありませんが、何台の`kube-apiserver`がKubernetesコントロールプレーンを稼働させているのかをクライアントが知るためのメカニズムを提供します。 kube-apiserverリースが存在することで、各kube-apiserver間の調整が必要となる可能性がある将来の機能が使えるようになります。 `kube-system`名前空間の`kube-apiserver-<sha256-hash>`という名前のリースオブジェクトを確認することで、各kube-apiserverが所有しているLeaseを確認することができます。 また、`k8s.io/component=kube-apiserver`ラベルセレクターを利用することもできます。 ```shell $ kubectl -n kube-system get lease -l k8s.io/component=kube-apiserver NAME                                        HOLDER                                                                           AGE kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a   kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4   5m33s kube-apiserver-dz2dqprdpsgnm756t5rnov7yka   kube-apiserver-dz2dqprdpsgnm756t5rnov7yka_84f2a85d-37c1-4b14-b6b9-603e62e4896f   4m23s kube-apiserver-fyloo45sdenffw2ugwaz3likua   kube-apiserver-fyloo45sdenffw2ugwaz3likua_c5ffa286-8a9a-45d4-91e7-61118ed58d2e   4m43s ``` リースの名前に使われているSHA256ハッシュはkube-apiserverのOSホスト名に基づいています。各kube-apiserverはクラスター内で一意なホスト名を使用するように構成する必要があります。 同じホスト名を利用する新しいkube-apiserverインスタンスは、新しいリースオブジェクトを作成せずに、既存のLeaseを新しいインスタンスのアイデンティティーを利用して引き継ぎます。 kube-apiserverが使用するホスト名は`kubernetes.io/hostname`ラベルの値で確認できます。 ```shell $ kubectl -n kube-system get lease kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a -o yaml ``` ```yaml apiVersion: coordination.k8s.io/v1 kind: Lease metadata: creationTimestamp: "2022-11-30T15:37:15Z" labels: k8s.io/component: kube-apiserver kubernetes.io/hostname: kind-control-plane name: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a namespace: kube-system resourceVersion: "18171" uid: d6c68901-4ec5-4385-b1ef-2d783738da6c spec: holderIdentity: kube-apiserver-c4vwjftbvpc5os2vvzle4qg27a_9cbf54e5-1136-44bd-8f9a-1dcd15c346b4 leaseDurationSeconds: 3600 renewTime: "2022-11-30T18:04:27.912073Z" ``` すでに存在しなくなったkube-apiserverの期限切れリースは、1時間後に新しいkube-apiserverによってガベージコレクションされます。 </ins>

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. --Translate into Japanese Why is this needed 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


Question: Help	 Labels	 Const Labels	  Deprecated Version

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: documents metrics for Kubernetes v1.26 but that's incorrect because at the time I'm filing this the live documentation is for Kubernetes v1.25 Proposed Solution: Revert whichever PR bumped the document too early or do a careful partial revert that only omits the v1.26 changes Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig instrumentation /language en If v1.26 gets released before we fix this, it's OK to close the issue. Consider a backport to the v1.25 docs, though.
/assign
/triage accepted
/assign


Question: #### Manually provisioning a Regional PD PersistentVolume Dynamic provisioning is possible using a <del> [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce). </del> <ins> [StorageClass for GCE PD](/docs/concepts/storage/storage-classes/#gce-pd). </ins> Before creating a PersistentVolume, you must create the persistent disk: ```shell

Problem: The text on is not working, it should point to these Check the page for the problem. Page to Update: Proposed Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text StorageClass for GCE PD 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, it should point to these Check the page for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the link on the text StorageClass for GCE PD 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
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: "k8s.gcr.io 重定向到 registry.k8s.io - 用户须知" date: 2023-03-10T17:00:00.000Z slug: image-registry-redirect --- <!-- layout: blog title: "k8s.gcr.io Redirect to registry.k8s.io - What You Need to Know" date: 2023-03-10T17:00:00.000Z slug: image-registry-redirect --> <!-- **Authors**: Bob Killen (Google), Davanum Srinivas (AWS), Chris Short (AWS), Frederico Muñoz (SAS Institute), Tim Bannister (The Scale Factory), Ricky Sadowski (AWS), Grace Nguyen (Expo), Mahamed Ali (Rackspace Technology), Mars Toktonaliev (independent), Laura Santamaria (Dell), Kat Cosgrove (Dell) --> **作者**：Bob Killen (Google)、Davanum Srinivas (AWS)、Chris Short (AWS)、Frederico Muñoz (SAS Institute)、Tim Bannister (The Scale Factory)、Ricky Sadowski (AWS)、Grace Nguyen (Expo)、Mahamed Ali (Rackspace Technology)、Mars Toktonaliev（独立个人）、Laura Santamaria (Dell)、Kat Cosgrove (Dell) **译者**：Michael Yao (DaoCloud) <!-- On Monday, March 20th, the k8s.gcr.io registry [will be redirected to the community owned registry](https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/), **registry.k8s.io** . --> 3 月 20 日星期一，k8s.gcr.io 仓库[被重定向到了社区拥有的仓库](https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)： **registry.k8s.io** 。 <!-- ## TL;DR: What you need to know about this change - On Monday, March 20th, traffic from the older k8s.gcr.io registry will be redirected to registry.k8s.io with the eventual goal of sunsetting k8s.gcr.io. - If you run in a restricted environment, and apply strict domain name or IP address access policies limited to k8s.gcr.io, **the image pulls will not function** after k8s.gcr.io starts redirecting to the new registry. --> ## 长话短说：本次变更须知   {#you-need-to-know} - 3 月 20 日星期一，来自 k8s.gcr.io 旧仓库的流量被重定向到了 registry.k8s.io， 最终目标是逐步淘汰 k8s.gcr.io。 - 如果你在受限的环境中运行，且你为 k8s.gcr.io 限定采用了严格的域名或 IP 地址访问策略， 那么 k8s.gcr.io 开始重定向到新仓库之后镜像拉取操作将不起作用。 <!-- - A small subset of non-standard clients do not handle HTTP redirects by image registries, and will need to be pointed directly at registry.k8s.io. - The redirect is a stopgap to assist users in making the switch. The deprecated k8s.gcr.io registry will be phased out at some point. **Please update your manifests as soon as possible to point to registry.k8s.io**. - If you host your own image registry, you can copy images you need there as well to reduce traffic to community owned registries. --> - 少量非标准的客户端不会处理镜像仓库的 HTTP 重定向，将需要直接指向 registry.k8s.io。 - 本次重定向只是一个协助用户进行切换的权宜之计。弃用的 k8s.gcr.io 仓库将在某个时间点被淘汰。 **请尽快更新你的清单，尽快指向 registry.k8s.io。** - 如果你托管自己的镜像仓库，你可以将需要的镜像拷贝到自己的仓库，这样也能减少到社区所拥有仓库的流量压力。 <!-- If you think you may be impacted, or would like to know more about this change, please keep reading. --> 如果你认为自己可能受到了影响，或如果你想知道本次变更的更多相关信息，请继续阅读下文。 <!-- ## How can I check if I am impacted? To test connectivity to registry.k8s.io and being able to pull images from there, here is a sample command that can be executed in the namespace of your choosing: --> ## 若我受到影响该怎样检查？   {#how-can-i-check} 若要测试到 registry.k8s.io 的连通性，测试是否能够从 registry.k8s.io 拉取镜像， 可以在你所选的命名空间中执行类似以下的命令： ```shell kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date ``` <!-- When you run the command above, here’s what to expect when things work correctly: --> 当你执行上一条命令时，若一切工作正常，预期的输出如下： ```none $ kubectl run hello-world -ti --rm --image=registry.k8s.io/busybox:latest --restart=Never -- date Fri Feb 31 07:07:07 UTC 2023 pod "hello-world" deleted ``` <!-- ## What kind of errors will I see if I’m impacted? Errors may depend on what kind of container runtime you are using, and what endpoint you are routed to, but it should present such as `ErrImagePull`, `ImagePullBackOff`, or a container failing to be created with the warning `FailedCreatePodSandBox`. Below is an example error message showing a proxied deployment failing to pull due to an unknown certificate: --> ## 若我受到影响会看到哪种错误？   {#what-kind-of-errors} 出现的错误可能取决于你正使用的容器运行时类别以及你被路由到的端点， 通常会出现 `ErrImagePull`、`ImagePullBackOff` 这类错误， 也可能容器创建失败时伴随着警告 `FailedCreatePodSandBox`。 以下举例的错误消息显示了由于未知的证书使得代理后的部署拉取失败： ```none FailedCreatePodSandBox: Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Head “https://us-west1-docker.pkg.dev/v2/k8s-artifacts-prod/images/pause/manifests/3.8”: x509: certificate signed by unknown authority ``` <!-- ## What images will be impacted? **ALL** images on k8s.gcr.io will be impacted by this change. k8s.gcr.io hosts many images beyond Kubernetes releases. A large number of Kubernetes subprojects host their images there as well. Some examples include the `dns/k8s-dns-node-cache`, `ingress-nginx/controller`, and `node-problem-detector/node-problem-detector` images. --> ## 哪些镜像会受影响？    {#what-images-be-impacted} k8s.gcr.io 上的 **所有** 镜像都会受到本次变更的影响。 k8s.gcr.io 除了 Kubernetes 各个版本外还托管了许多镜像。 大量 Kubernetes 子项目也在其上托管了自己的镜像。 例如 `dns/k8s-dns-node-cache`、`ingress-nginx/controller` 和 `node-problem-detector/node-problem-detector` 这些镜像。 <!-- ## I am impacted. What should I do? For impacted users that run in a restricted environment, the best option is to copy over the required images to a private registry or configure a pull-through cache in their registry. There are several tools to copy images between registries; [crane](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_copy.md) is one of those tools, and images can be copied to a private registry by using `crane copy SRC DST`. There are also vendor-specific tools, like e.g. Google’s [gcrane](https://cloud.google.com/container-registry/docs/migrate-external-containers#copy), that perform a similar function but are streamlined for their platform. --> ## 我受影响了。我该怎么办？   {#what-should-i-do} 若受影响的用户在受限的环境中运行，最好的办法是将必需的镜像拷贝到私有仓库，或在自己的仓库中配置一个直通缓存。 在仓库之间拷贝镜像可使用若干工具： [crane](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_copy.md) 就是其中一种工具，通过使用 `crane copy SRC DST` 可以将镜像拷贝到私有仓库。还有一些供应商特定的工具，例如 Google 的 [gcrane](https://cloud.google.com/container-registry/docs/migrate-external-containers#copy)， 这个工具实现了类似的功能，但针对其平台自身做了一些精简。 <!-- ## How can I find which images are using the legacy registry, and fix them? **Option 1**: See the one line kubectl command in our [earlier blog post](https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/#what-s-next): --> ## 我怎样才能找到哪些镜像正使用旧仓库，如何修复？    {#how-can-i-find-and-fix} **方案 1**： 试试[上一篇博文](https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/#what-s-next)中所述的一条 kubectl 命令： ```shell kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" | tr -s '[[:space:]]' 'n' | sort | uniq -c ``` <!-- **Option 2**: A `kubectl` [krew](https://krew.sigs.k8s.io/) plugin has been developed called [`community-images`](https://github.com/kubernetes-sigs/community-images#kubectl-community-images), that will scan and report any images using the k8s.gcr.io endpoint. If you have krew installed, you can install it with: --> **方案 2**：`kubectl` [krew](https://krew.sigs.k8s.io/) 的一个插件已被开发完成，名为 [`community-images`](https://github.com/kubernetes-sigs/community-images#kubectl-community-images)， 它能够使用 k8s.gcr.io 端点扫描和报告所有正使用 k8s.gcr.io 的镜像。 如果你安装了 krew，你可以运行以下命令进行安装： ```shell kubectl krew install community-images ``` <!-- and generate a report with: --> 并用以下命令生成一个报告： ```shell kubectl community-images ``` <!-- For alternate methods of install and example output, check out the repo: [kubernetes-sigs/community-images](https://github.com/kubernetes-sigs/community-images). **Option 3**: If you do not have access to a cluster directly, or manage many clusters - the best way is to run a search over your manifests and charts for _"k8s.gcr.io"_. --> 对于安装和示例输出的其他方法，可以查阅代码仓库： [kubernetes-sigs/community-images](https://github.com/kubernetes-sigs/community-images)。 **方案 3**：如果你不能直接访问集群，或如果你管理了许多集群，最好的方式是在清单（manifest）和 Chart 中搜索 **"k8s.gcr.io"**。 <!-- **Option 4**: If you wish to prevent k8s.gcr.io based images from running in your cluster, example policies for [Gatekeeper](https://open-policy-agent.github.io/gatekeeper-library/website/) and [Kyverno](https://kyverno.io/) are available in the [AWS EKS Best Practices repository](https://github.com/aws/aws-eks-best-practices/tree/master/policies/k8s-registry-deprecation) that will block them from being pulled. You can use these third-party policies with any Kubernetes cluster. --> **方案 4**：如果你想预防基于 k8s.gcr.io 的镜像在你的集群中运行，可以在 [AWS EKS 最佳实践代码仓库](https://github.com/aws/aws-eks-best-practices/tree/master/policies/k8s-registry-deprecation)中找到针对 [Gatekeeper](https://open-policy-agent.github.io/gatekeeper-library/website/) 和 [Kyverno](https://kyverno.io/) 的示例策略，这些策略可以阻止镜像被拉取。 你可以在任何 Kubernetes 集群中使用这些第三方策略。 <!-- **Option 5**: As a **LAST** possible option, you can use a [Mutating Admission Webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) to change the image address dynamically. This should only be considered a stopgap till your manifests have been updated. You can find a (third party) Mutating Webhook and Kyverno policy in [k8s-gcr-quickfix](https://github.com/abstractinfrastructure/k8s-gcr-quickfix). --> **方案 5**：作为 **最后一个** 备选方案， 你可以使用[修改性质的准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) 来动态更改镜像地址。在更新你的清单之前这只应视为一个权宜之计。你可以在 [k8s-gcr-quickfix](https://github.com/abstractinfrastructure/k8s-gcr-quickfix) 中找到（第三方）可变性质的 Webhook 和 Kyverno 策略。 <!-- ## Why did Kubernetes change to a different image registry? k8s.gcr.io is hosted on a custom [Google Container Registry (GCR)](https://cloud.google.com/container-registry) domain that was set up solely for the Kubernetes project. This has worked well since the inception of the project, and we thank Google for providing these resources, but today, there are other cloud providers and vendors that would like to host images to provide a better experience for the people on their platforms. In addition to Google’s [renewed commitment to donate $3 million](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/) to support the project's infrastructure last year, Amazon Web Services announced a matching donation [during their Kubecon NA 2022 keynote in Detroit](https://youtu.be/PPdimejomWo?t=236). This will provide a better experience for users (closer servers = faster downloads) and will reduce the egress bandwidth and costs from GCR at the same time. --> ## 为什么 Kubernetes 要换到一个全新的镜像仓库？   {#why-did-k8s-change-registry} k8s.gcr.io 托管在一个 [Google Container Registry (GCR)](https://cloud.google.com/container-registry) 自定义的域中，这是专为 Kubernetes 项目搭建的域。自 Kubernetes 项目启动以来， 这个仓库一直运作良好，我们感谢 Google 提供这些资源，然而如今还有其他云提供商和供应商希望托管这些镜像， 以便为他们自己云平台上的用户提供更好的体验。除了去年 Google [捐赠 300 万美金的续延承诺](https://www.cncf.io/google-cloud-recommits-3m-to-kubernetes/)来支持本项目的基础设施外， Amazon Web Services (AWS) 也在[底特律召开的 Kubecon NA 2022 上发言](https://youtu.be/PPdimejomWo?t=236)公布了相当的捐赠金额。 AWS 能为用户提供更好的体验（距离用户更近的服务器 = 更快的下载速度），同时还能减轻 GCR 的出站带宽和成本。 <!-- For more details on this change, check out [registry.k8s.io: faster, cheaper and Generally Available (GA)](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/). --> 有关此次变更的更多详情，请查阅 [registry.k8s.io：更快、成本更低且正式发布 (GA)](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)。 <!-- ## Why is a redirect being put in place? The project switched to [registry.k8s.io last year with the 1.25 release](https://kubernetes.io/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/); however, most of the image pull traffic is still directed at the old endpoint k8s.gcr.io. This has not been sustainable for us as a project, as it is not utilizing the resources that have been donated to the project from other providers, and we are in the danger of running out of funds due to the cost of serving this traffic. --> ## 为什么要设置重定向？   {#why-is-a-redirect} 本项目在[去年发布 1.25 时切换至 registry.k8s.io](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)； 然而，大多数镜像拉取流量仍被重定向到旧端点 k8s.gcr.io。 从项目角度看，这对我们来说是不可持续的，因为这样既没有完全利用其他供应商捐赠给本项目的资源， 也由于流量服务成本而使我们面临资金耗尽的危险。 <!-- A redirect will enable the project to take advantage of these new resources, significantly reducing our egress bandwidth costs. We only expect this change to impact a small subset of users running in restricted environments or using very old clients that do not respect redirects properly. --> 重定向将使本项目能够利用这些新资源的优势，从而显著降低我们的出站带宽成本。 我们预计此次更改只会影响一小部分用户，他们可能在受限环境中运行 Kubernetes， 或使用了老旧到无法处理重定向行为的客户端。 <!-- ## What will happen to k8s.gcr.io? Separate from the redirect, k8s.gcr.io will be frozen [and will not be updated with new images after April 3rd, 2023](https://kubernetes.io/blog/2023/02/06/k8s-gcr-io-freeze-announcement/). `k8s.gcr.io` will not get any new releases, patches, or security updates. It will continue to remain available to help people migrate, but it **WILL** be phased out entirely in the future. --> ## k8s.gcr.io 将会怎样？   {#what-will-happen-to-k8s-gcr-io} 除了重定向之外，k8s.gcr.io 将被冻结， [且在 2023 年 4 月 3 日之后将不会随着新的镜像而更新](/zh-cn/blog/2023/02/06/k8s-gcr-io-freeze-announcement/)。 `k8s.gcr.io` 将不再获取任何新的版本、补丁或安全更新。 这个旧仓库将继续保持可用，以帮助人们迁移，但在以后将会被彻底淘汰。 <!-- ## I still have questions, where should I go? For more information on registry.k8s.io and why it was developed, see [registry.k8s.io: faster, cheaper and Generally Available](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/). If you would like to know more about the image freeze and the last images that will be available there, see the blog post: [k8s.gcr.io Image Registry Will Be Frozen From the 3rd of April 2023](/blog/2023/02/06/k8s-gcr-io-freeze-announcement/). --> ## 我仍有疑问，我该去哪儿询问？   {#what-should-i-go} 有关 registry.k8s.io 及其为何开发这个新仓库的更多信息，请参见 [registry.k8s.io：更快、成本更低且正式发布](/blog/2022/11/28/registry-k8s-io-faster-cheaper-ga/)。 如果你想了解镜像冻结以及最后一版可用镜像的更多信息，请参见博文： [k8s.gcr.io 镜像仓库将从 2023 年 4 月 3 日起被冻结](/zh-cn/blog/2023/02/06/k8s-gcr-io-freeze-announcement/)。 <!-- Information on the architecture of registry.k8s.io and its [request handling decision tree](https://github.com/kubernetes/registry.k8s.io/blob/8408d0501a88b3d2531ff54b14eeb0e3c900a4f3/cmd/archeio/docs/request-handling.md) can be found in the [kubernetes/registry.k8s.io repo](https://github.com/kubernetes/registry.k8s.io). If you believe you have encountered a bug with the new registry or the redirect, please open an issue in the [kubernetes/registry.k8s.io repo](https://github.com/kubernetes/registry.k8s.io/issues/new/choose). **Please check if there is an issue already open similar to what you are seeing before you create a new issue**. --> 有关 registry.k8s.io 架构及其[请求处理决策树](https://github.com/kubernetes/registry.k8s.io/blob/8408d0501a88b3d2531ff54b14eeb0e3c900a4f3/cmd/archeio/docs/request-handling.md)的信息， 请查阅 [kubernetes/registry.k8s.io 代码仓库](https://github.com/kubernetes/registry.k8s.io)。 若你认为自己在使用新仓库和重定向时遇到 bug，请在 [kubernetes/registry.k8s.io 代码仓库](https://github.com/kubernetes/registry.k8s.io/issues/new/choose)中提出 Issue。 **请先检查是否有人提出了类似的 Issue，再行创建新 Issue。** </ins>

I will localize this blog in days. To avoid possible conflicts with other contributors, this issue is opened. /assign /language zh /area blog
/triage accepted thanks.


Question: ``` {{% note %}} <del> ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。 </del> <ins> ページのweightについては、1、2、3…などの値を使用せず、10、20、30…のように一定の間隔を空けた方が賢明です。こうすることで、後で別のページを間に挿入できるようになります。さらに、同じディレクトリ(セクション)内の各ページのweightは、重複しないようにする必要があります。これにより、特にローカライズされたコンテンツでは、コンテンツが常に正しく整列されるようになります。 </ins> {{% /note %}} ### ドキュメントのメインメニュー

This is a Feature Request What would you like to be We need to update /content/ja/docs/contribute/style/content- according to the English text, because it is outdated. Why is this needed /content/ja/docs/contribute/style/content- is outdated. In the English page, a note for localication was in . It needs to be to the Japanese page. Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Related Issue : ,


Question: * Run etcd as a cluster of odd members. <del> * etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. </del> <ins> * etcd is a leader-based distributed system. Ensure that the leader periodically send heartbeats on time to all followers to keep the cluster stable. </ins> * Ensure that no resource starvation occurs. <del> Performance and stability of the cluster is sensitive to network and disk IO. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled. </del> <ins> Performance and stability of the cluster is sensitive to network and disk I/O. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster. An unstable etcd indicates that no leader is elected. Under such circumstances, a cluster cannot make any changes to its current state, which implies no new pods can be scheduled. </ins> <del> * Keeping stable etcd clusters is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://github.com/coreos/etcd/blob/master/Documentation/op-guide/hardware.md#hardware-recommendations). </del> <ins> * Keeping etcd clusters stable is critical to the stability of Kubernetes clusters. Therefore, run etcd clusters on dedicated machines or isolated environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/). </ins> * The minimum recommended version of etcd to run in production is `3.2.10+`. -->

" etcd "client.cert " etcd etcd " " etcd client.key etcd "
~ GitHub is not the right place for support requests.~ ~If you're looking for help, oyu could ask on .~ ~You can also post your question on the or the forum. There are other support venues with contributions from the wider community of Kubernetes users.~
/triage accepted /kind bug
/remove-kind support
Thanks
/language zh
/priority backlog


Question: /api-ref/     https://github.com/kubernetes/kubernetes/milestones/ 301 /concepts/containers/container-lifecycle-hooks/     /docs/concepts/containers/container-lifecycle-hooks/ 301 /docs/     /docs/home/ 301 <del> /docs/abstractions/controllers/petset/     /docs/concepts/workloads/controllers/statefulset/ 301 </del> /docs/admin/     /docs/concepts/cluster-administration/cluster-administration-overview/ 301 /docs/admin/add-ons/     /docs/concepts/cluster-administration/addons/ 301

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


Question: # i18n strings for the Chinese version of the site (https://kubernetes.io/zh-cn/) # 注意：修改此文件时请维持字符串名称的字母顺序并与英文版保持一致 <ins> # Avoid using conjunction_1. # Must match the context in layouts/shortcodes/release-data.html # Appears on https://kubernetes.io/releases/ # For example the "and" in "Complete 1.25 Schedule and Changelog" [conjunction_1] other = "和" </ins> [caution] other = "注意："

What would you like to be This issue is a follow-up task from displays some English text: ! To replace this text with localized strings, you can update with from . Specifically, these:
/language zh-cn
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language zh-cn Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig-docs
/language zh
/triage accepted /assign


Question: # Create temp directories to store files that will end up on other hosts mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/ --> ```sh # 使用你的主机 IP 更新 HOST0、HOST1 和 HOST2 的 IP 地址 export HOST0=10.0.0.6

apiVersion: kind: KubeletConfiguration authentication: anonymous: enabled: false webhook: enabled: false authorization: mode: AlwaysAllow apiVersion: kind: KubeletConfiguration authentication: anonymous: enabled: false webhook: enabled: false authorization: mode: AlwaysAllow
Use kubeadm to create a highly available etcd cluster apiVersion: kind: KubeletConfiguration authentication: anonymous: enabled: false webhook: enabled: false authorization: mode: AlwaysAllow There is a problem here, there is no indentation Normal should be apiVersion: kind: KubeletConfiguration authentication: anonymous: enabled: false webhook: enabled: false authorization: mode: AlwaysAllow
provide more details of the issue as it's difficult to address your issue with the information that you have provided. Atleast mention the page you are referring to. /triage needs-information
Page related to the issue :
/language zh
/retitle The YAML format may be not correct in setup-ha-etcd-with-kubeadm
/triage accepted /assign


Question: 2. Download the Google Cloud public signing key: ```shell <del> sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg </del> <ins> sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg </ins> ``` 3. Add the Kubernetes `apt` repository: ```shell <del> echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list </del> <ins> echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list </ins> ``` 4. Update `apt` package index with the new repository and install kubectl:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The documentation recommends installing the repository signing key to . This is contrary to the recommendation in the Debian documentation : There is no keyring package in the k8s repository that would replace and (when necessary) update a keyring installed to , so the keyring should go to . Proposed Solution: Replace with in the instructions for setting up the apt package repository. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This is a reasonable change. We could also mention that and document how to make sure it exists. /language en /sig cluster-lifecycle /remove-kind bug It's not exactly a bug, and it's not a feature either. Let's not choose. /triage accepted /priority backlog /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 : This is a reasonable change. We could also mention that In releases older than Debian 12 and Ubuntu 22.04, does not exist by default. /sig cluster-lifecycle /priority backlog /help 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
please update the issue description to not mention updating the localized versions. Localization teams pick those changes up and will file their own issues if needed.
I've removed the mention of localization.
I will give a try on this. /assign
Thank you very much! :slightlysmilingface:


Question: 与 DaemonSet 中的 Pod 进行通信的几种可能模式如下： <del> - **Push**：配置 DaemonSet 中的 Pod，将更新发送到另一个服务，例如统计数据库。 </del> <ins> - **推送（Push）**：配置 DaemonSet 中的 Pod，将更新发送到另一个服务，例如统计数据库。 </ins> 这些服务没有客户端。 - **NodeIP 和已知端口**：DaemonSet 中的 Pod 可以使用 `hostPort`，从而可以通过节点 IP

“ DaemonSet spec.template.“ “”“”
Mind propose a fix?
/triage accepted
/language zh (I presume)
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /language zh (I presume) 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
yes,this is chinese languge,“”change to“”
/assign


Question: Once you've done that, move on to Using <tt>kubectl</tt> to create a Deployment.

The basic tutorial starts at , which leads to , which leads to Since one does not know what is exactly meant with in the second site, one does also the deploy step. Because it's not clearly said "" or so. Then you go back to the second site, to read all through, only to do create/expose again (with little extras), only to go back to the first site and do create/expose again. Back to the first site on step 2, pretty much at the beginning it says: But I did it already 2 times in the current tutorial flow. Now I have 3 deployments, still in the basics deployment tutorial. Its like, there are 3 tutorials to do, which are the same, but also not the same. Instead of leading the user back and forth, I suggest to do one single sufficient tutorial.
Page related to issue: /language en
/retitle Consolidate and streamline Kubernetes basics tutorials to avoid redundancy and confusion
/sig docs
the three tutorial have different purpose. What I understood the purpose of having these as three.: Yes, Its leading to back and forth of the users but I think First link showing the general functionality of the cluster's component. It Should have the link To and then link will be helpful for readers to traverse. This sequence is lacking in the page. Thats the reason why i thing its taking user back and forth several times .
There was a previous attempt at de-duplicating, but it probably has to be done again - after the removal of the Katacoda tutorials, which were using a hosted setup of to run through the tutorials "inline" with the docs
I'll change the title to frame this as a bug. /retitle Multiple, similar Kubernetes basics tutorials that cause confusion /kind bug /triage accepted /priority important-longterm
/lifecycle frozen
Yes You are right! +1
/assign
I will start working on this.


Question: --- linktitle: Kubernetes Documentation title: Documentation <ins> sitemap: priority: 1.0 </ins> ---

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The Kubernetes website generates a sitemap. Let's highlight specific pages using priority weighting: (and any localization that copies the priority weight) (and any localization that copies the priority weight) (and any localization that copies the priority weight) Why is this needed: Making this change helps search engines understand what pages the Kubernetes project sees as important. Comments /kind feature


Question: ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure <del> upstream </del> fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 <del> proxy ./etc/resolv.conf </del> <ins> forward ./etc/resolv.conf </ins> cache 30 loop reload

proxy --forward .
/assign /language zh
page: below yaml config comes from k8s 1.19


Question: kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash> ``` <ins> To let kubectl work in the following steps, you need to run these commands as a regular user (which is part of the output above): ``` mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` </ins> Make a record of the `kubeadm join` command that `kubeadm init` outputs. You will need this in a moment.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:


Question: {{% capture overview %}} <del> {{< feature-state state="beta" >}} </del> <ins> {{< feature-state state="beta" for_k8s_version="v1.18" >}} </ins> An increasing number of systems leverage a combination of CPUs and hardware accelerators to support latency-critical execution and high-throughput parallel computation. These include workloads in fields such as telecommunications, scientific computing, machine learning, financial services and data analytics. Such hybrid systems comprise a high performance environment.

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: has a feature-state shortcode: this shortcode doesn't track when the feature went beta. Proposed Solution: Change that line to: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /help /language en /priority backlog /good-first-issue
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 : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: has a feature-state shortcode: Change that line to: <!--Kubernetes Version:--/help /language en /priority backlog /good-first-issue </details
/assign


Question: ## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} </ins>

This is a clean up issue <!-- 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 changed Look at Make sure that all the version constraints in the page make sense and related to the list of Kubernetes versions that are for documentation. There is a shortcode in the page that expects a value in the page front matter. ~Replace that shortcode with English text that explains in words what versions the reader should have. (to save you having to check: you can only configure a startup probe if you have Kubernetes v1.16 or later and if you have enabled the )~ Remove that shortcode. Why is this needed doesn't clearly tell readers about the version of Kubernetes they need to be running and the feature gate(s) they might need to enable. Comments /help /kind cleanup If you're looking at this, you might also want to tackle issue
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 : This is a clean up issue <!-- See for guidance on writing an actionable issue description. --Look at (to save you having to check: you can only configure a startup probe if you have Kubernetes v1.16 or later and if you have enabled the ) doesn't clearly tell readers about the version of Kubernetes they need to be running and the feature gate(s) they might need to enable. /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
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
/language en /lifecycle frozen
/assign I'll probably be back with questions - where's better to post/ask, here on the issue, or in Slack?
Should I just add the info for Startup probes?


Question: ## {{% heading "prerequisites" %}} <del> {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} </del> <ins> {{< include "task-tutorial-prereqs.md" >}} </ins>

I see that they came last with the feature gate in 1.16 onwards, checking now re: Liveness and Readiness but I guess they're earlier than the supported doc versions. Still would be nice to mention though - as a reader with maybe a bit less context I would get confused if the page title mentions 3 kinds of probes and the docs only talk about version requirements for one type of probe.
Also at this point for the feature flag since it went beta in 1.18 and GA in 1.20 the text would be something like: Kubernetes v1.16 and v1.17 require the to be set. Startup probes are enabled by default in Kubernetes v1.18 onwards.
IMO it's OK to focus on documenting for v1.21, the current documentation version. If we want to backport the equivalent change to the older documentation, that's an option too. For example, if you want to revise https://v1- to explain the feature gate, that's OK (but also not a priority).
how do I go about editing the old version of the docs? Or is there a how-to/readme somewhere? I've submitted a PR for the current version/file with the text I suggested: Do you know btw when Liveness and Readiness probes went alpha/beta/GA? I found Liveness probes introduced but haven't found Readiness probes yet. Anyways given that it's all the way in 2014 I think it's safe to omit specific versions. I updated the text to read: lmk what you think
Since I opened this issue, several Kubernetes releases have come out and I didn't update the issue text to clarify it. I have now.
If all PRs were this simple Actually it turns out some of them really are :)