Question: <ins> --- title: Participating in SIG Docs content_type: concept weight: 60 card: name: contribute weight: 60 --- <!-- overview --> SIG Docs is one of the [special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md) within the Kubernetes project, focused on writing, updating, and maintaining the documentation for Kubernetes as a whole. See [SIG Docs from the community github repo](https://github.com/kubernetes/community/tree/master/sig-docs) for more information about the SIG. SIG Docs welcomes content and reviews from all contributors. Anyone can open a pull request (PR), and anyone is welcome to file issues about content or comment on pull requests in progress. You can also become a [member](/docs/contribute/participating/roles-and-responsibilities/#members), [reviewer](/docs/contribute/participating/roles-and-responsibilities/#reviewers), or [approver](/docs/contribute/participating/roles-and-responsibilities/#approvers). These roles require greater access and entail certain responsibilities for approving and committing changes. See [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) for more information on how membership works within the Kubernetes community. The rest of this document outlines some unique ways these roles function within SIG Docs, which is responsible for maintaining one of the most public-facing aspects of Kubernetes -- the Kubernetes website and documentation. <!-- body --> ## SIG Docs chairperson Each SIG, including SIG Docs, selects one or more SIG members to act as chairpersons. These are points of contact between SIG Docs and other parts of the Kubernetes organization. They require extensive knowledge of the structure of the Kubernetes project as a whole and how SIG Docs works within it. See [Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) for the current list of chairpersons. ## SIG Docs teams and automation Automation in SIG Docs relies on two different mechanisms: GitHub teams and OWNERS files. ### GitHub teams There are two categories of SIG Docs [teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) on GitHub: - `@sig-docs-{language}-owners` are approvers and leads - `@sig-docs-{language}-reviewers` are reviewers Each can be referenced with their `@name` in GitHub comments to communicate with everyone in that group. Sometimes Prow and GitHub teams overlap without matching exactly. For assignment of issues, pull requests, and to support PR approvals, the automation uses information from `OWNERS` files. ### OWNERS files and front-matter The Kubernetes project uses an automation tool called prow for automation related to GitHub issues and pull requests. The [Kubernetes website repository](https://github.com/kubernetes/website) uses two [prow plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins): - blunderbuss - approve These two plugins use the [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) and [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) files in the top level of the `kubernetes/website` GitHub repository to control how prow works within the repository. An OWNERS file contains a list of people who are SIG Docs reviewers and approvers. OWNERS files can also exist in subdirectories, and can override who can act as a reviewer or approver of files in that subdirectory and its descendants. For more information about OWNERS files in general, see [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). In addition, an individual Markdown file can list reviewers and approvers in its front-matter, either by listing individual GitHub usernames or GitHub groups. The combination of OWNERS files and front-matter in Markdown files determines the advice PR owners get from automated systems about who to ask for technical and editorial review of their PR. ## How merging works When a pull request is merged to the branch used to publish content, that content is published to http://kubernetes.io. To ensure that the quality of our published content is high, we limit merging pull requests to SIG Docs approvers. Here's how it works. - When a pull request has both the `lgtm` and `approve` labels, has no `hold` labels, and all tests are passing, the pull request merges automatically. - Kubernetes organization members and SIG Docs approvers can add comments to prevent automatic merging of a given pull request (by adding a `/hold` comment or withholding a `/lgtm` comment). - Any Kubernetes member can add the `lgtm` label by adding a `/lgtm` comment. - Only SIG Docs approvers can merge a pull request by adding an `/approve` comment. Some approvers also perform additional specific roles, such as [PR Wrangler](/docs/contribute/advanced#be-the-pr-wrangler-for-a-week) or [SIG Docs chairperson](#sig-docs-chairperson). ## {{% heading "whatsnext" %}} For more information about contributing to the Kubernetes documentation, see: - [Contributing new content](/docs/contribute/overview/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) </ins>

Parent issue: Part 1 of the reorganization effort for the participating section.
/language en
/priority important-longterm
/assign


Question: `kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`. `$NODE` must be set to the name of the existing failed node in the cluster. Modify the resulted `kubelet.conf` manually to adjust the cluster name and server endpoint, <del> or pass `kubeconfig user --config` (it accepts `InitConfiguration`). If your cluster does not have </del> <ins> or pass `kubeconfig user --config` (see [Generating kubeconfig files for additional users](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubeconfig-additional-users)). If your cluster does not have </ins> the `ca.key` you must sign the embedded certificates in the `kubelet.conf` externally. 1. Copy this resulted `kubelet.conf` to `/etc/kubernetes/kubelet.conf` on the failed node. 1. Restart the kubelet (`systemctl restart kubelet`) on the failed node and wait for

In the paragraph under a working control plane node in the cluster that has execute kubeadm kubeconfig user --org system:nodes --client-name system:node:NODE must be set to the name of the existing failed node in the cluster. Modify the resulted manually to adjust the cluster name and server endpoint, or pass kubeconfig user --config (it accepts InitConfiguration). If your cluster does not have the you must sign the embedded certificates in the externally. I do not know where or what the "InitConfiguration" is, nor does the command run without specifying a --config. Could someone add a little more information or example to this?
Page reported in issue: /language en
/retitle Lack of clarity on usage of within the "Troubleshooting kubeadm" page
/sig cluster-lifecycle
all kubeadm commands have reference pages
About InitConfiguration is explained
if you go to that page there is a guide on how to generate kubeconfig files. but the text under should probably mention /help /triage accepted replace: with:
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 : all kubeadm commands have reference pages /triage accepted (it accepts InitConfiguration (see ) </details
/assign
Please review the PR.
I just wanted to say thank you very much. I really appreciate that link going into the paragraph so I can follow it to the reference.


Question: 参阅[容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/) 以了解更多信息。 <del> <!-- </del> {{< note >}} <ins> <!-- </ins> Docker Engine does not implement the [CRI](/docs/concepts/architecture/cri/) which is a requirement for a container runtime to work with Kubernetes. For that reason, an additional service [cri-dockerd](https://github.com/Mirantis/cri-dockerd) has to be installed. cri-dockerd is a project based on the legacy built-in Docker Engine support that was [removed](/dockershim) from the kubelet in version 1.24. --> <del> {{< note >}} </del> Docker Engine 没有实现 [CRI](/zh-cn/docs/concepts/architecture/cri/)，而这是容器运行时在 Kubernetes 中工作所需要的。 为此，必须安装一个额外的服务 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)。 cri-dockerd 是一个基于传统的内置Docker引擎支持的项目，它在 1.24 版本从 kubelet 中[移除](/zh-cn/dockershim)。

(kubeadm) []
/triage accepted /kind bug /assign /language zh


Question:
 {% for version in page.versions %}
{{ version.version }}
   {% if page.versionedurl contains version.version %}
{{ version.version }}
 {% else  %}
{{ version.version }}
 {% endif %}  {% endfor %}

<!-- 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: When switching to a different version of the docs, I get redirected to the root of the doc tree. Proposed Solution: Would be nice to redirect users to an equivalent page in the previous version of docs. Easy way to get started would be to just support pages that haven't moved or been refactored. Could get fancier after that.
Also related (found while I was reproducing this), the drop-down mechanism that allows version changing doesn't render correctly on safari (mobile or laptop) so that you can't choose the older versions, and the same happens in Chrome (IOS) - you see part of 1.8, but the rest of the list is cut off. See embedded screenshot (from Chrome IOS) !
I've attempted to implement a solution to this in . This part works by default This part requires setting data on the page as to where to send the person.
This issue is still present on the current version of the website.
not sure if we should reopen this issue or file a new one as a bug report but this no longer works. from what I can tell during the migration to hugo the header file was removed


Question: <ins> --- layout: blog title: "聚光灯下的 SIG Instrumentation" slug: sig-instrumentation-spotlight-2023 date: 2023-02-03 --- <!-- layout: blog title: "Spotlight on SIG Instrumentation" slug: sig-instrumentation-spotlight-2023 date: 2023-02-03 canonicalUrl: https://www.kubernetes.dev/blog/2023/02/03/sig-instrumentation-spotlight-2023/ --> <!-- **Author:** Imran Noor Mohamed (Delivery Hero) --> **作者**: Imran Noor Mohamed (Delivery Hero) **译者**: [Kevin Yang](https://github.com/kevin1689-cloud) <!-- Observability requires the right data at the right time for the right consumer (human or piece of software) to make the right decision. In the context of Kubernetes, having best practices for cluster observability across all Kubernetes components is crucial. --> 可观测性需要在合适的时间提供合适的数据，以便合适的消费者（人员或软件）做出正确的决策。 在 Kubernetes 的环境中，拥有跨所有 Kubernetes 组件的集群可观测性最佳实践是至关重要的。 <!-- SIG Instrumentation helps to address this issue by providing best practices and tools that all other SIGs use to instrument Kubernetes components-like the *API server*, *scheduler*, *kubelet* and *kube-controller-manager*. --> SIG Instrumentation 通过提供最佳实践和工具来解决这个问题， 所有其他 SIG 都可以使用它们来对如 **API 服务器**、**kubelet** 和 **kube-controller-manager** 这类 Kubernetes 组件进行插桩。 <!-- In this SIG Instrumentation spotlight, [Imran Noor Mohamed](https://www.linkedin.com/in/imrannoormohamed/), SIG ContribEx-Comms tech lead talked with [Elana Hashman](https://twitter.com/ehashdn), and [Han Kang](https://www.linkedin.com/in/hankang), chairs of SIG Instrumentation, on how the SIG is organized, what are the current challenges and how anyone can get involved and contribute. --> 在这次 SIG Instrumentation 采访报道中，SIG ContribEx-Comms 技术主管 [Imran Noor Mohamed](https://www.linkedin.com/in/imrannoormohamed/) 与 SIG Instrumentation 的两位主席 [Elana Hashman](https://twitter.com/ehashdn) 和 [Han Kang](https://www.linkedin.com/in/hankang) 讨论了 SIG 的组织结构、当前的挑战以及大家如何参与并贡献。 <!-- ## About SIG Instrumentation **Imran (INM)**: Hello, thank you for the opportunity of learning more about SIG Instrumentation. Could you tell us a bit about yourself, your role, and how you got involved in SIG Instrumentation? --> ## 关于 SIG Instrumentation **Imran (INM)**: 你好，感谢你给我这个机会进一步了解关于 SIG Instrumentation 的情况。 你能否介绍一下你自己、你的角色以及你是如何参与 SIG Instrumentation 的？ <!-- **Han (HK)**: I started in SIG Instrumentation in 2018, and became a chair in 2020. I primarily got involved with SIG instrumentation due to a number of upstream issues with metrics which ended up affecting GKE in bad ways. As a result, we ended up launching an initiative to stabilize our metrics and make metrics a proper API. --> **Han (HK)**: 我在 2018 年开始参与 SIG Instrumentation，并于 2020 年成为主席。 我参与 SIG Instrumentation 主要是因为一些上游的指标问题对 GKE 造成了不好的影响。 因此我们发起了一个活动，目的是让我们的指标更稳定并将这些指标打造成一个合适的 API 。 <!-- **Elana (EH)**: I also joined SIG Instrumentation in 2018 and became a chair at the same time as Han. I was working as a site reliability engineer (SRE) on bare metal Kubernetes clusters and was working to build out our observability stack. I encountered some issues with label joins where Kubernetes metrics didn’t match kube-state-metrics ([KSM](https://github.com/kubernetes/kube-state-metrics)) and started participating in SIG meetings to improve things. I helped test performance improvements to kube-state-metrics and ultimately coauthored a KEP for overhauling metrics in the 1.14 release to improve usability. --> **Elana (EH)**: 我也是在 2018 年加入了 SIG Instrumentation，并与 Han 同时成为主席。 当时我是一名负责裸金属 Kubernetes 集群的站点可靠性工程师（site reliability engineer，SRE）， 致力于构建我们的可观测性堆栈。我在标签关联方面遇到了一些问题，具体来说是 Kubernetes 的指标与 kube-state-metrics（[KSM](https://github.com/kubernetes/kube-state-metrics)）不匹配， 因此我开始参加 SIG 会议以改进这些方面。我帮助测试了 kube-state-metrics 的性能改进， 并最终共同撰写了一个关于在 1.14 版本中彻底改进指标以提高其可用性的 KEP 提案。 <!-- **Imran (INM)**: Interesting! Does that mean SIG Instrumentation involves a lot of plumbing? --> **Imran (INM)**: 有趣！这是否意味着 SIG Instrumentation 涉及很多的钻研工作？ <!-- **Han (HK)**: I wouldn’t say it involves a ton of plumbing, though it does touch basically every code base. We have our own dedicated directories for our metrics, logs, and tracing frameworks which we tend to work out of primarily. We do have to interact with other SIGs in order to propagate our changes which makes us more of a horizontal SIG. --> **Han (HK)**: 我不会说它涉及大量的钻研工作，但它确实触及了基本上每个代码库。 我们有专门的目录用于我们的 metrics、logs 和 tracing 框架，这些是我们要完成的主要工作。 我们必须与其他 SIG 进行互动以推动我们的变更，这使我们更加成为一个横向的 SIG。 <!-- **Imran (INM)**: Speaking about interaction and coordination with other SIG could you describe how the SIGs is organized? --> **Imran (INM)**: 谈到与其他 SIG 的互动和协调，你能描述一下 SIG 是如何组织的吗？ <!-- **Elana (EH)**: In SIG Instrumentation, we have two chairs, Han and myself, as well as two tech leads, David Ashpole and Damien Grisonnet. We all work together as the SIG’s leads in order to run meetings, triage issues and PRs, review and approve KEPs, plan for each release, present at KubeCon and community meetings, and write our annual report. Within the SIG we also have a number of important subprojects, each of which is stewarded by its subproject owners. For example, Marek Siarkowicz is a subproject owner of [metrics-server](https://github.com/kubernetes-sigs/metrics-server). --> **Elana (EH)**: 在 SIG Instrumentation 中，我们有两位主席：Han 和我自己，还有两位技术负责人： David Ashpole 和 Damien Grisonnet。作为 SIG 的领导者，我们一起工作，负责组织会议、分类问题和 PR、审查和批准 KEP、规划每个发布版本、在 KubeCon 和社区会议上演讲，以及撰写我们的年度报告。 在 SIG 内部，我们还有许多重要的子项目，每个子项目都有负责人来指导。例如，Marek Siarkowicz 是 [metrics-server](https://github.com/kubernetes-sigs/metrics-server) 这个子项目的负责人。 <!-- Because we’re a horizontal SIG, some of our projects have a wide scope and require coordination from a dedicated group of contributors. For example, in order to guide the Kubernetes migration to structured logging, we chartered the [Structured Logging](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md) Working Group (WG), organized by Marek and Patrick Ohly. The WG doesn’t own any code, but helps with various components such as the *kubelet*, *scheduler*, etc. in migrating their code to use structured logs. --> 由于我们是一个横向的 SIG，我们的一些项目的牵涉面很广，需要由一组专门的贡献者来协调。 例如，为了指导 Kubernetes 向结构化日志的迁移，我们成立了由 Marek 和 Patrick Ohly 组织的 [Structured Logging](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md) 工作组（Working Group，WG）。这个工作组没有自己的代码，但会帮助各个组件（如 **kubelet**、**scheduler** 等）迁移它们的代码以使用结构化日志。 <!-- **Imran (INM)**: Walking through the [charter](https://github.com/kubernetes/community/blob/master/sig-instrumentation/charter.md) alone it’s clear that SIG Instrumentation has a lot of sub-projects. Could you highlight some important ones? --> **Imran (INM)**: 从章程（[charter](https://github.com/kubernetes/community/blob/master/sig-instrumentation/charter.md)）来看， SIG Instrumentation 显然有许多子项目。你能重点说一下其中一些重要的项目吗？ <!-- **Han (HK)**: We have many different sub-projects and we are in dire need of people who can come and help shepherd them. Our most important projects in-tree (that is, within the kubernetes/kubernetes repo) are metrics, tracing, and, structured logging. Our most important projects out-of-tree are (a) KSM (kube-state-metrics) and (b) metrics-server. --> **Han (HK)**: 我们有许多不同的子项目，我们急需能够来协助推动它们的人员。我们最重要的树内（in-tree）项目（即在 kubernetes/kubernetes 代码仓库中）是 metrics、tracing 和 structured logging。 我们最重要的树外（out-of-tree）项目是：（a）KSM（kube-state-metrics）和（b）metrics-server。 <!-- **Elana (EH)**: Echoing this, we would love to bring on more maintainers for kube-state-metrics and metrics-server. Our friends at WG Structured Logging are also looking for contributors. Other subprojects include klog, prometheus-adapter, and a new subproject that we just launched for collecting high-fidelity, scalable utilization metrics called [usage-metrics-collector](https://github.com/kubernetes-sigs/usage-metrics-collector). All are seeking new contributors! --> **Elana (EH)**: 与上面所说的相呼应，我们希望为 kube-state-metrics 和 metrics-server 引入更多的维护者。我们在 Structure Logging 工作组的朋友也在寻找贡献者。其他子项目包括 klog、prometheus-Adapter， 以及我们刚刚启动的一个用于收集高保真度、可伸缩利用率指标的新子项目，称为 [usage-metrics-collector](https://github.com/kubernetes-sigs/usage-metrics-collector) ，它们都在寻找新的贡献者！ <!-- ## Current status and ongoing challenges **Imran (INM)**: For release [1.26](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.26) we can see that there are a relevant number of metrics, logs, and tracing [KEPs](https://www.k8s.dev/resources/keps/) in the pipeline. Would you like to point out important things for last release (maybe alpha & stable milestone candidates?) --> ## 现状和持续的挑战 **Imran (INM)**: 在 [1.26](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.26) 版本中，我们可以在流水线中看到有相当数量的关于 metrics、logs 和 tracing 方面的 [KEPs](https://www.k8s.dev/resources/keps/)。您可否谈谈上个版本中的重要事项 （例如 alpha 和 stable 里程碑的候选项？） <!-- **Han (HK)**: We can now generate [documentation](https://kubernetes.io/docs/reference/instrumentation/metrics/) for every single metric in the main Kubernetes code base! We have a pretty fancy static analysis pipeline that enables this functionality. We’ve also added feature metrics so that you can look at your metrics to determine which features are enabled in your cluster at a given time. Lastly, we added a component-sli endpoint, which should make it easy for people to create availability SLOs for *control-plane* components. --> **Han (HK)**: 现在我们可以为 Kubernetes 的 main 代码库中的所有监控指标生成[文档](https://kubernetes.io/docs/reference/instrumentation/metrics/)！ 我们有一个相当不错的静态分析流水线，使这一功能成为可能。 我们还添加了 feature 指标，这样你可以查看这个指标来确定在给定时间内集群中启用了哪些特性。 最后，我们添加了一个 component-sli 端点，它应该使人们为**控制平面（control-plane）** 组件制定可用性 SLOs 变得容易。 <!-- **Elana (EH)**: We’ve also been working on tracing KEPs for both the *API server* and *kubelet*, though neither graduated in 1.26. I’m also really excited about the work Han is doing with WG Reliability to extend and improve our metrics stability framework. --> **Elana (EH)**: 我们还在做关于 **API 服务器** 和 **kubelet** 的 tracing 方面的 KEPs 工作， 尽管它们都没有在 1.26 版本中毕业。我对于 Han 与可靠性工作组合作，来扩展和改进我们的指标稳定性框架的工作也感到非常兴奋。 <!-- **Imran (INM)**: What do you think are the Kubernetes-specific challenges tackled by the SIG Instrumentation? What are the future efforts to solve them? --> **Imran (INM)**: 您认为 SIG Instrumentation 所应对的 Kubernetes 特有挑战有哪些？未来打算如何来解决它们？ <!-- **Han (HK)**:  SIG instrumentation suffered a bit in the past from being a horizontal SIG. We did not have an obvious location to put our code and did not have a good mechanism to audit metrics that people would randomly add. We’ve fixed this over the years and now we have dedicated spots for our code and a reliable mechanism for auditing new metrics. We also now offer stability guarantees for metrics. We hope to have full-blown tracing up and down the kubernetes stack, and metric support via exemplars. --> **Han (HK)**: SIG Instrumentation 作为一个横向的 SIG 曾经遇到一些困难，我们没有明确的位置来存放我们的代码， 也没有一个良好的机制来审核随意添加的指标。经过多年努力我们已经解决了这个问题，现在我们有了专门的代码存放位置， 并且有可靠的机制来审核新的指标。我们现在还为指标提供稳定性保证。我们希望在 Kubernetes 堆栈上下游进行全面的跟踪， 并通过示例提供指标支持。 <!-- **Elana (EH)**: I think SIG Instrumentation is a really interesting SIG because it poses different kinds of opportunities to get involved than in other SIGs. You don’t have to be a software developer to contribute to our SIG! All of our components and subprojects are focused on better understanding Kubernetes and its performance in production, which allowed me to get involved as one of the few SIG Chairs working as an SRE at that time. I like that we provide opportunities for newcomers to contribute through using, testing, and providing feedback on our subprojects, which is a lower barrier to entry. Because many of these projects are out-of-tree, I think one of our challenges is to figure out what’s in scope for core Kubernetes SIGs instrumentation subprojects, what’s missing, and then fill in the gaps. --> **Elana (EH)**: 我认为 SIG Instrumentation 是一个非常有趣的 SIG，因为与其他 SIG 相比，它提供了不同类型的参与机会。您不必是一名软件开发人员就可以为我们的 SIG 做出贡献！ 我们的所有组件和子项目都专注于更好地了解 Kubernetes 及其在生产环境中的性能， 这也使得我当时能参与进来并成为少数几个 SRE 身份的 SIG 主席。 我喜欢我们通过使用、测试和提供反馈意见的方式来为新人提供贡献机会，这降低了加入的门槛。 由于这些项目中许多都是 out-of-tree 的，我认为我们面临的挑战之一是确定 Kubernetes 核心 SIGs Instrumentation 子项目的范围并找出缺失的部分，然后填补这些空白。 <!-- ## Community and contribution **Imran (INM)**: Kubernetes values community over products. Any recommendation for anyone looking into getting involved in SIG Instrumentation work? Where should they start (new contributor-friendly areas within SIG?) --> ## 社区和贡献 **Imran (INM)**: Kubernetes 重视社区胜过重视产品。如果有人想参与 SIG Instrumentation 的工作， 您有什么建议？他们应该从哪里开始（在 SIG 中适合新贡献者的领域？） <!-- **Han(HK) and Elana (EH)**: Come to our bi-weekly triage [meetings](https://github.com/kubernetes/community/tree/master/sig-instrumentation#meetings)! They aren’t recorded and are a great place to ask questions and learn about our ongoing work. We strive to be a friendly community and one of the easiest SIGs to get started with. You can check out our latest KubeCon NA 2022 [SIG Instrumentation Deep Dive](https://youtu.be/JIzrlWtAA8Y) to get more insight into our work. We also invite you to join our Slack channel #sig-instrumentation and feel free to reach out to any of our SIG leads or subproject owners directly. --> **Han(HK) and Elana (EH)**: 参加我们的双周分类[会议](https://github.com/kubernetes/community/tree/master/sig-instrumentation#meetings)！ 这些会议不会被录制，它们是一个很好的提问的地方并可以了解我们正在进行的工作。我们致力于打造一个友好的社区， 同时也是最容易入门的 SIG 之一。你可以查看我们最新的 KubeCon NA 2022 [SIG Instrumentation Deep Dive](https://youtu.be/JIzrlWtAA8Y)， 以更深入地了解我们的工作。我们还邀请你加入我们的 Slack 频道 #sig-instrumentation，并随时与我们的 SIG 负责人或子项目所有者直接联系。 <!-- Thank you so much for your time and insights into the workings of SIG Instrumentation! --> 非常感谢你抽出宝贵时间并深入了解了 SIG Instrumentation 的工作！ </ins>  No newline at end of file

This is a Feature Request Problem: misssing Chinese translation docs: Proposed Solution: add Chinese translation docs in website Kubernetes Blog Comments /language zh
/triage accepted
/assign
I will working on that. When I'm done the translate, will link a pull request to add the translation docs at .


Question: display: block; width: 100%; } <ins> .col-container { flex-direction: column; } </ins> } .button{

This is feedback by email from within the CNCF/Linux Foundation: add the CKA/CKAD logos from to the page.
I'll take care of this, so assign it to me :)
/assign


Question: date: 2021-04-06 slug: podsecuritypolicy-deprecation-past-present-and-future --- **Author:** Tabitha Sable (Kubernetes SIG Security) <ins> {{% pageinfo color="primary" %}} **Update:** *With the release of Kubernetes v1.25, PodSecurityPolicy has been removed.* *You can read more information about the removal of PodSecurityPolicy in the [Kubernetes 1.25 release notes](/blog/2022/08/23/kubernetes-v1-25-release/#pod-security-changes).* {{% /pageinfo %}} </ins> PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably. What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes.

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update (but check with the author, before you do) Make it obvious that your change is an update to an existing article. Hyperlink to Why is this needed PodSecurityPolicy is no longer deprecated; it is actually removed. It helps to amplify that story. Comments /area blog Follows on from
/language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Update PSP deprecation blog article to link to v1.25 release blog
/assign
Any suggestion from your end?
??
This seems like a good idea. Perhaps add something like this, up at the top of the document?


Question: 1. Get a shell into the restarted Container: <del> kubectl exec -it redis -- /bin/bash </del> <ins> kubectl exec -it redis -- /bin/bash </ins> 1. In your shell, goto `/data/redis`, and verify that `test-file` is still there.

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: This page has extra spaces before the commands: I am not sure it's a more systemic problem, but this causes commands to not to show up on the bash history (undesirable). Proposed Solution: Page to Update: /assign
A cursory look through the rest of the docs under Configure Pods and Containers showed that one out of four docs also had this issue. I'll make this change as I update the callouts.


Question: {{< feature-state for_k8s_version="v1.12" state="beta" >}} <!-- steps --> The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption. The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS

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: There are indentation errors in the yaml files of EncryptionConfiguration. For example in the following yaml, lines after "- secrets" should indent two to the right. ! Proposed Solution: Correct the indentation errors. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Is it right to have in the fixed page?
I checked the preview page, and it's still wrong. I've close my PR.
It should looks like this or "secrets" is the subcontent of the second "resources", and "providers" is with the same level of the second "resources". Although I modified the markdown, the rendered webpage is still wrong.
/priority backlog /language en /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /priority backlog /language en /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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten /assign


Question: <ins> --- title: 检查弃用 Dockershim 对你的影响 content_type: task weight: 20 --- <!-- title: Check whether Dockershim deprecation affects you content_type: task reviewers: - SergeyKanzhelev weight: 20 --> <!-- overview --> <!-- The `dockershim` component of Kubernetes allows to use Docker as a Kubernetes's {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. Kubernetes' built-in `dockershim` component was deprecated in release v1.20. --> Kubernetes 的 `dockershim` 组件使得你可以把 Docker 用作 Kubernetes 的 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。 在 Kubernetes v1.20 版本中，内建组件 `dockershim` 被弃用。 <!-- This page explains how your cluster could be using Docker as a container runtime, provides details on the role that `dockershim` plays when in use, and shows steps you can take to check whether any workloads could be affected by `dockershim` deprecation. --> 本页讲解你的集群把 Docker 用作容器运行时的运作机制， 并提供使用 `dockershim` 时，它所扮演角色的详细信息， 继而展示了一组验证步骤，可用来检查弃用 `dockershim` 对你的工作负载的影响。 <!-- ## Finding if your app has a dependencies on Docker {#find-docker-dependencies} --> ## 检查你的应用是否依赖于 Docker {#find-docker-dependencies} <!-- If you are using Docker for building your application containers, you can still run these containers on any container runtime. This use of Docker does not count as a dependency on Docker as a container runtime. --> 虽然你通过 Docker 创建了应用容器，但这些容器却可以运行于所有容器运行时。 所以这种使用 Docker 容器运行时的方式并不构成对 Docker 的依赖。 <!-- When alternative container runtime is used, executing Docker commands may either not work or yield unexpected output. This is how you can find whether you have a dependency on Docker: --> 当用了替代的容器运行时之后，Docker 命令可能不工作，甚至产生意外的输出。 这才是判定你是否依赖于 Docker 的方法。 <!-- 1. Make sure no privileged Pods execute Docker commands. 2. Check that scripts and apps running on nodes outside of Kubernetes infrastructure do not execute Docker commands. It might be: - SSH to nodes to troubleshoot; - Node startup scripts; - Monitoring and security agents installed on nodes directly. 3. Third-party tools that perform above mentioned privileged operations. See [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) for more information. 4. Make sure there is no indirect dependencies on dockershim behavior. This is an edge case and unlikely to affect your application. Some tooling may be configured to react to Docker-specific behaviors, for example, raise alert on specific metrics or search for a specific log message as part of troubleshooting instructions. If you have such tooling configured, test the behavior on test cluster before migration. --> 1. 确认没有特权 Pod 执行 docker 命令。 2. 检查 Kubernetes 基础架构外部节点上的脚本和应用，确认它们没有执行 Docker 命令。可能的命令有： - SSH 到节点排查故障； - 节点启动脚本； - 直接安装在节点上的监视和安全代理。 3. 检查执行了上述特权操作的第三方工具。详细操作请参考: [从 dockershim 迁移遥测和安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) 4. 确认没有对 dockershim 行为的间接依赖。这是一种极端情况，不太可能影响你的应用。 一些工具很可能被配置为使用了 Docker 特性，比如，基于特定指标发警报，或者在故障排查指令的一个环节中搜索特定的日志信息。 如果你有此类配置的工具，需要在迁移之前，在测试集群上完成功能验证。 <!-- ## Dependency on Docker explained {#role-of-dockershim} --> ## Docker 依赖详解 {#role-of-dockershim} <!-- A [container runtime](/docs/concepts/containers/#container-runtimes) is software that can execute the containers that make up a Kubernetes pod. Kubernetes is responsible for orchestration and scheduling of Pods; on each node, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} uses the container runtime interface as an abstraction so that you can use any compatible container runtime. --> [容器运行时](/zh/docs/concepts/containers/#container-runtimes)是一个软件，用来运行组成 Kubernetes Pod 的容器。 Kubernetes 负责编排和调度 Pod；在每一个节点上， {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 使用抽象的容器运行时接口，所以你可以任意选用兼容的容器运行时。 <!-- In its earliest releases, Kubernetes offered compatibility with just one container runtime: Docker. Later in the Kubernetes project's history, cluster operators wanted to adopt additional container runtimes. The CRI was designed to allow this kind of flexibility - and the kubelet began supporting CRI. However, because Docker existed before the CRI specification was invented, the Kubernetes project created an adapter component, `dockershim`. The dockershim adapter allows the kubelet to interact with Docker as if Docker were a CRI compatible runtime. --> 在早期版本中，Kubernetes 提供的兼容性只支持一个容器运行时：Docker。 在 Kubernetes 发展历史中，集群运营人员希望采用更多的容器运行时。 于是 CRI 被设计出来满足这类灵活性需要 - 而 kubelet 亦开始支持 CRI。 然而，因为 Docker 在 CRI 规范创建之前就已经存在，Kubernetes 就创建了一个适配器组件：`dockershim`。 dockershim 适配器允许 kubelet 与 Docker交互，就好像 Docker 是一个 CRI 兼容的运行时一样。 <!-- You can read about it in [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) blog post. --> 你可以阅读博文 [Kubernetes 容器集成功能的正式发布](/zh/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/) <!-- Dockershim vs. CRI with Containerd --> ![Dockershim 和 Containerd CRI 的实现对比图](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png) <!-- Switching to Containerd as a container runtime eliminates the middleman. All the same containers can be run by container runtimes like Containerd as before. But now, since containers schedule directly with the container runtime, they are not visible to Docker. So any Docker tooling or fancy UI you might have used before to check on these containers is no longer available. --> 切换到容器运行时 Containerd 可以消除掉中间环节。 所有以前遗留的容器可由 Containerd 这类容器运行时来运行和管理，操作体验也和以前一样。 但是现在，由于直接用容器运行时调度容器，所以它们对 Docker 来说是不可见的。 因此，你以前用来检查这些容器的 Docker 工具或漂亮的 UI 都不再可用。 <!-- You cannot get container information using `docker ps` or `docker inspect` commands. As you cannot list containers, you cannot get logs, stop containers, or execute something inside container using `docker exec`. --> 你不能再使用 `docker ps` 或 `docker inspect` 命令来获取容器信息。 由于你不能列出容器，因此你不能获取日志、停止容器，甚至不能通过 `docker exec` 在容器中执行命令。 <!-- If you're running workloads via Kubernetes, the best way to stop a container is through the Kubernetes API rather than directly through the container runtime (this advice applies for all container runtimes, not just Docker). --> {{< note >}} 如果你用 Kubernetes 运行工作负载，最好通过 Kubernetes API停止容器，而不是通过容器运行时 （此建议适用于所有容器运行时，不仅仅是针对 Docker）。 {{< /note >}} <!-- You can still pull images or build them using `docker build` command. But images built or pulled by Docker would not be visible to container runtime and Kubernetes. They needed to be pushed to some registry to allow them to be used by Kubernetes. --> 你仍然可以下载镜像，或者用 `docker build` 命令创建它们。 但用 Docker 创建、下载的镜像，对于容器运行时和 Kubernetes，均不可见。 为了在 Kubernetes 中使用，需要把镜像推送（push）到某注册中心。 </ins>

This is a Feature Request translate /docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects- into Chinese What would you like to be /zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects- /assign /language zh
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: adjust their behavior based on a ConfigMap. {{< /note >}} <ins> ## Using ConfigMaps ConfigMaps can be mounted as data volumes. ConfigMaps can also be used by other parts of the system, without being directly exposed to the Pod. For example, ConfigMaps can hold data that other parts of the system should use for configuration. ### Using ConfigMaps as files from a Pod To consume a ConfigMap in a volume in a Pod: 1. Create a config map or use an existing one. Multiple Pods can reference the same config map. 1. Modify your Pod definition to add a volume under `.spec.volumes[]`. Name the volume anything, and have a `.spec.volumes[].configmap.localObjectReference` field set to reference your ConfigMap object. 1. Add a `.spec.containers[].volumeMounts[]` to each container that needs the config map. Specify `.spec.containers[].volumeMounts[].readOnly = true` and `.spec.containers[].volumeMounts[].mountPath` to an unused directory name where you would like the config map to appear. 1. Modify your image or command line so that the program looks for files in that directory. Each key in the config map `data` map becomes the filename under `mountPath`. This is an example of a Pod that mounts a ConfigMap in a volume: ```yaml apiVersion: v1 kind: Pod metadata: name: mypod spec: containers: - name: mypod image: redis volumeMounts: - name: foo mountPath: "/etc/foo" readOnly: true volumes: - name: foo configmap: name: myconfigmap ``` Each ConfigMap you want to use needs to be referred to in `.spec.volumes`. If there are multiple containers in the Pod, then each container needs its own `volumeMounts` block, but only one `.spec.volumes` is needed per ConfigMap. #### Mounted ConfigMaps are updated automatically When a config map currently consumed in a volume is updated, projected keys are eventually updated as well. The kubelet checks whether the mounted config map is fresh on every periodic sync. However, the kubelet uses its local cache for getting the current value of the ConfigMap. The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in the [KubeletConfiguration struct](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go). A ConfigMap can be either propagated by watch (default), ttl-based, or simply redirecting all requests directly to the API server. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay, where the cache propagation delay depends on the chosen cache type (it equals to watch propagation delay, ttl of cache, or zero correspondingly). {{< feature-state for_k8s_version="v1.18" state="alpha" >}} The Kubernetes alpha feature _Immutable Secrets and ConfigMaps_ provides an option to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps (at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their data has the following advantages: - protects you from accidental (or unwanted) updates that could cause applications outages - improves performance of your cluster by significantly reducing load on kube-apiserver, by closing watches for config maps marked as immutable. To use this feature, enable the `ImmutableEmphemeralVolumes` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and set your Secret or ConfigMap `immutable` field to `true`. For example: ```yaml apiVersion: v1 kind: ConfigMap metadata: ... data: ... immutable: true ``` {{< note >}} Once a ConfigMap or Secret is marked as immutable, it is _not_ possible to revert this change nor to mutate the contents of the `data` field. You can only delete and recreate the ConfigMap. Existing Pods maintain a mount point to the deleted ConfigMap - it is recommended to recreate these pods. {{< /note >}} </ins> {{% /capture %}} {{% capture whatsnext %}}

I can't find anything that documents the ability to have configmap volumes self-updated. Secrets documents it with two sentences: "When a secret being already consumed in a volume is updated, projected keys are eventually updated as well. The update time depends on the kubelet syncing period."
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
/remove-lifecycle stale /lifecycle frozen
/language en
/sig apps
/priority backlog should have an nice high priority though


Question: /docs/setup/turnkey/aws/     /docs/setup/production-environment/turnkey/aws/   301 /docs/setup/turnkey/alibaba-cloud/     /docs/setup/production-environment/turnkey/alibaba-cloud/   301 /docs/setup/turnkey/azure/     /docs/setup/production-environment/turnkey/azure/   301 <del> /docs/setup/turnkey/clc/     /docs/setup/production-environment/turnkey/clc/   301 </del> /docs/setup/turnkey/gce/     /docs/setup/production-environment/turnkey/gce/   301 /docs/setup/turnkey/icp/     /docs/setup/production-environment/turnkey/icp/   301 /docs/setup/on-premises-vm/cloudstack/     /docs/setup/production-environment/on-premises-vm/cloudstack/   301

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is very dated; it talks about “minions” rather than nodes, which means that Kubernetes has moved on quite a lot since that page was last accurate. Proposed Solution: Either: delete the page, and justify that deletion review the page and update it to be current. Page to Update: Notes: “3rd party content in documentation” may be relevant here. /kind cleanup /language en /priority backlog
Hello I shall work on this issue and submit the PR for the same. Thanks
:ok_hand:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Still needs fixing. /remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Let's remove based on
/remove-lifecycle stale


Question: * `MinAge`: the minimum age at which the kubelet can garbage collect a container. Disable by setting to `0`. <del> * `MaxPerPodContainer`: the maximum number of dead containers each Pod pair </del> <ins> * `MaxPerPodContainer`: the maximum number of dead containers each Pod </ins> can have. Disable by setting to less than `0`. * `MaxContainers`: the maximum number of dead containers the cluster can have. Disable by setting to less than `0`.

The description of under mentions without explaining what it means: I suspect that this is a typo and should be removed.
/sig docs /language en
/kind documentation
/assign
/retitle Confusing word (pod pair) in Garbage collection page.
/triage accepted


Question: ## Writing, reading, and updating versioned CustomResourceDefinition objects <del> When an object is written, it is persisted at the version designated as the </del> <ins> When an object is written, it is stored at the version designated as the </ins> storage version at the time of the write. If the storage version changes, existing objects are never converted automatically. However, newly-created or updated objects are written at the new storage version. It is possible for an object to have been written at a version that is no longer served. <del> When you read an object, you specify the version as part of the path. If you specify a version that is different from the object's persisted version, Kubernetes returns the object to you at the version you requested, but the persisted object is neither changed on disk, nor converted in any way (other than changing the `apiVersion` string) while serving the request. </del> <ins> When you read an object, you specify the version as part of the path. </ins> You can request an object at any version that is currently served. <ins> If you specify a version that is different from the object's stored version, Kubernetes returns the object to you at the version you requested, but the stored object is not changed on disk. What happens to the object that is being returned while serving the read request depends on what is specified in the CRD's `spec.conversion`: - if the default `strategy` value `None` is specified, the only modifications to the object are changing the `apiVersion` string and perhaps [pruning unknown fields](/docs/concepts/extend-kubernetes/api-extension/custom-resources/custom-resource-definitions/#field-pruning) (depending on the configuration). Note that this is unlikely to lead to good results if the schemas differ between the storage and requested version. In particular, you should not use this strategy if the same data is represented in different fields between versions. - if [webhook conversion](#webhook-conversion) is specified, then this mechanism controls the conversion. </ins> If you update an existing object, it is rewritten at the version that is currently the storage version. This is the only way that objects can change from

This is a Bug Report Problem: One part of the "Versions in CustomResourceDefinitions" document says that conversion is performed from storage version to served version. Another says it's not (and furthermore, that k8s will lie about by setting it without actually making any attempt at schema conversion). Specifically: says: the same time says: The above sentence is not true in general. Specifically because the part: blurs the distinction between the "persisted object" (which indeed never changes on reads) and the served representation (which definitely is converted, if only to change the apiVersion string), this sentence could be read in two ways: persisted object is not changed on disk. The served representation is not converted (i.e. does not differ from the persisted object) other than the version string. This first interpretation is only correct if the schemas do not differ. A casual reader of a general document on conversion webhooks certainly dos not have this assumption, and definitely not before reading the example which follows the above sentence. persisted object is not changed on disk. The only conversion applied to persisted object is that the apiVersion string is changed. This conversion to persisted object happens when the request is being served. This second interpretation is just plain wrong. The on-disk object does not change. Period. Then later, there is an example which describes a special case of serving a representation of an object persisted at version: This sentence is correct, and in this particular context the first sentence makes more sense (but is still blurry). Proposed Solution: the first sentence to: match what happens in the general case of stored version != served version. Not just in the specific -case. make an explicit distinction between (conceptually immutable on reads) persisted object and the served representation, rather to try and describe both in one go an example for the case where conversion webhooks are actually useful (i.e. where the schema between persisted and served versions differs). This can be an additional second example, or the existing example can be replaced. [separate issue] provide an additional example of what happens when there is no conversion webhook defined and schemas differ schemas are identical (except for the version string) [separate issue] additionally, it might be good to use "stored version" consistently, rather than "persisted version". This should also probably be a different orthogonal issue.

Page to Update:
The difference is that the persisted object is not changed no matter what version of its API you use to read it. That's what the second quote is about. If you have a persisted object and try to use a different version of that API to read or modify it, then the API server must convert its representation the persisted object to the API version that the client asked for. That's might involve a webhook for a CRD, as the first quote explains. GitHub (this website) does something similar. This issue is in no matter which API you use to access it. If GitHub adds a new kind of API for accessing issues, they might choose not to replace all their stored data; instead, they keep storing the data they have and convert on-the-fly when you access it. I think the pages are accurate. It's a difficult concept to explain well and if you have suggestions for improving the explanation (without changing the technical meaning), we'd be keen to hear them. /remove-kind bug /sig api-machinery /language en PS Using “persisted” vs “stored” consistently could be a useful cleanup - perhaps for a separate issue.
BTW, the reason that the two objects in differ only by the API version is because that was the only change you made. In Kubernetes, the convention when promoting an API to stable (taking or out of the version) is that you try not to change that API when you do so).
thanks for the fast response! Thank you for clarification, what you now described matches my understanding. I think the confusing part was this: I'm guessing this is indeed the case when is . But since the preceding sections talk at length about using conversion webhooks, such statement at this point was a bit of a shock to me. :-) I re-read the second quote and now that I have your clarification I admit it makes sense, if one assumes that the schema for the two versions is the same, as you say: Indeed the example that follows ("To illustrate this ...", changing to ) provides a hint to that, to someone who knows the semantics of version strings in Kubernetes. However this is a bit implied, and I think it would be better to make it explicit - as you say - this is a difficult concept.

I think there are two ways to improve the situation: the section mostly as is, but explicitly mention that it is talking about promoting to a version without changing the schema, where conversion webhook would indeed be unnecessary. Perhaps also linking to a document which explains the versioning conventions, i.e. that changing from to should imply no schema changes, unlike -. more general, and explicitly describe what happens in the following cases: schemas differ, and there is a conversion webhook (response is converted, but stored object stays intact) schemas differ, but there is no conversion webhook (that was actually what I was looking for in this document, since this is a corner case with potential for data loss in some cases) no schema difference and no conversion webhook (just is bumped in the response, but stored object stays intact) I think the latter option would be much more informative, however I lack knowledge about what happens in the middle case. If someone could chime in with a link to the relevant place in the code, I'd be more than happy to send a doc improvement PR!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
also /wg api-expression
/remove-lifecycle rotten
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
in light of the discussion so far, would you be willing to revise the issue description to outline the defect you see or the improvement you'd like made?
finally had some time to reword the issue description. Please take a look and if this makes sense I can propose a patch and file the additional issues.
Thanks /triage accepted /priority backlog
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
When working on a PR to address this issue, I tried to find some documentation in to back the following claim: but did not find anything concrete. Do you know if this goal is actually written down somewhere, or is this tribal knowledge?

That's not a policy, it's an observation. SIG Architecture might have an opinion to add here that it's also an aim of the Kubernetes project. /sig architecture


Question: You can have multiple paragraphs and block-level elements inside an admonition. <del> | Or | a | table | </del> <ins> You can also add tables to organize and highlight key information. | Header 1 | Header 2 | Header 3 | | -------- | -------- | -------- | | Data 1   | Data A   | Info X   | | Data 2   | Data B   | Info Y   | </ins> {{< /note >}} {{< caution >}}

Problem: ! Proposed Solution: I have no idea because I have never used Hugo Page to Update:
/area web-development /triage accepted
Can I take care of it?
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
It is not clear what is the next step to take this issue to closure. I see tried a number of things in Is the issue that the table "borders" are not rendered correctly in the Note admonition? It seems Hugo is not able to render the borders of the table when it is inside a Note admonition block. In this case it should be reported as a bug to Hugo, right? In the meanwhile, I propose we remove the part of having support for a table inside a Note from the Propose to remove from the below section. !
I have raised a for support in the Hugo forums.
There is an answer on the Hugo forum stating that this is not a Hugo issue. The suggestion is to fix the CSS. Any pointers?


Question: ```powershell # Example <del> .Install-Containerd.ps1 -ContainerDVersion v1.4.1 </del> <ins> .Install-Containerd.ps1 -ContainerDVersion 1.4.1 </ins> ``` {{< /note >}}

Install containerd with powershell do not work with .Install-Containerd.ps1 -ContainerDVersion v1.4.1. The download url is ''. So ".Install-Containerd.ps1 -ContainerDVersion 1.4.1." will work the command.
I think this might be a bug in rather than in the Kubernetes documentation. If so, you could report this via
/triage accepted /assign /sig windows
See


Question: Hopefully I can do some more posts about advanced Kubernetes topics such as changing the cluster size and number of Node.js web server replicas, using different environments (dev, staging, prod) on the same cluster, and doing rolling updates. Thanks to [Mark Mandel](https://medium.com/@markmandel), [Aja Hammerly](https://medium.com/@thagomizer), and [Jack Wilber](https://medium.com/@jack.g.wilber). [Some rights reserved](http://creativecommons.org/licenses/by/4.0/) by the author.

NodeJS 0.10 is going into security-only release mode very soon. The first version of 0.10 was released in March 2013, so it's over 3 years old. It would be great if we could update the tutorial/dockerfile to list the latest (or at least a newer) nodejs version.
Resolved by, thanks to


Question: <ins> --- title: Controladores Ingress description: >- Para que un [Ingress](/docs/concepts/services-networking/ingress/) funcione en tu clúster, debe haber un _ingress controller_ en ejecución. Debes seleccionar al menos un controlador Ingress y asegurarte de que está configurado en tu clúster. En esta página se enumeran los controladores Ingress más comunes que se pueden implementar. content_type: concept weight: 50 --- <!-- overview --> Para que el recurso Ingress funcione, el clúster necesita tener un controlador Ingress corriendo. Mientras otro tipo de controladores que corren como parte del binario de `kube-controller-manager`, los controladores Ingress no son automaticamente iniciados dentro del clúster. Usa esta página para elegir la mejor implementación de controlador Ingress que funcione mejor para tu clúster. Kubernetes es un proyecto que soporta y mantiene los controladores Ingress de [AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme), [GCE](https://git.k8s.io/ingress-gce/README.md#readme) y [nginx](https://git.k8s.io/ingress-nginx/README.md#readme). <!-- body --> ## Controladores adicionales {{% thirdparty-content %}} * [AKS Application Gateway Ingress Controller](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json) es un controlador Ingress que controla la configuración de [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview). * [Alibaba Cloud MSE Ingress](https://www.alibabacloud.com/help/en/mse/user-guide/overview-of-mse-ingress-gateways) es un controlador Ingress que controla la configuración de [Alibaba Cloud Native Gateway](https://www.alibabacloud.com/help/en/mse/product-overview/cloud-native-gateway-overview?spm=a2c63.p38356.0.0.20563003HJK9is), el cual es una versión comercial de [Higress](https://github.com/alibaba/higress). * [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) es un [Apache APISIX](https://github.com/apache/apisix)-basado en un controlador Ingress. * [Avi Kubernetes Operator](https://github.com/vmware/load-balancer-and-ingress-services-for-kubernetes) provee un balanceador de cargas L4-L7 usando [VMware NSX Advanced Load Balancer](https://avinetworks.com/). * [BFE Ingress Controller](https://github.com/bfenetworks/ingress-bfe) es un controlador Ingress basado en [BFE](https://www.bfe-networks.net). * [Cilium Ingress Controller](https://docs.cilium.io/en/stable/network/servicemesh/ingress/) es un controlador Ingress potenciado por [Cilium](https://cilium.io/). * El [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme) funciona con Citrix Application Delivery Controller. * [Contour](https://projectcontour.io/) es un controlador Ingress basado en [Envoy](https://www.envoyproxy.io/). * [Emissary-Ingress](https://www.getambassador.io/products/api-gateway) es un API Gateway [Envoy](https://www.envoyproxy.io)-basado en el controlador Ingress. * [EnRoute](https://getenroute.io/) es un API Gateway basado en [Envoy](https://www.envoyproxy.io) que puede correr como un controlador Ingress. * [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/reference/ingresscontroller.md) es una API Gateway basada en [Easegress](https://megaease.com/easegress/) que puede correr como un controlador Ingress. * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/) te permite usar un Ingress para configurar los servidores virtuales de F5 BIG-IP. * [FortiADC Ingress Controller](https://docs.fortinet.com/document/fortiadc/7.0.0/fortiadc-ingress-controller/742835/fortiadc-ingress-controller-overview) soporta el recurso de Kubernetes Ingress y te permite manejar los objectos FortiADC desde Kubernetes. * [Gloo](https://gloo.solo.io) es un controlador Ingress de código abierto basado en [Envoy](https://www.envoyproxy.io), el cual ofrece la funcionalidad de API gateway. * [HAProxy Ingress](https://haproxy-ingress.github.io/) es un controlador Ingress para [HAProxy](https://www.haproxy.org/#desc). * [Higress](https://github.com/alibaba/higress) es una API Gateway basada en [Envoy](https://www.envoyproxy.io) que puede funcionar como un controlador Ingress. * El [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress#readme) es también un controlador Ingress para [HAProxy](https://www.haproxy.org/#desc). * [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/) es un controlador Ingress basado en [Istio](https://istio.io/). * El [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme) es un controlador Ingress que controla [Kong Gateway](https://konghq.com/kong/). * [Kusk Gateway](https://kusk.kubeshop.io/) es un controlador Ingress OpenAPI-driven basado en [Envoy](https://www.envoyproxy.io). * El [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx-ingress-controller/) trabaja con el servidor web (como un proxy) [NGINX](https://www.nginx.com/resources/glossary/nginx/). * El [ngrok Kubernetes Ingress Controller](https://github.com/ngrok/kubernetes-ingress-controller) es un controlador de código abierto para añadir acceso público seguro a sus servicios K8s utilizando la [plataforma ngrok](https://ngrok.com). * El [OCI Native Ingress Controller](https://github.com/oracle/oci-native-ingress-controller#readme) es un controlador Ingress para Oracle Cloud Infrastructure el cual te permite manejar el [balanceador de cargas OCI](https://docs.oracle.com/en-us/iaas/Content/Balance/home.htm). * El [Pomerium Ingress Controller](https://www.pomerium.com/docs/k8s/ingress.html) esta basado en [Pomerium](https://pomerium.com/), que ofrece una política de acceso sensible al contexto. * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) es un enrutador HTTP y proxy inverso para la composición de servicios, incluyendo casos de uso como Kubernetes Ingress, diseñado como una biblioteca para construir su proxy personalizado. * El [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/) es un controlador Ingress para el [Traefik](https://traefik.io/traefik/) proxy. * El [Tyk Operator](https://github.com/TykTechnologies/tyk-operator) amplía Ingress con recursos personalizados para aportar capacidades de gestión de API a Ingress. Tyk Operator funciona con el plano de control de código abierto Tyk Gateway y Tyk Cloud. * [Voyager](https://voyagermesh.com) es un controlador Ingress para [HAProxy](https://www.haproxy.org/#desc). * [Wallarm Ingress Controller](https://www.wallarm.com/solutions/waf-for-kubernetes) es un controlador Ingress que proporciona capacidades de seguridad WAAP (WAF) y API. ## Uso de varios controladores Ingress Puedes desplegar cualquier número de controladores Ingress utilizando [clase ingress](/docs/concepts/services-networking/ingress/#ingress-class) dentro de un clúster. Ten en cuenta el `.metadata.name` de tu recurso de clase Ingress. Cuando creas un Ingress, necesitarás ese nombre para especificar el campo `ingressClassName` de su objeto Ingress (consulta [referencia IngressSpec v1](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)). `ingressClassName` sustituye el antiguo [método de anotación](/docs/concepts/services-networking/ingress/#deprecated-annotation). Si no especificas una IngressClass para un Ingress, y tu clúster tiene exactamente una IngressClass marcada como predeterminada, Kubernetes [aplica](/docs/concepts/services-networking/ingress/#default-ingress-class) la IngressClass predeterminada del clúster al Ingress. Se marca una IngressClass como predeterminada estableciendo la [anotación `ingressclass.kubernetes.io/is-default-class`](/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) en esa IngressClass, con el valor de cadena `"true"`. Lo ideal sería que todos los controladores Ingress cumplieran esta especificación, pero los distintos controladores Ingress funcionan de forma ligeramente diferente. {{< note >}} Asegúrate de revisar la documentación de tu controlador Ingress para entender las advertencias de tu elección. {{< /note >}} ## {{% heading "whatsnext" %}} * Más información [Ingress](/docs/concepts/services-networking/ingress/). * [Configurar Ingress en Minikube con el controlador NGINX](/docs/tasks/access-application-cluster/ingress-minikube). </ins>

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


Question: Deployment 是管理 Pod 创建和扩展的推荐方法。 <!-- <del> 1. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then click open a new terminal. </del> <ins> 1. Katacoda environment only: At the top of the terminal pane, click the plus sign, and then **Open New Terminal**. </ins> --> <del> 1. 仅 Katacoda 环境：在终端窗格的顶部，点击加号，然后点击 **Open a new terminal**。 </del> <ins> 1. 仅 Katacoda 环境：在终端窗格的顶部，点击加号，然后点击 **Open New Terminal**。 </ins> <!-- 1. Use the `kubectl create` command to create a Deployment that manages a Pod. The

Numbers in the following list may be not up to date. Please run again before working on each of them.
/language zh /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 : /language zh /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
/assign


Question: The responsibilities of each role are described below. - [Contact](#contact) <ins> - [Security Embargo Policy](#security-embargo-policy) </ins> - [Handbooks](#handbooks) - [Release Managers](#release-managers) - [Becoming a Release Manager](#becoming-a-release-manager)

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 Mention the within , or link to it. Why is this needed Readers might have an interest in knowing how security fixes are planned and communicated. Comments /sig release /sig security /language en /kind feature
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign I can work on this.
Hi Please suggest which option from the following I will go with In this, we will have to make a page for embargo policy(security-embargo-) as we do not mention the link directly. 1) Copy the whole content from the to security-embargo- which seems redudant as it already mention in kubernete/security. 2) Mention the below text and then the link to for more details like:
I can clarify: this issue is about explaining that some information about upcoming releases is subject to embago, and that there is a defined policy about how those embargos are set. I don't see a need to mention how to join the mailing list for distributors within If someone is maintaining a Kubernetes distribution, I hope they're able to follow hyperlinks well enough to work that out. We have readers who might not think to look there. That's why we should refer to it (a hyperlink could be OK).
Thanks for suggestion. will create a pr for it soon.
fixed it here:


Question:
 Buy your ticket now! 21 - 23 August | Hong Kong   - name: KubeCon 2024 NA startTime: 2024-09-30T00:00:00  #Added in https://github.com/kubernetes/website/pull/48086 endTime: 2024-11-15T18:00:00 style: >- background: linear-gradient(90deg, rgba(64,66,169,1) 60%, rgba(0,81,181,1) 100%); color: #fffff; title: |  KubeCon + CloudNativeCon 2024 message: | Join us for three days of incredible opportunities to collaborate, learn and share with the cloud native community.
  Buy your ticket now! 12 - 15 November | Salt Lake City

This is a Feature Request What would you like to be Set a banner to announce KubeCon 2024 NA Why is this needed We usually turn on a banner for the upcoming KubeCon about 4 weeks ahead of the event. Logos are available from: (Note: be sure to copy the logo into this repo) should help with text. Also see the config from a last year's KubeCon. Comments This change will need approval. I would like to set the banner to start on the ~Oct 14, 2024~ Sep 30 and to end on Nov 15, 2024 at 1800 CET (UTC+1). edit: We've been asked if we can do a 6 week banner rather than a 4 week run. /priority important-soon
/triage accepted
/assign
/assign


Question: cgroupDriver: <value> ``` <ins> For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). </ins> Please mind, that you **only** have to do that if the cgroup driver of your CRI is not `cgroupfs`, because that is the default value in the kubelet already.

This is a Feature Request The says as follows When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet and set it in the file during runtime. If you are using a different CRI, you have to modify the file with your value, like so: This sounds like saving the yaml file in IS used in but it actually isn't. You need to specify the --config option when running Ref. What would you like to be Add kubeadm config and pass it to command. Example: Why is this needed To avoid confusion Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
the command reference page has this block: it links to: on the godoc page there is an example like so:
with the above documentation links / examples i have not seen any recent reports of users being confused. /priority awaiting-more-evidence /sig cluster-lifecycle
I get your point but this page should be one-stop place where you can find all the basic information enough to create a single cluster with the given condition; this case it mentions about when using different container runtime, so it should be more clear about that. My point is that even adding reference link to the config option would be better. What do you think?
proposing a minor change to the above: please send a PR for this if you can.
Created it!
Hi , on above - ok there is at least one user of that kind now, myself. See my confusion here: I was totally sure that for just adding systemd as cgroup driver (and nothing more different to the default ), tells me to print the default config into a file, add the three lines there required for , and supply it to kubeadm. As you can imagine, I was quite puzzled by the result... Fortunately, I found this page, and realised what a silly sausage I was. The initial suggestion by , with his config snippet, really helped (thanks!!) - that was exactly what I needed. Since the recommended runtime now is , and most recommended way is to use as a cgroup driver for kubelet, I think his suggestion is very right and this snippet should be mentioned right at the page that tells about how to install , and its footnote telling about . Honestly, it's really confusing without it.

hi, we have a new WIP page that will be dedicated to cgroup drivers entirely:
Agreed: I have been confused also for the last couple of hours, and searching finally led to this issue.
Issue like this should not be closed. /reopen
Reopened this issue. <detailsIn response to : Issue like this should not be closed. /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
When talking about the config-file for , we should explain this more generally - not specific to the cgroup-driver. In my case, I need to set the parameter. For about 8 hours I searched for a way to do that with . Now I found So I can implicate that this is a gerenal solution. However, the docs should mention this explicitly.
This is also very confusing for me. I could not find how to use the kubelet-configuration with kubeadm in this docs. seems to help in this case.
did you see this section for kubeadm init? both the kubeadm init and join documentation pages link to the kubeadm API from where you can pick e.g. v1beta2 and it has examples how to pass KubeletConfiguration to kubeadm init: from there users need to understand what fields the KubeletConfiguration has. the KubeletConfiguration is not managed by the kubeadm team - it's located here:
and to respond to the original issue (again) here the "installing kubeadm" guide now also has: most users understand what they need to do after clicking that link, but some would still get confused. due to the cgroup driver configuration issue this PR: adds new page explicitly for cgroup divers and after that this issue feels resolved to me. unless users have more specific requests on how to organize the docs?

yes, but that site does not tell anything about the syntax and structure for that config file. For me as an system engineer I am not able to create a config file with the information included on that site. I must admit that I have never scrolled to the end of that page. For me, it was not transparent that I have to use "Directories" to get the link to v1beta2, which will finally lead me to the information I wanted. That's why I asked for the link to itself. the KubeletConfiguration is not managed by the kubeadm team - it's located here: Here is no link to "Directories". Where do I find the syntax for the KubeletConfiguration within the yaml-config-file? I was confused because that link does not explain how to use the KubeletConfiguration with ... This was my suggestion: . Another solution would be here: Maybe someone else can check what will be helpful here. EDIT: Could we also have the 3 or 4 steps to create a configuration file instead of linking to the command, which is in fact , pipe them to a file and then run with ?
For me as an system engineer I am not able to create a config file with the information included on that site. it's an API presented to the user in a standard godoc format. structure fields map to JSON / YAML, e.g.: i'm surprised that you as a system engineer are having trouble parsing this aspect. what is the exact change you would like to see? that's actually a bug. prior to the new godoc we design it was possible to HTML anchor link to the subdirectories. i've just logged this issue it's not a directory because the KubeletConfiguration is not a kubeadm structure, it's a kubelet structure. kubeadm just allows you pass it to the kubelet, because kubeadm manages a kubelet. the kubeadm v1beta2 page links to the KubeletConfiguration, did you see this? here currently users must navigate to or directly. a number of kubeadm pages link to that already. this is a bit vague to me, still. this change seems fine to me, but i cannot approve it since it's for the kubelet pages. sure, we can keep this issue open until that happens.

one problem that i have with similar requests is that users want a change, but they are not exactly sure what they want to be changed. the feedback is vague. its not "config view", but rather "config print init-defaults". including a placeholder stub seems OK to me in the lines of: but nothing more, just the link to which is already there. PRs welcome.
First, thank you for taking so much time and your questions to understand that! I also want to help with my point of view so I hope this will be transparent. First, I want to answer your points. Then, in my next comment, I'd like to describe my "jouney" through the docs on the wrong tracks... itself. I've just commented it... Ok, thanks. You see, this is the "inner" way to see it. For administrating it, it is not that easy to see why it's so complicated to find those simple things (see also my next comment) To be honest: No. But after so many hours lost in space, I did not take the time to have a look at that in detail. So this definitely was my fault. Sorry. I already knew that I have to use the config file instead of the command-line-tools. So I know this page, but do not read it for my actual problem. (see next comment: lost in space) This did not seem to be a syntax for me which can be used for my kubelet configuration. Yes, this is perfect! This is what I was looking for for 2 days :) This seems to be the biggest barrier here. Do you find one of them when searching for kubelet config :) ? I will add a new comment or maybe another issue to discuss that. Thanks. I see. Ok, I will try to help more precisely. The thing for me is to understand the way it works without having the docs I would have needed - and the give the feedback what would have been helpful. I would never have the idea that I have to do that to create the config I need to change, when I have to change the kubelet-config. Yes, this exactly should be explained on a page like and broken ;) Will you make one to fix the link to ? If not, I can do that.

For me as an system engineer I am not able to create a config file with the information included on that site. This refered to , not to the API documentation. what is the exact change you would like to see? I'll try to show you my confusing way through the docs. I hope we see wenn I got lost :) have 3 small clusters running created with kubeadm. For the provisioning I use . I know that we have to switch to a kubelet-config-file instead of the command line because of deprecation for most arguments. I am starting with zero knowledge about this config-file. am starting with . I have no idea that what I have to do has anything to do with kubadm. I read the example for the config file and know that I have to start kubelet with and this file. EDIT: Fixed with This is the first time I get lost - where I created this issue: . So you see I was on the very wrong way. confusing thing is here: For now I am still using docker, so I have no idea that this is also the solution for my case. BUT: editing is not a good idea... . I know that this is NOT the solution. Lost in space... to EDIT: hopefully better with This really does NOT sound that it could be the solution for my problem. However, if I had a full example of the config file meant here, I would have seen that it also had a -part. So I had no idea why I should print my kubeadm config and migrate it ... The link with the list is broken, we talked about that... I am still lost ... EDIT: fixed the web again I finally find and the link to this issue.... and get the idea that this could be a way for me, although changing the cgroup-Driver is not my problem... (Thanks to your comments there! and the PR of I am :)
no problem, but i don't have much time to debate this close to a kubernetes release (1.21). your feedback seems like a story in the lines of "hey, i saw a bunch of problems in your docs". if you have any suggestions just log separate issues / send PRs. EOD, every single change gets approved by the kubernetes/website maintainers and not by component maintainers like me.

you can update the link in k/website. i will try to fix the general problem at
Oh, I thought you were a docs maintainer. Thanks for your help. still.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/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: Setup | [All heading and subheading URLs](/docs/setup/) Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file <ins> Releases | [All heading and subheading URLs](/releases) </ins> Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:

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 I propose that should include Why is this needed The releases page (just the front page, and not requiring any pages within it) is a key document to make available to readers. The shortcode this page uses already has localization support. I think we should localize this page. Comments If we accept this issue, we should also open one issue per downstream localization, about making sure that that localization team works on and localizes for their target localization. Link each of those issues back to this one, which then becomes an umbrella issue.
PS. The localization is on this one, and shows an example of what success looks like. There's one paragraph in the shortcode that doesn't yet localize; if you look at the rendered page you'll see that it's marked as English. Fixing that would be a separate issue.
/triage accepted
/language en /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 : /language en /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
Hi if the issue is still open, can I work on it?
/assign Sure
do you have any questions about how to get started? You're very welcome to open a pull request.
Hey I made the PR, if you can review it that would be great!


Question: The output displays that the Deployment was created: ``` <del> NAME         READY   UP-TO-DATE   AVAILABLE   AGE redis-master 1/1     1            1           55s </del> <ins> NAME    READY   UP-TO-DATE   AVAILABLE   AGE mongo   1/1     1            1           2m21s </ins> ``` The Deployment automatically manages a ReplicaSet.

uses manifests However, these files were removed in . The new example is using mongodb instead of redis, and so, the document needs to be updated overall. The page to update:
/language en
/kind bug /language en /priority backlog /triage accepted /help Thanks
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /kind bug /language en /priority backlog /triage accepted </details
/assign

On Forward a local port to a port on the Pod section this should be
/triage needs-information
Could you please link the page
This page
/triage accepted /kind bug /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /kind bug /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
/remove-triage needs-information
/assign


Question: Annotations:         <none> Selector:            run=my-nginx Type:                ClusterIP <ins> IP Family Policy:    SingleStack IP Families:         IPv4 </ins> IP:                  10.0.162.149 <ins> IPs:                 10.0.162.149 </ins> Port:                <unset> 80/TCP <ins> TargetPort:          80/TCP </ins> Endpoints:           10.244.2.5:80,10.244.3.4:80 Session Affinity:    None Events:              <none>

Would be good to include the new fields in the output such as ,, and . These are related to dual stack deployments but since the same IPv4 address appear twice in a single stack output I think it is worth updating the sample outputs.
/retitle Stale output in Connecting Applications with Services URL of tutorial is ( it's definitely helpful if you include that detail) /language en /kind bug
/triage accepted
/sig network
/assign
I will update output with latest one


Question: <ins> apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: container-test image: busybox volumeMounts: - name: all-in-one mountPath: "/projected-volume" readOnly: true volumes: - name: all-in-one projected: sources: - secret: name: mysecret items: - key: username path: my-group/my-username - downwardAPI: items: - path: "labels" fieldRef: fieldPath: metadata.labels - path: "cpu_limit" resourceFieldRef: containerName: container-test resource: limits.cpu - configMap: name: myconfigmap items: - key: config path: my-group/my-config </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 This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted


Question: - title: Other Resources section: <del> - title: Known Issues path: /docs/user-guide/known-issues/ </del> - title: Kubernetes Issue Tracker on GitHub path: https://github.com/kubernetes/kubernetes/issues/ - title: Report a Security Vulnerability

This page is woefully out of date: docs/user-guide/known-issues/ We should move the content to the 1.0 release notes and delete the page. cc
already contains this info. I'll delete the file.
cc I can't see how to delete a file using this new edit-in-place interface. Maybe it's a permission issue?
These items are all in flight - But I have no power to assign or merge anything.
Nice work, David. :)


Question: * Read the [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API reference * Read the [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API reference * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS <del> * Read more about the [kube-scheduler Policy reference (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) </del> <ins> * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) </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: The scheduler policy API was completely removed in 1.23. Proposed Solution: Revise concepts/configuration/manage-resources- to remove references to the scheduler policy API; Revise or even remove which is meaningless; Remove the kube-scheduler-policy- file from config API. Page to Update: See above. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Related:
/sig scheduling /language en
/triage accepted


Question: } } <ins> .td-search { header > .header-filler { height: $hero-padding-top; background-color: black; } } </ins> // Docs specific #editPageButton {

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: Navbar prevents search input field from being clicked on Can reproduce on Firefox, Chrome on latest builds Proposed Solution: Remove navbar from search page Page to Update: !
is not supposed to look like that screenshot /kind bug /priority critical-urgent /area web-development Thanks for reporting this.
/triage accepted
/retitle Navbar prevents search inputfield from being clicked
Actually /retitle Search page rendering incorrectly


Question: apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts. * For example, with a Deployment that was created: Get the Deployment details: ```shell kubectl get deploy

suggests: Do changes, then The output is equivalent to the previous run of . I do not see, how this output can confirm, that the Deployment was updated.
Welcome and thanks for contributing your first issue here! This sentence does seem confusing to me. I will improve it. /triage accepted /kind bug /assign
/sig apps
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]: