Question: <ins> --- layout: blog title: "聚焦 SIG Storage" slug: sig-storage-spotlight date: 2022-08-22 --- <!-- layout: blog title: "Spotlight on SIG Storage" slug: sig-storage-spotlight date: 2022-08-22 canonicalUrl: https://www.kubernetes.dev/blog/2022/08/22/sig-storage-spotlight-2022/ --> <!-- **Author**: Frederico Muñoz (SAS) --> **作者**：Frederico Muñoz (SAS) <!-- Since the very beginning of Kubernetes, the topic of persistent data and how to address the requirement of stateful applications has been an important topic. Support for stateless deployments was natural, present from the start, and garnered attention, becoming very well-known. Work on better support for stateful applications was also present from early on, with each release increasing the scope of what could be run on Kubernetes. --> 自 Kubernetes 诞生之初，持久数据以及如何解决有状态应用程序的需求一直是一个重要的话题。 对无状态部署的支持是很自然的、从一开始就存在的，并引起了人们的关注，变得众所周知。 从早期开始，我们也致力于更好地支持有状态应用程序，每个版本都增加了可以在 Kubernetes 上运行的范围。 <!-- Message queues, databases, clustered filesystems: these are some examples of the solutions that have different storage requirements and that are, today, increasingly deployed in Kubernetes. Dealing with ephemeral and persistent storage, local or remote, file or block, from many different vendors, while considering how to provide the needed resiliency and data consistency that users expect, all of this is under SIG Storage's umbrella. --> 消息队列、数据库、集群文件系统：这些是具有不同存储要求的解决方案的一些示例， 如今这些解决方案越来越多地部署在 Kubernetes 中。 处理来自许多不同供应商的临时和持久存储（本地或远程、文件或块），同时考虑如何提供用户期望的所需弹性和数据一致性， 所有这些都在 SIG Storage 的整体负责范围之内。 <!-- In this SIG Storage spotlight, [Frederico Muñoz](https://twitter.com/fredericomunoz) (Cloud & Architecture Lead at SAS) talked with [Xing Yang](https://twitter.com/2000xyang), Tech Lead at VMware and co-chair of SIG Storage, on how the SIG is organized, what are the current challenges and how anyone can get involved and contribute. --> 在这次 SIG Storage 采访报道中，[Frederico Muñoz](https://twitter.com/fredericomunoz) （SAS 的云和架构负责人）与 VMware 技术负责人兼 SIG Storage 联合主席 [Xing Yang](https://twitter.com/2000xyang)，讨论了 SIG 的组织方式、当前的挑战是什么以及如何进行参与和贡献。 <!-- ## About SIG Storage **Frederico (FSM)**: Hello, thank you for the opportunity of learning more about SIG Storage. Could you tell us a bit about yourself, your role, and how you got involved in SIG Storage. --> ## 关于 SIG Storage **Frederico (FSM)**：你好，感谢你给我这个机会了解更多关于 SIG Storage 的情况。 你能否介绍一下你自己、你的角色以及你是如何参与 SIG Storage 的。 <!-- **Xing Yang (XY)**: I am a Tech Lead at VMware, working on Cloud Native Storage. I am also a Co-Chair of SIG Storage. I started to get involved in K8s SIG Storage at the end of 2017, starting with contributing to the [VolumeSnapshot](https://kubernetes.io/docs/concepts/storage/volume-snapshots/) project. At that time, the VolumeSnapshot project was still in an experimental, pre-alpha stage. It needed contributors. So I volunteered to help. Then I worked with other community members to bring VolumeSnapshot to Alpha in K8s 1.12 release in 2018, Beta in K8s 1.17 in 2019, and eventually GA in 1.20 in 2020. --> **Xing Yang (XY)**：我是 VMware 的技术主管，从事云原生存储方面的工作。我也是 SIG Storage 的联合主席。 我从 2017 年底开始参与 K8s SIG Storage，开始为 [VolumeSnapshot](https://kubernetes.io/zh-cn/docs/concepts/storage/volume-snapshots/) 项目做贡献。 那时，VolumeSnapshot 项目仍处于实验性的 pre-alpha 阶段。它需要贡献者。所以我自愿提供帮助。 然后我与其他社区成员合作，在 2018 年的 K8s 1.12 版本中将 VolumeSnapshot 带入 Alpha， 2019 年在 K8s 1.17 版本中带入 Beta，并最终在 2020 年在 1.20 版本中带入 GA。 <!-- **FSM**: Reading the [SIG Storage charter](https://github.com/kubernetes/community/blob/master/sig-storage/charter.md) alone it’s clear that SIG Storage covers a lot of ground, could you describe how the SIG is organised? --> **FSM**：仅仅阅读 [SIG Storage 章程](https://github.com/kubernetes/community/blob/master/sig-storage/charter.md) 就可以看出，SIG Storage 涵盖了很多领域，你能描述一下 SIG 的组织方式吗？ <!-- **XY**: In SIG Storage, there are two Co-Chairs and two Tech Leads. Saad Ali from Google and myself are Co-Chairs. Michelle Au from Google and Jan Šafránek from Red Hat are Tech Leads. --> **XY**：在 SIG Storage 中，有两位联合主席和两位技术主管。来自 Google 的 Saad Ali 和我是联合主席。 来自 Google 的 Michelle Au 和来自 Red Hat 的 Jan Šafránek 是技术主管。 <!-- We have bi-weekly meetings where we go through features we are working on for each particular release, getting the statuses, making sure each feature has dev owners and reviewers working on it, and reminding people about the release deadlines, etc. More information on the SIG is on the [community page](https://github.com/kubernetes/community/tree/master/sig-storage). People can also add PRs that need attention, design proposals that need discussion, and other topics to the meeting agenda doc. We will go over them after project tracking is done. --> 我们每两周召开一次会议，讨论我们正在为每个特定版本开发的功能，获取状态，确保每个功能都有开发人员和审阅人员在处理它， 并提醒人们发布截止日期等。有关 SIG 的更多信息，请查阅[社区页面](https://github.com/kubernetes/community/tree/master/sig-storage)。 人们还可以将需要关注的 PR、需要讨论的设计提案和其他议题添加到会议议程文档中。 我们将在项目跟踪完成后对其进行审查。 <!-- We also have other regular meetings, i.e., CSI Implementation meeting, Object Bucket API design meeting, and one-off meetings for specific topics if needed. There is also a [K8s Data Protection Workgroup](https://github.com/kubernetes/community/blob/master/wg-data-protection/README.md) that is sponsored by SIG Storage and SIG Apps. SIG Storage owns or co-owns features that are being discussed at the Data Protection WG. --> 我们还举行其他的定期会议，如 CSI 实施会议，Object Bucket API 设计会议，以及在需要时针对特定议题的一次性会议。 还有一个由 SIG Storage 和 SIG Apps 赞助的 [K8s 数据保护工作组](https://github.com/kubernetes/community/blob/master/wg-data-protection/README.md)。 SIG Storage 拥有或共同拥有数据保护工作组正在讨论的功能特性。 <!-- ## Storage and Kubernetes **FSM**: Storage is such a foundational component in so many things, not least in Kubernetes: what do you think are the Kubernetes-specific challenges in terms of storage management? --> ## 存储和 Kubernetes **FSM**：存储是很多模块的基础组件，尤其是 Kubernetes：你认为 Kubernetes 在存储管理方面的具体挑战是什么? <!-- **XY**: In Kubernetes, there are multiple components involved for a volume operation. For example, creating a Pod to use a PVC has multiple components involved. There are the Attach Detach Controller and the external-attacher working on attaching the PVC to the pod. There’s the Kubelet that works on mounting the PVC to the pod. Of course the CSI driver is involved as well. There could be race conditions sometimes when coordinating between multiple components. --> **XY**：在 Kubernetes 中，卷操作涉及多个组件。例如，创建一个使用 PVC 的 Pod 涉及多个组件。 有 Attach Detach Controller 和 external-attacher 负责将 PVC 连接到 Pod。 还有 Kubelet 可以将 PVC 挂载到 Pod 上。当然，CSI 驱动程序也参与其中。 在多个组件之间进行协调时，有时可能会出现竞争状况。 <!-- Another challenge is regarding core vs [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRD), not really storage specific. CRD is a great way to extend Kubernetes capabilities while not adding too much code to the Kubernetes core itself. However, this also means there are many external components that are needed when running a Kubernetes cluster. --> 另一个挑战是关于核心与 [Custom Resource Definitions](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)（CRD）， 这并不是特定于存储的。CRD 是一种扩展 Kubernetes 功能的好方法，同时又不会向 Kubernetes 核心本身添加太多代码。 然而，这也意味着运行 Kubernetes 集群时需要许多外部组件。 <!-- From the SIG Storage side, one most notable example is Volume Snapshot. Volume Snapshot APIs are defined as CRDs. API definitions and controllers are out-of-tree. There is a common snapshot controller and a snapshot validation webhook that should be deployed on the control plane, similar to how kube-controller-manager is deployed. Although Volume Snapshot is a CRD, it is a core feature of SIG Storage.  It is recommended for the K8s cluster distros to deploy Volume Snapshot CRDs, the snapshot controller, and the snapshot validation webhook, however, most of the time we don’t see distros deploy them. So this becomes a problem for the storage vendors: now it becomes their responsibility to deploy these non-driver specific common components. This could cause conflicts if a customer wants to use more than one storage system and deploy more than one CSI driver. --> 在 SIG Storage 方面，一个最好的例子是卷快照。卷快照 API 被定义为 CRD。 API 定义和控制器是 out-of-tree。有一个通用的快照控制器和一个快照验证 Webhook 应该部署在控制平面上，类似于 kube-controller-manager 的部署方式。 虽然 Volume Snapshot 是一个 CRD，但它是 SIG Storage 的核心特性。 建议 K8s 集群发行版部署卷快照 CRD、快照控制器和快照验证 Webhook，然而，大多数时候我们没有看到发行版部署它们。 因此，这对存储供应商来说就成了一个问题：现在部署这些非驱动程序特定的通用组件成为他们的责任。 如果客户需要使用多个存储系统，且部署多个 CSI 驱动，可能会导致冲突。 <!-- **FSM**: Not only the complexity of a single storage system, you have to consider how they will be used together in Kubernetes? --> **FSM**：不仅要考虑单个存储系统的复杂性，还要考虑它们在 Kubernetes 中如何一起使用？ <!-- **XY**: Yes, there are many different storage systems that can provide storage to containers in Kubernetes. They don’t work the same way. It is challenging to find a solution that works for everyone. --> **XY**：是的，有许多不同的存储系统可以为 Kubernetes 中的容器提供存储。它们的工作方式不同。找到适合所有人的解决方案是具有挑战性的。 <!-- **FSM**: Storage in Kubernetes also involves interacting with external solutions, perhaps more so than other parts of Kubernetes. Is this interaction with vendors and external providers challenging? Has it evolved with time in any way? --> **FSM**：Kubernetes 中的存储还涉及与外部解决方案的交互，可能比 Kubernetes 的其他部分更多。 这种与供应商和外部供应商的互动是否具有挑战性？它是否以任何方式随着时间而演变？ <!-- **XY**: Yes, it is definitely challenging. Initially Kubernetes storage had in-tree volume plugin interfaces. Multiple storage vendors implemented in-tree interfaces and have volume plugins in the Kubernetes core code base.  This caused lots of problems.  If there is a bug in a volume plugin, it affects the entire Kubernetes code base.  All volume plugins must be released together with Kubernetes. There was no flexibility if storage vendors need to fix a bug in their plugin or want to align with their own product release. --> **XY**：是的，这绝对是具有挑战性的。最初 Kubernetes 存储具有 in-tree 卷插件接口。 多家存储供应商实现了 in-tree 接口，并在 Kubernetes 核心代码库中拥有卷插件。这引起了很多问题。 如果卷插件中存在错误，它会影响整个 Kubernetes 代码库。所有卷插件必须与 Kubernetes 一起发布。 如果存储供应商需要修复其插件中的错误或希望与他们自己的产品版本保持一致，这是不灵活的。 <!-- **FSM**: That’s where CSI enters the game? --> **FSM**：这就是 CSI 加入的原因？ <!-- **XY**: Exactly, then there comes [Container Storage Interface](https://kubernetes-csi.github.io/docs/) (CSI). This is an industry standard trying to design common storage interfaces so that a storage vendor can write one plugin and have it work across a range of container orchestration systems (CO). Now Kubernetes is the main CO, but back when CSI just started, there were Docker, Mesos, Cloud Foundry, in addition to Kubernetes. CSI drivers are out-of-tree so bug fixes and releases can happen at their own pace. --> **XY**：没错，接下来就是[容器存储接口](https://kubernetes-csi.github.io/docs/)（CSI）。 这是一个试图设计通用存储接口的行业标准，以便存储供应商可以编写一个插件并让它在一系列容器编排系统（CO）中工作。 现在 Kubernetes 是主要的 CO，但是在 CSI 刚开始的时候，除了 Kubernetes 之外，还有 Docker、Mesos、Cloud Foundry。 CSI 驱动程序是 out-of-tree 的，因此可以按照自己的节奏进行错误修复和发布。 <!-- CSI is definitely a big improvement compared to in-tree volume plugins. Kubernetes implementation of CSI has been GA [since the 1.13 release](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/).  It has come a long way.  SIG Storage has been working on moving in-tree volume plugins to out-of-tree CSI drivers for several releases now. --> 与 in-tree 卷插件相比，CSI 绝对是一个很大的改进。CSI 的 Kubernetes 实现[自 1.13 版本以来](https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/)就达到 GA。 它已经发展了很长时间。SIG Storage 一直致力于将 in-tree 卷插件迁移到 out-of-tree 的 CSI 驱动，已经有几个版本了。 <!-- **FSM**: Moving drivers away from the Kubernetes main tree and into CSI was an important improvement. --> **FSM**：将驱动程序从 Kubernetes 主仓移到 CSI 中是一项重要的改进。 <!-- **XY**: CSI interface is an improvement over the in-tree volume plugin interface, however, there are still challenges. There are lots of storage systems. Currently [there are more than 100 CSI drivers listed in CSI driver docs](https://kubernetes-csi.github.io/docs/drivers.html). These storage systems are also very diverse.  So it is difficult to design a common API that works for all.  We introduced capabilities at CSI driver level, but we also have challenges when volumes provisioned by the same driver have different behaviors.  The other day we just had a meeting discussing Per Volume CSI Driver Capabilities. We have a problem differentiating some CSI driver capabilities when the same driver supports both block and file volumes.  We are going to have follow up meetings to discuss this problem. --> **XY**： CSI 接口是对 in-tree 卷插件接口的改进，但是仍然存在挑战。有很多存储系统。 目前在 [CSI 驱动程序文档中列出了 100 多个 CSI 驱动程序](https://kubernetes-csi.github.io/docs/drivers.html)。 这些存储系统也非常多样化。因此，很难设计一个适用于所有人的通用 API。 我们在 CSI 驱动层面引入了功能，但当同一驱动配置的卷具有不同的行为时，我们也会面临挑战。 前几天我们刚刚开会讨论每种卷 CSI 驱动程序功能。 当同一个驱动程序同时支持块卷和文件卷时，我们在区分某些 CSI 驱动程序功能时遇到了问题。 我们将召开后续会议来讨论这个问题。 <!-- ## Ongoing challenges **FSM**: Specifically for the [1.25 release](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.25) we can see that there are a relevant number of storage-related [KEPs](https://bit.ly/k8s125-enhancements) in the pipeline, would you say that this release is particularly important for the SIG? --> ## 持续的挑战 **FSM**：具体来说，对于 [1.25 版本](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.25) 们可以看到管道中有一些与存储相关的 [KEPs](https://bit.ly/k8s125-enhancements)。 你是否认为这个版本对 SIG 特别重要？ <!-- **XY**: I wouldn’t say one release is more important than other releases. In any given release, we are working on a few very important things. --> **XY**：我不会说一个版本比其他版本更重要。在任何给定的版本中，我们都在做一些非常重要的事情。 <!-- **FSM**: Indeed, but are there any 1.25 specific specificities and highlights you would like to point out though? --> **FSM**：确实如此，但你是否想指出 1.25 版本的特定特性和亮点呢？ <!-- **XY**: Yes. For the 1.25 release, I want to highlight the following: --> **XY**：好的。对于 1.25 版本，我想强调以下几点： <!-- * [CSI Migration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/625-csi-migration) is an on-going effort that SIG Storage has been working on for a few releases now. The goal is to move in-tree volume plugins to out-of-tree CSI drivers and eventually remove the in-tree volume plugins.  There are 7 KEPs that we are targeting in 1.25 are related to CSI migration. There is one core KEP for the general CSI Migration feature. That is targeting GA in 1.25. CSI Migration for GCE PD and AWS EBS are targeting GA. CSI Migration for vSphere is targeting to have the feature gate on by default while staying in 1.25 that are in Beta. Ceph RBD and PortWorx are targeting Beta, with feature gate off by default. Ceph FS is targeting Alpha. --> * [CSI 迁移](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/625-csi-migration) 是一项持续的工作，SIG Storage 已经工作了几个版本了。目标是将 in-tree 卷插件移动到 out-of-tree 的 CSI 驱动程序，并最终删除 in-tree 卷插件。在 1.25 版本中，有 7 个 KEP 与 CSI 迁移有关。 有一个核心 KEP 用于通用的 CSI 迁移功能。它的目标是在 1.25 版本中达到 GA。 GCE PD 和 AWS EBS 的 CSI 迁移以 GA 为目标。vSphere 的 CSI 迁移的目标是在默认情况下启用特性门控， 在 1.25 版本中达到 Beta。Ceph RBD 和 PortWorx 的目标是达到 Beta，默认关闭特性门控。 Ceph FS 的目标是达到 Alpha。 <!-- * The second one I want to highlight is [COSI, the Container Object Storage Interface](https://github.com/kubernetes-sigs/container-object-storage-interface-spec). This is a sub-project under SIG Storage. COSI proposes object storage Kubernetes APIs to support orchestration of object store operations for Kubernetes workloads. It also introduces gRPC interfaces for object storage providers to write drivers to provision buckets. The COSI team has been working on this project for more than two years now. The COSI feature is targeting Alpha in 1.25. The KEP just got merged. The COSI team is working on updating the implementation based on the updated KEP. --> * 我要强调的第二个是 [COSI，容器对象存储接口](https://github.com/kubernetes-sigs/container-object-storage-interface-spec)。 这是 SIG Storage 下的一个子项目。COSI 提出对象存储 Kubernetes API 来支持 Kubernetes 工作负载的对象存储操作的编排。 它还为对象存储提供商引入了 gRPC 接口，以编写驱动程序来配置存储桶。COSI 团队已经在这个项目上工作两年多了。 COSI 功能的目标是 1.25 版本中达到 Alpha。KEP 刚刚合入。COSI 团队正在根据更新后的 KEP 更新实现。 <!-- * Another feature I want to mention is [CSI Ephemeral Volume](https://github.com/kubernetes/enhancements/issues/596) support. This feature allows CSI volumes to be specified directly in the pod specification for ephemeral use cases. They can be used to inject arbitrary states, such as configuration, secrets, identity, variables or similar information, directly inside pods using a mounted volume.  This was initially introduced in 1.15 as an alpha feature, and it is now targeting GA in 1.25. --> * 我要提到的另一个功能是 [CSI 临时卷](https://github.com/kubernetes/enhancements/issues/596)支持。 此功能允许在临时用例的 Pod 规约中直接指定 CSI 卷。它们可用于使用已安装的卷直接在 Pod 内注入任意状态， 例如配置、Secrets、身份、变量或类似信息。这最初是在 1.15 版本中作为一个 Alpha 功能引入的，现在它的目标是在 1.25 版本中达到 GA。 <!-- **FSM**: If you had to single something out, what would be the most pressing areas the SIG is working on? --> **FSM**：如果你必须单独列出一些内容，那么 SIG 正在研究的最紧迫的领域是什么? <!-- **XY**: CSI migration is definitely one area that the SIG has put in lots of effort and it has been on-going for multiple releases now. It involves work from multiple cloud providers and storage vendors as well. --> **XY**：CSI 迁移绝对是 SIG 投入大量精力的领域之一，并且现在已经进行了多个版本。它还涉及来自多个云提供商和存储供应商的工作。 <!-- ## Community involvement **FSM**: Kubernetes is a community-driven project. Any recommendation for anyone looking into getting involved in SIG Storage work? Where should they start? --> ## 社区参与 **FSM**：Kubernetes 是一个社区驱动的项目。对任何希望参与 SIG Storage 工作的人有什么建议吗？他们应该从哪里开始？ <!-- **XY**: Take a look at the [SIG Storage community page](https://github.com/kubernetes/community/tree/master/sig-storage), it has lots of information on how to get started. There are [SIG annual reports](https://github.com/kubernetes/community/blob/master/sig-storage/annual-report-2021.md) that tell you what we did each year. Take a look at the Contributing guide. It has links to presentations that can help you get familiar with Kubernetes storage concepts. --> **XY**：查看 [SIG Storage 社区页面](https://github.com/kubernetes/community/tree/master/sig-storage)， 它有很多关于如何开始的信息。[SIG 年度报告](https://github.com/kubernetes/community/blob/master/sig-storage/annual-report-2021.md)告诉你我们每年做了什么。 查看贡献指南。它有一些演示的链接，可以帮助你熟悉 Kubernetes 存储概念。 <!-- Join our [bi-weekly meetings on Thursdays](https://github.com/kubernetes/community/tree/master/sig-storage#meetings). Learn how the SIG operates and what we are working on for each release. Find a project that you are interested in and help out. As I mentioned earlier, I got started in SIG Storage by contributing to the Volume Snapshot project. --> 参加我们[在星期四举行的双周会议](https://github.com/kubernetes/community/tree/master/sig-storage#meetings)。 了解 SIG 的运作方式以及我们为每个版本所做的工作。找到你感兴趣的项目并提供贡献。 正如我之前提到的，我通过参与 Volume Snapshot 项目开始了 SIG Storage。 <!-- **FSM**: Any closing thoughts you would like to add? --> **FSM**：你有什么要补充的结束语吗？ <!-- **XY**: SIG Storage always welcomes new contributors. We need contributors to help with building new features, fixing bugs, doing code reviews, writing tests, monitoring test grid health, and improving documentation, etc. --> **XY**：SIG Storage 总是欢迎新的贡献者。 我们需要贡献者来帮助构建新功能、修复错误、进行代码审查、编写测试、监控测试网格的健康状况以及改进文档等。 <!-- **FSM**: Thank you so much for your time and insights into the workings of SIG Storage! --> **FSM**：非常感谢你抽出宝贵时间让我们深入了解 SIG Storage！ </ins>  No newline at end of file

This is a Feature Request This page blog/2022/08/22/sig-storage- has no Chinese version What would you like to be Translate Chinese version for blog/2022/08/22/sig-storage-spotlight/ Comments /language zh /assign
/triage accepted


Question: 默认调度器接下来将 Pod 绑定到目标主机。 如果 DaemonSet Pod 的节点亲和性配置已存在，则被替换。 DaemonSet 控制器仅在创建或修改 DaemonSet Pod 时执行这些操作， <del> 并且不回更改 DaemonSet 的 `spec.template`。 </del> <ins> 并且不会更改 DaemonSet 的 `spec.template`。 </ins> ```yaml nodeAffinity:

“ 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: 1. Run the following: <del> ```sh ./etcd --listen-client-urls=http://$PRIVATE_IP:2379 --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </del> <ins> ```sh etcd --listen-client-urls=http://$PRIVATE_IP:2379  --advertise-client-urls=http://$PRIVATE_IP:2379 ``` </ins> <del> 2. Start Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </del> <ins> 2. Start the Kubernetes API server with the flag `--etcd-servers=$PRIVATE_IP:2379`. </ins> <del> Replace `PRIVATE_IP` with your etcd client IP. </del> <ins> Make sure `PRIVATE_IP` is set to your etcd client IP. </ins> --> ### 单节点 etcd 集群

" 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: - Keep the blog content the same. If there are changes, they should be made to the original article first, and then to the mirrored article. - The mirrored blog should have a `canonicalUrl`, that is, essentially the url of the original blog after it has been published. <del> - [Kubernetes contributor blogs](https://kubernetes.dev/blog) have their authors mentioned in the YAML header, while the Kubernetes blog posts mention authors in the blog content itself. This should be changed when mirroring the content. </del> <ins> - Same as [Kubernetes contributor blogs](https://kubernetes.dev/blog), Kubernetes blog posts also mention authors in the YAML header as per the new guidelines. This should be ensured. </ins> - Publication dates stay the same as the original blog. All of the other guidelines and expectations detailed above apply as well.

This is a Feature Request <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--What would you like to be The blog submission guidelines currently do not reflect the new format required for front matter, particularly the inclusion of author metadata. This discrepancy could lead to confusion and incorrect submissions from contributors who follow the outdated format. The existing guidelines need to be updated to reflect this change. Proposed Solution: Update the example front matter on the to demonstrate the correct format for including author metadata. Ensure that any related content, such as instructions or explanations surrounding the addition of author information, is also updated to reflect the new requirement. Reference of a published blog following the new format: Example of new format: Page to Update: Page URL: source: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /sig docs /area blog
/triage accepted /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 : /triage accepted /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
/priority backlog
/assign


Question: for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release! ## Helpful Resources <ins> Refer to the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) resources for key information on roles and the release process. </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: No resource or content is getting showcased under 'Helpful Resources' heading in . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--!
/sig docs /priority backlog /language en
can I work on this issue? /assign
What might we do to fix this issue? do you have an idea? (it's OK if you don't)
3 kind of solutions are coming to my mind- 'Helpful resources' heading, if it's not adding any value here. some resources that are helpful to understand more about release process. Like- can also add things like this
I think would be great fit , here we can find detailed information about the roles within the release team, processes, and other essential aspects of managing Kubernetes releases.
/triage accepted It's definitely not right to keep the section empty does sound like an approach to me.
Upon some inspection, We don't have a heading on any other page. Should we remove it for consistency?


Question: <ins> apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very --- apiVersion: v1 kind: ConfigMap metadata: name: env-config namespace: default data: log_level: INFO </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 Translate tasks/configure-pod-container/configure-pod-configmap/ into Japanese. Why is this needed This page has not been translated. Comments /language ja
/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: <ins> --- title: Prácticas Recomendadas de Configuración content_type: concept weight: 10 --- <!-- overview --> Este documento destaca y consolida las prácticas recomendadas de configuración que se presentan a lo largo de la guía del usuario, la documentación de Introducción y los ejemplos. Este es un documento vivo. Si se te ocurre algo que no está en esta lista pero que puede ser útil a otros, no dudes en crear un _issue_ o enviar un PR. <!-- body --> ## Consejos Generales de Configuración - Al definir configuraciones, especifica la última versión estable de la API. - Los archivos de configuración deben almacenarse en el control de versiones antes de enviarse al clúster. Este le permite revertir rápidamente un cambio de configuración si es necesario. También ayuda a la recreación y restauración del clúster. - Escribe tus archivos de configuración usando YAML en lugar de JSON. Aunque estos formatos se pueden utilizarse indistintamente en casi todos los escenarios, YAML tiende a ser más amigable con el usuario. - Agrupa los objetos relacionados en un solo archivo siempre que tenga sentido. Un archivo suele ser más fácil de administrar que varios. Ver el archivo [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) como un ejemplo de esta sintaxis. - Ten en cuenta también que se pueden llamar muchos comandos `kubectl` en un directorio. Por ejemplo, puedes llamar `kubectl apply` en un directorio de archivos de configuración. - No especifiques valores predeterminados innecesariamente: una configuración simple y mínima hará que los errores sean menos probables. - Coloca descripciones de objetos en anotaciones, para permitir una mejor introspección. ## "Naked" Pods vs ReplicaSets, Deployments y Jobs {#naked-pods-vs-replicasets-deployments-and-jobs} - No usar "Naked" Pods (es decir, Pods no vinculados a un [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) o a un [Deployment](/docs/concepts/workloads/controllers/deployment/)) si puedes evitarlo. Los Naked Pods no se reprogramará en caso de falla de un nodo. Un Deployment, que crea un ReplicaSet para garantizar que se alcance la cantidad deseada de Pods está siempre disponible y especifica una estrategia para reemplazar los Pods (como [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), es casi siempre preferible a crear Pods directamente, excepto por algunos explícitos [`restartPolicy: Never`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) escenarios. Un [Job](/docs/concepts/workloads/controllers/job/) también puede ser apropiado. ## Servicios - Crea un [Service](/docs/concepts/services-networking/service/) antes de tus cargas de trabajo de backend correspondientes (Deployments o ReplicaSets) y antes de cualquier carga de trabajo que necesite acceder a él. Cuando Kubernetes inicia un contenedor, proporciona variables de entorno que apuntan a todos los _Services_ que se estaban ejecutando cuando se inició el contenedor. Por ejemplo, si existe un _Service_ llamado `foo`, todos los contenedores obtendrán las siguientes variables en su entorno inicial: ```shell FOO_SERVICE_HOST=<el host en el que se ejecuta el Service> FOO_SERVICE_PORT=<el puerto en el que se ejecuta el Service> ``` * Esto implica un requisito de ordenamiento - cualquier `Service` al que un `Pod` quiera acceder debe ser creado antes del `Pod` en sí mismo, de lo contrario, las variables de entorno no se completarán. El DNS no tiene esta restricción. - Un [cluster add-on](/docs/concepts/cluster-administration/addons/) opcional (aunque muy recomendable) es un servidor DNS. El servidor DNS observa la API de Kubernetes en busca de nuevos `Servicios` y crea un conjunto de registros DNS para cada uno. Si el DNS se ha habilitado en todo el clúster, todos los `Pods` deben ser capaces de hacer la resolución de nombres de `Services` automáticamente. - No especifiques un `hostPort` para un Pod a menos que sea absolutamente necesario. Cuando vinculas un Pod a un `hostPort`, limita la cantidad de lugares en los que se puede agendar el Pod, porque cada combinación <`hostIP`, `hostPort`, `protocol`> debe ser única. Si no especificas el `hostIP` y `protocol` explícitamente, Kubernetes usará `0.0.0.0` como el `hostIP` predeterminado y `TCP` como el `protocol` por defecto. Si solo necesitas acceder al puerto con fines de depuración, puedes utilizar el [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) o [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). Si necesitas exponer explícitamente el puerto de un Pod en el nodo, considera usar un [NodePort](/docs/concepts/services-networking/service/#type-nodeport) Service antes de recurrir a `hostPort`. - Evita usar `hostNetwork`, por las mismas razones que `hostPort`. - Usa [headless Services](/docs/concepts/services-networking/service/#headless-services) (que tiene un `ClusterIP` de `None`) para el descubrimiento de servicios cuando no necesites balanceo de carga `kube-proxy`. ## Usando Labels - Define y usa [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquen __atributos semánticos__ de tu aplicación o Deployment, como `{ app.kubernetes.io/name: MyApp, tier: frontend, phase: test, deployment: v3 }`. Puedes utilizar estas labels para seleccionar los Pods apropiados para otros recursos; por ejemplo, un Service que selecciona todo los Pods `tier: frontend`, o todos los componentes `phase: test` de `app.kubernetes.io/name: MyApp`. Revisa el [libro de visitas](https://github.com/kubernetes/examples/tree/master/guestbook/) para ver ejemplos de este enfoque. Un Service puede hacer que abarque múltiples Deployments omitiendo las labels específicas de la versión de su selector. Cuando necesites actualizar un servicio en ejecución sin downtime, usa un [Deployment](/docs/concepts/workloads/controllers/deployment/). Un estado deseado de un objeto se describe mediante una implementación, y si los cambios a esa especificación son _aplicados_, el controlador de implementación cambia el estado actual al estado deseado en un ritmo controlado. - Use las [labels comunes de Kubernetes](/docs/concepts/overview/working-with-objects/common-labels/) para casos de uso común. Estas labels estandarizadas enriquecen los metadatos de una manera que permite que las herramientas, incluyendo `kubectl` y el [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), trabajen de forma interoperable. - Puedes manipular las labels para la depuración. Debido a que los controladores de Kubernetes (como ReplicaSet) y los Services coinciden con los Pods usando labels de selector, se detendrá la eliminación de las labels relevantes de un Pod que sea considerado por un controlador o que un Service sirva tráfico. si quitas las labels de un Pod existente, su controlador creará un nuevo Pod para ocupar su lugar. Esto es un forma útil de depurar un Pod previamente "vivo" en un entorno de "cuarentena". Para eliminar interactivamente o agregar labels, usa [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label). ## Usando kubectl - Usa `kubectl apply -f <directorio>`. Esto busca la configuración de Kubernetes en todos los `.yaml`, `.yml`, y `.json` en `<directorio>` y lo pasa a `apply`. - Usa selectores de labels para las operaciones `get` y `delete` en lugar de nombres de objetos específicos. Ve las secciones en [selectores de labels](/docs/concepts/overview/working-with-objects/labels/#label-selectors) y [usar labels de forma eficaz](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). - Usa `kubectl create deployment` y `kubectl expose` para crear rápidamente un contenedor único Deployments y Services. Consulta [Usar un Service para Acceder a una Aplicación en un Clúster](/docs/tasks/access-application-cluster/service-access-application-cluster/) para un ejemplo. </ins>

This is a Feature Request What would you like to be Localize to Spanish Why is this needed Comments
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language es /kind feature
hey i want to work for it can you plz assign this to me!!
Thanks for participating into the Kubernetes Website project. The Spanish translation team would like to facilitate your contribution's journey, so please share your goals and/or skills in order to assist you better. We also encourage new contributors to participate in their native speaking language.
/assign


Question: card: name: concepts weight: 10 <ins> sitemap: priority: 0.9 </ins> --- <!-- overview -->

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: <ins> --- title: 静的な処理の割り当てを使用した並列処理のためのインデックス付きJob content_type: task min-kubernetes-server-version: v1.21 weight: 30 --- {{< feature-state for_k8s_version="v1.21" state="alpha" >}} <!-- overview --> この例では、複数の並列ワーカープロセスを使用するKubernetesのJobを実行します。各ワーカーは、それぞれが自分のPod内で実行される異なるコンテナです。Podはコントロールプレーンが自動的に設定する*インデックス値*を持ち、この値を利用することで、各Podは処理するタスク全体のどの部分を処理するのかを特定できます。 Podのインデックスは、{{< glossary_tooltip text="アノテーション" term_id="annotation" >}}内の`batch.kubernetes.io/job-completion-index`を整数値の文字列表現として利用できます。コンテナ化されたタスクプロセスがこのインデックスを取得できるようにするために、このアノテーションの値は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)の仕組みを利用することで公開できます。利便性のために、コントロールプレーンは自動的にdownward APIを設定して、`JOB_COMPLETION_INDEX`環境変数にインデックスを公開します。 以下に、この例で実行するステップの概要を示します。 1. **completionのインデックスを使用してJobのマニフェストを定義する**。downward APIはPodのインデックスのアノテーションを環境変数またはファイルとしてコンテナに渡してくれます。 2. **そのマニフェストに基づいてインデックス付き(Indexed)のJobを開始する**。 ## {{% heading "prerequisites" %}} あらかじめ基本的な非並列の[Job](/docs/concepts/workloads/controllers/job/)の使用に慣れている必要があります。 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} インデックス付きJobを作成できるようにするには、[APIサーバー](/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)上で`IndexedJob`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしていることを確認してください。 <!-- steps --> ## アプローチを選択する ワーカープログラムから処理アイテムにアクセスするには、いくつかの選択肢があります。 1. `JOB_COMPLETION_INDEX`環境変数を読み込む。Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、この変数をcompletion indexを含むアノテーションに自動的にリンクします。 1. completion indexを含むファイルを読み込む。 1. プログラムを修正できない場合、プログラムをスクリプトでラップし、上のいずれかの方法でインデックスを読み取り、プログラムが入力として使用できるものに変換する。 この例では、3番目のオプションを選択肢して、[rev](https://man7.org/linux/man-pages/man1/rev.1.html)ユーティリティを実行したいと考えているとしましょう。このプログラムはファイルを引数として受け取り、内容を逆さまに表示します。 ```shell rev data.txt ``` `rev`ツールは[`busybox`](https://hub.docker.com/_/busybox)コンテナイメージから利用できます。 これは単なる例であるため、各Podはごく簡単な処理(短い文字列を逆にする)をするだけです。現実のワークロードでは、たとえば、シーンデータをもとに60秒の動画を生成するというようなタスクを記述したJobを作成するかもしれません。ビデオレンダリングJobの各処理アイテムは、ビデオクリップの特定のフレームのレンダリングを行うものになるでしょう。その場合、インデックス付きの完了が意味するのは、クリップの最初からフレームをカウントすることで、Job内の各Podがレンダリングと公開をするのがどのフレームであるかがわかるということです。 ## インデックス付きJobを定義する 以下は、completion modeとして`Indexed`を使用するJobのマニフェストの例です。 {{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} 上記の例では、Jobコントローラーがすべてのコンテナに設定する組み込みの`JOB_COMPLETION_INDEX`環境変数を使っています。[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)がインデックスを静的な値にマッピングし、その値をファイルに書き込み、ファイルを[emptyDir volume](/docs/concepts/storage/volumes/#emptydir)を介してワーカーを実行しているコンテナと共有します。オプションとして、インデックスとコンテナに公開するために[downward APIを使用して独自の環境変数を定義する](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)こともできます。[環境変数やファイルとして設定したConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)から値のリストを読み込むという選択肢もあります。 他には、以下の例のように、直接[downward APIを使用してアノテーションの値をボリュームファイルとして渡す](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)こともできます。 {{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} ## Jobを実行する 次のコマンドでJobを実行します。 ```shell # このコマンドでは1番目のアプローチを使っています ($JOB_COMPLETION_INDEX に依存しています) kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml ``` このJobを作成したら、コントロールプレーンは指定した各インデックスごとに一連のPodを作成します。`.spec.parallelism`の値が同時に実行できるPodの数を決定し、`.spec.completions`の値がJobが作成するPodの合計数を決定します。 `.spec.parallelism`は`.spec.completions`より小さいため、コントロールプレーンは別のPodを開始する前に最初のPodの一部が完了するまで待機します。 Jobを作成したら、少し待ってから進行状況を確認します。 ```shell kubectl describe jobs/indexed-job ``` 出力は次のようになります。 ``` Name:              indexed-job Namespace:         default Selector:          controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 Labels:            controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 job-name=indexed-job Annotations:       <none> Parallelism:       3 Completions:       5 Start Time:        Thu, 11 Mar 2021 15:47:34 +0000 Pods Statuses:     2 Running / 3 Succeeded / 0 Failed Completed Indexes: 0-2 Pod Template: Labels:  controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 job-name=indexed-job Init Containers: input: Image:      docker.io/library/bash Port:       <none> Host Port:  <none> Command: bash -c items=(foo bar baz qux xyz) echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt Environment:  <none> Mounts: /input from input (rw) Containers: worker: Image:      docker.io/library/busybox Port:       <none> Host Port:  <none> Command: rev /input/data.txt Environment:  <none> Mounts: /input from input (rw) Volumes: input: Type:       EmptyDir (a temporary directory that shares a pod's lifetime) Medium: SizeLimit:  <unset> Events: Type    Reason            Age   From            Message ----    ------            ----  ----            ------- Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-njkjj Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-9kd4h Normal  SuccessfulCreate  4s    job-controller  Created pod: indexed-job-qjwsz Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-fdhq5 Normal  SuccessfulCreate  1s    job-controller  Created pod: indexed-job-ncslj ``` この例では、各インデックスごとにカスタムの値を使用してJobを実行します。次のコマンドでPodの1つの出力を確認できます。 ```shell kubectl logs indexed-job-fdhq5 # これを対象のJobのPodの名前に一致するように変更してください。 ``` 出力は次のようになります。 ``` xuq ``` </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/triage accepted


Question: Kubernetesはオープンソースなので、オンプレミスやパブリッククラウド、それらのハイブリッドなどの利点を自由に得ることができ、簡単に移行することができます。 <ins> Kubernetesをダウンロードするには、[ダウンロード](/releases/download/)セクションを訪れてください。 </ins> {{% /blocks/feature %}} {{< /blocks/section >}}

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 some outdated descriptions in Why is this needed fix missing link to /releases update events Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question:
<button id="desktopShowVideoButton" onclick="kub.showVideo()">ビデオを見る</button>

  2022年5月16日〜20日のKubeCon EUバーチャルに参加する   2023年4月18日〜21日のKubeCon + CloudNativeCon Europeに参加する

  2022年10月24日-28日のKubeCon NAバーチャルに参加する   2023年11月6日〜9日のKubeCon + CloudNativeCon North Americaに参加する


Question: Details of the metric data that Kubernetes components export. --- <del> ## Metrics (v1.26) <!-- (auto-generated 2022 Nov 09) --> <!-- (auto-generated v1.26) --> </del> <ins> ## Metrics (auto-generated 2022 Nov 01) </ins> This page details the metrics that different Kubernetes components export. You can query the metrics endpoint for these components using an HTTP scrape, and fetch the current metrics data in Prometheus format.

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: * `kubectl debug` automatically generates the name of the new Pod based on the name of the Node. <del> * The container runs in the host IPC, Network, and PID namespaces. </del> * The root filesystem of the Node will be mounted at `/host`. <ins> * The container runs in the host IPC, Network, and PID namespaces, although the pod isn't privileged, so reading some process information may fail, and `chroot /host` will fail. * If you need a privileged pod, create it manually. </ins> Don't forget to clean up the debugging Pod when you're finished with it:

This is a Bug Report Problem: The following page writes: As discussed in issue , the use of "privileged" in the phrase "create a privileged Pod" is not standard usage and causes confusion because the pod is not created with the privileged flag (as ). This means that commands such as fail with and reading some process information may fail with . Proposed Solution: As far as what the actual clarification should be instead of the word "privileged", I'm not sure. I think a subject matter expert should opine on that. My guess is it should be something along the lines of: Page to Update: FYI
/assign
/sig cli /language en /triage accepted /remove-kind bug /priority backlog
/unassign PR is an attempt to resolve this issue, but the PR has been closed and this issue is not resolved yet. Please take a look discussions and suggestions in the PR before self-assign. :)
/good-first-issue /assign
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue /assign 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
The PR for this issue has already been raised earlier.


Question: <ins> apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: SPECIAL_LEVEL: very SPECIAL_TYPE: charm </ins>


Question: {{< note >}} 如果集群中正在运行任何 API 服务器，则不应尝试还原 etcd 的实例。相反，请按照以下步骤还原 etcd： <del> - 停止 *所有* kube-apiserver 实例 </del> <ins> - 停止 *所有* API 服务实例 </ins> - 在所有 etcd 实例中恢复状态 <del> - 重启所有 kube-apiserver 实例 </del> <ins> - 重启所有 API 服务实例 </ins> <del> 我们还建议重启所有组件（例如 kube-scheduler、kube-controller-manager、kubelet），以确保它们不会 </del> <ins> 我们还建议重启所有组件（例如 `kube-scheduler`、`kube-controller-manager`、`kubelet`），以确保它们不会 </ins> 依赖一些过时的数据。请注意，实际中还原会花费一些时间。 在还原过程中，关键组件将丢失领导锁并自行重启。 <del> {{< note >}} <!-- ## Upgrading and rolling back etcd clusters As of Kubernetes v1.13.0, etcd2 is no longer supported as a storage backend for new or existing Kubernetes clusters. The timeline for Kubernetes support for etcd2 and etcd3 is as follows: - Kubernetes v1.0: etcd2 only - Kubernetes v1.5.1: etcd3 support added, new clusters still default to etcd2 - Kubernetes v1.6.0: new clusters created with `kube-up.sh` default to etcd3, and `kube-apiserver` defaults to etcd3 - Kubernetes v1.9.0: deprecation of etcd2 storage backend announced - Kubernetes v1.13.0: etcd2 storage backend removed, `kube-apiserver` will refuse to start with `--storage-backend=etcd2`, with the message `etcd2 is no longer a supported storage backend` Before upgrading a v1.12.x kube-apiserver using `--storage-backend=etcd2` to v1.13.x, etcd v2 data MUST by migrated to the v3 storage backend, and kube-apiserver invocations changed to use `--storage-backend=etcd3`. The process for migrating from etcd2 to etcd3 is highly dependent on how the etcd cluster was deployed and configured, as well as how the Kubernetes cluster was deployed and configured. We recommend that you consult your cluster provider's documentation to see if there is a predefined solution. If your cluster was created via `kube-up.sh` and is still using etcd2 as its storage backend, please consult the [Kubernetes v1.12 etcd cluster upgrade docs](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) --> ## 升级和回滚 etcd 集群 从 Kubernetes v1.13.0 开始，不在支持 etcd2 作为新的或现有 Kubernetes 集群的后端。Kubernetes 支持 etcd2 和 etcd3 的时间表如下： - Kubernetes v1.0: 仅限 etcd2 - Kubernetes v1.5.1: 添加了 etcd3 支持，新的集群仍默认为 etcd2 - Kubernetes v1.6.0: 使用 `kube-up.sh` 创建的新集群默认为 etcd3，而 `kube-apiserver` 默认为 etcd3 - Kubernetes v1.9.0: 宣布弃用 etcd2 存储后端 - Kubernetes v1.13.0: 删除了 etcd2 存储后端，`kube-apiserver` 将拒绝以 `--storage-backend = etcd2` 开头，消息 `etcd2 不再是支持的存储后端` 在使用 `--storage-backend = etcd2` 升级 v1.12.x kube-apiserver 到 v1.13.x 之前，etcd v2 数据必须迁移到 v3 存储后端，并且 kube-apiserver 调用改为使用 `--storage-backend=etcd3`。 从 etcd2 迁移到 etcd3 的过程在很大程度上取决于部署和配置 etcd 集群的方式，以及如何部署和配置 Kubernetes 集群。 我们建议您查阅集群提供商的文档，以了解是否存在预定义的解决方案。 如果您的集群是通过 `kube-up.sh` 创建的并且仍然使用 etcd2 作为其存储后端，请参阅 [Kubernetes v1.12 etcd 集群升级文档](https://v1-12.docs.kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#upgrading-and-rolling-back-etcd-clusters) <!-- ## Known issue: etcd client balancer with secure endpoints The etcd v3 client, released in etcd v3.3.13 or earlier, has a [critical bug](https://github.com/kubernetes/kubernetes/issues/72102) which affects the kube-apiserver and HA deployments. The etcd client balancer failover does not properly work against secure endpoints. As a result, etcd servers may fail or disconnect briefly from the kube-apiserver. This affects kube-apiserver HA deployments. The fix was made in [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) (and backported to v3.3.14 or later): the new client now creates its own credential bundle to correctly set authority target in dial function. Because the fix requires gRPC dependency upgrade (to v1.23.0), downstream Kubernetes [did not backport etcd upgrades](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978). Which means the [etcd fix in kube-apiserver](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) is only available from Kubernetes 1.16. To urgently fix this bug for Kubernetes 1.15 or earlier, build a custom kube-apiserver. You can make local changes to [`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) with [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab). See ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). --> ## 已知问题：具有安全端点的 etcd 客户端均衡器 在 etcd v3.3.13 或更早版本的 etcd v3 客户端有一个[严重的错误](https://github.com/kubernetes/kubernetes/issues/72102)，会影响 kube-apiserver 和 HA 部署。etcd 客户端平衡器故障转移不适用于安全端点。结果是，etcd 服务器可能会失败或短暂地与 kube-apiserver 断开连接。这会影响 kube-apiserver HA 的部署。 该修复程序是在 [etcd v3.4](https://github.com/etcd-io/etcd/pull/10911) 中进行的（并反向移植到 v3.3.14 或更高版本）：现在，新客户端将创建自己的凭证捆绑包，以在拨号功能中正确设置授权目标。 因为此修复程序要求将 gRPC 依赖升级（到 v1.23.0 ），因此，下游 Kubernetes [未反向移植 etcd 升级](https://github.com/kubernetes/kubernetes/issues/72102#issuecomment-526645978)。这意味着只能从 Kubernetes 1.16 获得 [kube-apiserver 中的 etcd 修复](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab)。 要紧急修复 Kubernetes 1.15 或更早版本的此错误，请构建一个自定义的 kube-apiserver 。 您可以使用[`vendor/google.golang.org/grpc/credentials/credentials.go`](https://github.com/kubernetes/kubernetes/blob/7b85be021cd2943167cd3d6b7020f44735d9d90b/vendor/google.golang.org/grpc/credentials/credentials.go#L135) 和 [etcd@db61ee106](https://github.com/etcd-io/etcd/pull/10911/commits/db61ee106ca9363ba3f188ecf27d1a8843da33ab) 来进行本地更改。 请看  ["kube-apiserver 1.13.x refuses to work when first etcd-server is not available"](https://github.com/kubernetes/kubernetes/issues/72102). </del> <ins> {{< note >}} </ins>  No newline at end of file


Question: ### Linux {{< note >}} <del> Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://github.com/kubernetes/minikube#other-ways-to-install) im offiziellen Minikube-GitHub-Repository. </del> <ins> Dieses Dokument zeigt Ihnen, wie Sie Minikube mit einer statischen Binärdatei unter Linux installieren. Für alternative Linux-Installationsmethoden siehe [Andere Installationsmethoden](https://minikube.sigs.k8s.io/docs/start/) im offiziellen Minikube-GitHub-Repository. </ins> {{< /note >}} Sie können Minikube unter Linux installieren, indem Sie eine statische Binärdatei herunterladen:

"Ander Installationsmethoden" here should not be a link to github but to this link:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language de /kind cleanup /priority backlog Actually should either redirect to the (English) page, or it should be a stub that links there and explains that the documentation for Minikube is not localized.
/assign


Question: 쿠버네티스 DNS는 클러스터의 서비스와 DNS 파드를 관리하며, 개별 컨테이너들이 DNS 네임을 해석할 때 <del> DNS 서비스의 IP를 사용하도록 kubelets를 구성한다. </del> <ins> DNS 서비스의 IP를 사용하도록 kubelet을 구성한다. </ins> 클러스터 내의 모든 서비스(DNS 서버 자신도 포함하여)에는 DNS 네임이 할당된다. 기본적으로 클라이언트 파드의 DNS 검색 리스트는 파드 자체의 네임스페이스와

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: body.cid-community .community-section.community-frame { <del> width: 100vw; </del> <ins> width: 100%; </ins> } body.cid-community .community-section.community-frame .twittercol1 {

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: --- title: コンテンツの構造化 content_type: concept <del> weight: 40 </del> <ins> weight: 90 </ins> --- <!-- overview -->

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: ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:

In section it is said: The CRD can be either namespaced or cluster-scoped, as specified in the CRD's That text is wrong (a CRD object and the custom resource created from that CRD object are not the same). It should better say: The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's field
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
/wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix?
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix? </details
Thanks Yes, I am raising the PR. It is to be the first one I am creating against kubernetes documentation. Anything I should take care of? (thanks in advance ;-)
I found all details in . I am then following it ;-)
/wg api-expression
you've found the right guide. I hope it covers everything you need to know, but if it doesn't then please feel free to ask questions.
I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help?


Question: ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`:

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 : I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign 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
Saw this good first issue with no one assigned, I could take it up /assign
Thanks a lot for putting hands on this ... and sorry a lot for not having done it myself as initially proposed (I was disconnected for some long time).


Question: <ins> apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: access-nginx spec: podSelector: matchLabels: app: nginx ingress: - from: - podSelector: matchLabels: access: "true" </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign


Question:
[thirdparty_message] other = """Ta sekcja przekierowuje do projektów osób trzecich, które udostępniają funkcjonalność wymaganą przez Kubernetesa. Autory projektu Kubernetes nie są odpowiedzialni za te projekty. Ta strona podąża za wytycznymi CNCF dla stron internetowych aby pokazać projekty w kolejności alfabetycznej. Aby dodać projekt na tę listę przeczytaj wytyczne dla zawartości przed wysyłaniem zmian."""  [thirdparty_message_edit_disclaimer] other="""Zastrzeżenie dotyczące zawartości zewnętrznej""" [thirdparty_message_single_item] other = """🛇 Ta pozycja przekierowuje do projektu lub produktu osób trzecich, będących poza projektem Kubernetes. Więcej informacji""" [thirdparty_message_disclaimer] other = """
Niektóre elementy na tej stronie odnoszą się do zewnętrznych produktów lub projektów, które dostarczają funkcjonalności wymagane przez Kubernetesa. Autorzy projektu Kubernetes nie ponoszą odpowiedzialności za te produkty oraz projekty. Zajrzyj na stronę CNCF website guidelines po więcej informacji.

Zapoznaj się także z  content guide zanim zaproponujesz zmianę dodającą odnośnik do zewnętrznej strony.
"""  [ui_search_placeholder] other = "Szukaj"

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: <ins> --- title: Adding Windows worker nodes content_type: task weight: 50 --- <!-- overview --> This page explains how to add Windows worker nodes to a kubeadm cluster. ## {{% heading "prerequisites" %}} * A running [Windows Server 2022](https://www.microsoft.com/cloud-platform/windows-server-pricing) (or higher) instance with administrative access. * A running kubeadm cluster created by `kubeadm init` and following the steps in the document [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). <!-- steps --> ## Adding Windows worker nodes {{< note >}} To facilitate the addition of Windows worker nodes to a cluster, PowerShell scripts from the repository https://sigs.k8s.io/sig-windows-tools are used. {{< /note >}} Do the following for each machine: 1. Open a PowerShell session on the machine. 1. Make sure you are Administrator or a privileged user. Then proceed with the steps outlined below. ### Install containerd {{% thirdparty-content %}} To install containerd, first run the following command: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/Install-Containerd.ps1 `````` Then run the following command, but first replace `CONTAINERD_VERSION` with a recent release from the [containerd repository](https://github.com/containerd/containerd/releases). The version must not have a `v` prefix. For example, use `1.7.22` instead of `v1.7.22`: ```PowerShell .Install-Containerd.ps1 -ContainerDVersion CONTAINERD_VERSION ``` * Adjust any other parameters for `Install-Containerd.ps1` such as `netAdapterName` as you need them. * Set `skipHypervisorSupportCheck` if your machine does not support Hyper-V and cannot host Hyper-V isolated containers. * If you change the `Install-Containerd.ps1` optional parameters `CNIBinPath` and/or `CNIConfigPath` you will need to configure the installed Windows CNI plugin with matching values. ### Install kubeadm and kubelet Run the following commands to install kubeadm and the kubelet: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/PrepareNode.ps1 .PrepareNode.ps1 -KubernetesVersion v{{< skew currentVersion >}} ``` * Adjust the parameter `KubernetesVersion` of `PrepareNode.ps1` if needed. ### Run `kubeadm join` Run the command that was output by `kubeadm init`. For example: ```bash kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash> ``` #### Additional information about kubeadm join {{< note >}} To specify an IPv6 tuple for `<control-plane-host>:<control-plane-port>`, IPv6 address must be enclosed in square brackets, for example: `[2001:db8::101]:2073`. {{< /note >}} If you do not have the token, you can get it by running the following command on the control plane node: ```bash kubeadm token list ``` The output is similar to this: ```console TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS 8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system: signing          token generated by     bootstrappers: 'kubeadm init'.        kubeadm: default-node-token ``` By default, node join tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control plane node: ```bash kubeadm token create ``` The output is similar to this: ```console 5didvk.d09sbcov8ph2amjw ``` If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following commands on the control plane node: ```bash sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey  | openssl rsa -pubin -outform der 2>/dev/null |  openssl dgst -sha256 -hex | sed 's/^.* //' ``` The output is similar to: ```console 8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 ``` The output of the `kubeadm join` command should look something like: ``` [preflight] Running pre-flight checks ... (log output of join workflow) ... Node join complete: * Certificate signing request sent to control-plane and response received. * Kubelet informed of new secure connection details. Run 'kubectl get nodes' on control-plane to see this machine join. ``` A few seconds later, you should notice this node in the output from `kubectl get nodes`. (for example, run `kubectl` on a  control plane node). ### Network configuration CNI setup on clusters mixed with Linux and Windows nodes requires more steps than just running `kubectl apply` on a manifest file. Additionally, the CNI plugin running on control plane nodes must be prepared to support the CNI plugin running on Windows worker nodes. {{% thirdparty-content %}} Only a few CNI plugins currently support Windows. Below you can find individual setup instructions for them: * [Flannel](https://sigs.k8s.io/sig-windows-tools/guides/flannel.md) * [Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/windows-calico/) ### Install kubectl for Windows (optional) {#install-kubectl} See [Install and Set Up kubectl on Windows](/docs/tasks/tools/install-kubectl-windows/). ## {{% heading "whatsnext" %}} * See how to [add Linux worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-linux-nodes/). </ins>

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: <ins> --- title: Adding Windows worker nodes content_type: task weight: 50 --- <!-- overview --> This page explains how to add Windows worker nodes to a kubeadm cluster. ## {{% heading "prerequisites" %}} * A running [Windows Server 2022](https://www.microsoft.com/cloud-platform/windows-server-pricing) (or higher) instance with administrative access. * A running kubeadm cluster created by `kubeadm init` and following the steps in the document [Creating a cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). <!-- steps --> ## Adding Windows worker nodes {{< note >}} To facilitate the addition of Windows worker nodes to a cluster, PowerShell scripts from the repository https://sigs.k8s.io/sig-windows-tools are used. {{< /note >}} Do the following for each machine: 1. Open a PowerShell session on the machine. 1. Make sure you are Administrator or a privileged user. Then proceed with the steps outlined below. ### Install containerd {{% thirdparty-content %}} To install containerd, first run the following command: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/Install-Containerd.ps1 `````` Then run the following command, but first replace `CONTAINERD_VERSION` with a recent release from the [containerd repository](https://github.com/containerd/containerd/releases). The version must not have a `v` prefix. For example, use `1.7.22` instead of `v1.7.22`: ```PowerShell .Install-Containerd.ps1 -ContainerDVersion CONTAINERD_VERSION ``` * Adjust any other parameters for `Install-Containerd.ps1` such as `netAdapterName` as you need them. * Set `skipHypervisorSupportCheck` if your machine does not support Hyper-V and cannot host Hyper-V isolated containers. * If you change the `Install-Containerd.ps1` optional parameters `CNIBinPath` and/or `CNIConfigPath` you will need to configure the installed Windows CNI plugin with matching values. ### Install kubeadm and kubelet Run the following commands to install kubeadm and the kubelet: ```PowerShell curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/hostprocess/PrepareNode.ps1 .PrepareNode.ps1 -KubernetesVersion v{{< skew currentVersion >}} ``` * Adjust the parameter `KubernetesVersion` of `PrepareNode.ps1` if needed. ### Run `kubeadm join` Run the command that was output by `kubeadm init`. For example: ```bash kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash> ``` #### Additional information about kubeadm join {{< note >}} To specify an IPv6 tuple for `<control-plane-host>:<control-plane-port>`, IPv6 address must be enclosed in square brackets, for example: `[2001:db8::101]:2073`. {{< /note >}} If you do not have the token, you can get it by running the following command on the control plane node: ```bash kubeadm token list ``` The output is similar to this: ```console TOKEN                    TTL  EXPIRES              USAGES           DESCRIPTION            EXTRA GROUPS 8ewj1p.9r9hcjoqgajrj4gi  23h  2018-06-12T02:51:28Z authentication,  The default bootstrap  system: signing          token generated by     bootstrappers: 'kubeadm init'.        kubeadm: default-node-token ``` By default, node join tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control plane node: ```bash kubeadm token create ``` The output is similar to this: ```console 5didvk.d09sbcov8ph2amjw ``` If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following commands on the control plane node: ```bash sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey  | openssl rsa -pubin -outform der 2>/dev/null |  openssl dgst -sha256 -hex | sed 's/^.* //' ``` The output is similar to: ```console 8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78 ``` The output of the `kubeadm join` command should look something like: ``` [preflight] Running pre-flight checks ... (log output of join workflow) ... Node join complete: * Certificate signing request sent to control-plane and response received. * Kubelet informed of new secure connection details. Run 'kubectl get nodes' on control-plane to see this machine join. ``` A few seconds later, you should notice this node in the output from `kubectl get nodes`. (for example, run `kubectl` on a  control plane node). ### Network configuration CNI setup on clusters mixed with Linux and Windows nodes requires more steps than just running `kubectl apply` on a manifest file. Additionally, the CNI plugin running on control plane nodes must be prepared to support the CNI plugin running on Windows worker nodes. {{% thirdparty-content %}} Only a few CNI plugins currently support Windows. Below you can find individual setup instructions for them: * [Flannel](https://sigs.k8s.io/sig-windows-tools/guides/flannel.md) * [Calico](https://docs.tigera.io/calico/latest/getting-started/kubernetes/windows-calico/) ### Install kubectl for Windows (optional) {#install-kubectl} See [Install and Set Up kubectl on Windows](/docs/tasks/tools/install-kubectl-windows/). ## {{% heading "whatsnext" %}} * See how to [add Linux worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-linux-nodes/). </ins>

/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 p:last-of-type { margin-bottom: 6em; /* extra space for background */ } <ins> } @media only screen and (max-width: 767px) { body.cid-community .community-section h2:before, body.cid-community .community-section h2:after { display: none; } </ins> }  No newline at end of file


Question: $ kubectl attach <podname> -i                             # Attach to Running Container $ kubectl port-forward <podname> <local-and-remote-port>  # Forward port of Pod to your local machine $ kubectl port-forward <servicename> <port>               # Forward port to service <del> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </del> <ins> $ kubectl exec <pod-name> -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec <pod-name> -c <container-name> -- ls /     # Run command in existing pod (multi-container case) </ins> ```

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: $ kubectl logs -f my-pod -c my-container              # stream pod container logs (stdout, multi-container case) $ kubectl run -i --tty busybox --image=busybox -- sh  # Run pod as interactive shell $ kubectl attach my-pod -i                            # Attach to Running Container <del> $ kubectl port-forward my-pod 5000:6000               # Forward port 6000 of Pod to your to 5000 on your local machine </del> <ins> $ kubectl port-forward my-pod 5000:6000               # Listen on port 5000 on the local machine and forward to port 6000 on my-pod </ins> $ kubectl exec my-pod -- ls /                         # Run command in existing pod (1 container case) $ kubectl exec my-pod -c my-container -- ls /         # Run command in existing pod (multi-container case) $ kubectl top pod POD_NAME --containers               # Show metrics for a given pod and its containers

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [x] Feature Request [ ] Bug Report Problem: The port-forward command description is misleading. As a user I would expect the command to forward the complete traffic from port 6000 to 5000 locally, not only the data from both ports like the explanation in the detailed command page mentions. Proposed Solution: You could change the description to something like in the detail command description () or change the command to the version it describes. (kubectl port-forward my-pod 5000:6000 -with colon) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: [release_date_format] other = "2006-01-02" <ins> # Deprecated. Planned for removal in a future release. # Use [release_full_details_initial_text] instead. [release_complete] other = "完整的" # Replace [release_complete] with [release_full_details_initial_text] [release_full_details_initial_text] other = "完整的" [release_schedule] other = "排期表" [release_changelog] other = "变更记录" </ins> [seealso_heading] 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: <del> You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. </del> <ins> You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , There are some redirection rules with wildcard(``). Expectation: Netlify redirects to Reality: gives Instead, Netlify redirects (literally) to (literally) Expectation: Netlify redirects to Reality: Netlify redirects to (with trailing slash) which is not a valid anchor URL (because of the trailing slash). Proposed Solution: File to Update:  <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I would like to give this a try /assign
how can I test these redirect things after I made the changes? Do I have to make a PR to get the netlify link to test the things?
Are you working on this issue?
Ya I was trying but couldn't figure out how can I test these redirects after making the changes
Thanks, I will unassign myself. Please consider commenting before. It helps others to know about the progress of issue. /unassign
/assign
It was my bad.
I think the problem is with the link itself. Here may be is the splat. Maybe that's why it's unable to redirect. If I change the redirect to something like below without the .md it works fine And for this link , the splat is get/ and hence it redirects to This can be resolve if we remove the trailing slash from this link So, where are all these links present if we want to modify the link itself?
What a great research! I think so.


Question: <del> You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. </del> <ins> You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. </ins>

To do tests, you should changes on  file, a PR, and the redirection rules on the deploy preview: https://deploy-preview-xxxxx--kubernetes-io-main- And regarding your research, I suggest to make changes like these: and test on the deploy preview of the PR you will post. I did some searching and found these: content/en/blog/posts/2016-08-00-Kubernetes-Namespaces-Use-Cases- content/en/blog/posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-
I have made the PR. Let me know if I have to do some more changes or anything


Question: Pods aren't intended to be treated as durable entities. They won't survive scheduling failures, node failures, or other evictions, such as due to lack of resources, or in the case of node maintenance. <del> In general, users shouldn't need to create pods directly. They should almost always use controllers (e.g., [Deployments](/docs/concepts/workloads/controllers/deployment/)), even for singletons.  Controllers provide self-healing with a cluster scope, as well as replication and rollout management. </del> <ins> In general, users shouldn't need to create pods directly. They should almost always use controllers even for singletons, for example, [Deployments](/docs/concepts/workloads/controllers/deployment/)). Controllers provide self-healing with a cluster scope, as well as replication and rollout management. Controllers like [StatefulSet](/docs/concepts/workloads/controllers/statefulset.md) can also provide support to stateful pods. </ins> The use of collective APIs as the primary user-facing primitive is relatively common among cluster scheduling systems, including [Borg](https://research.google.com/pubs/pub43438.html), [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html), [Aurora](http://aurora.apache.org/documentation/latest/reference/configuration/#job-schema), and [Tupperware](http://www.slideshare.net/Docker/aravindnarayanan-facebook140613153626phpapp02-37588997).

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: kubectl apply -f <add-on.yaml> ``` <ins> {{< note >}} Only a few CNI plugins support Windows. More details and setup instructions can be found in [Adding Windows worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/#network-config). {{< /note >}} </ins> You can install only one Pod network per cluster. Once a Pod network has been installed, you can confirm that it is working by


Question: kubectl apply -f <add-on.yaml> ``` <ins> {{< note >}} Only a few CNI plugins support Windows. More details and setup instructions can be found in [Adding Windows worker nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/#network-config). {{< /note >}} </ins> You can install only one Pod network per cluster. Once a Pod network has been installed, you can confirm that it is working by


Question: convert your old configuration files to a newer version. `kubeadm config images list` and `kubeadm config images pull` can be used to list and pull the images that kubeadm requires. <ins> For more information navigate to [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). </ins> In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used.

It is very difficult to find any links to the . This is a huge roadblock to new users trying to do anything custom with kubeadm. As a new user, I don't expect to have to read about to find information about configuring the tool. To someone who is unfamiliar with the project, that seems like more advanced documentation than I should need, and therefore not somewhere I would expect to find basic config file documentation. I also was able to find the long before I found the more user-friendly documentation, which made it seem like that was the only documentation that exists. I would expect a link to those docs to be available on the kubeadm-config page, as well as where config files are mentioned in the kubeadm-init and kubeadm-join pages.
/language en
it seems you have missed these two sections: and for these commands the kubeadm API is actually the most important for. linking the command line reference page to the API makes sense. but instead of linking to a particular version of the API we should link to: and let users navigate to a particular API version. this is done with the idea that can also migrate v1beta1 -v1beta2. PRs welcome. thanks /sig cluster-lifecycle /priority backlog /help wanted
. I will keep most of the discussion over there for now.
/remove-help /assign /lifecycle-active sending a PR with:


Question: <ins> apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: k8s.gcr.io/busybox command: [ "/bin/sh","-c","cat /etc/config/keys" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: special-config items: - key: SPECIAL_LEVEL path: keys restartPolicy: Never </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 Translate tasks/configure-pod-container/configure-pod-configmap/ into Japanese. Why is this needed This page has not been translated. Comments /language ja
/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:
# i18n strings for the Polish site. # NOTE: Please keep the entries in alphabetical order when editing  # For "and", see [conjunction_1] [auto_generated_edit_notice] other = "(strona utworzona automatycznie)" [auto_generated_pageinfo] other = """
Ta strona została utworzona przez automat.

Jeśli chcesz zgłosić problem dotyczący tej strony, pamiętaj o zaznaczeniu, że została wygenerowana automatycznie. Może być konieczna zmiana w zupełnie innymi miejscu projektu Kubernetes.
"""  [caution] other = "Ostrzeżenie:"


Question: [community_youtube_name] other = "YouTube" <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 = "i" [cve_id] other = "CVE ID" [cve_issue_url] other = "URL do CVE w GitHubie" [cve_json_external_url] other = "external_url" [cve_json_id] other = "id" [cve_json_summary] other = "podsumowanie" [cve_json_url] other = "url" [cve_summary] other = "Podsumowanie problemu" [cve_table] other = "Oficjalna lista CVE Kubernetesa" [cve_url] other = "CVE URL" </ins> [deprecation_title] other = "Teraz oglądasz dokumentację Kubernetesa w wersji:"


Question: Production likes to run cattle, so let's create some cattle pods. ```shell <del> kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5 -n=production </del> <ins> kubectl create deployment cattle --image=k8s.gcr.io/serve_hostname -n=production kubectl scale deployment cattle --replicas=5 -n=production </ins> kubectl get deployment -n=production ```

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: After creating and scaling deployment using command kubectl create deployment cattle -- kubectl scale deployment cattle --replicas=5 When we execute below command to list pods with options -l kubectl get pods -l run=cattle O/P is No resources found in production namespace. Proposed Solution: kubectl get pods -l app=cattle Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
can you / have you confirmed that this is a bug? If so, it's be good to record this issue as /kind bug
Yes, this is a bug. When was changed to , the label should have changed from to . This needs to be updated on a couple of other pages as well. /kind bug
/priority backlog


Question: <ins> --- title: "セキュリティ" weight: 40 --- </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