I have noticed that the blog meta links (e.g. the twitter link) on sidebar of blog pages are opening in the same tab, while on other sections of the website, they are opening in a new tab. What I would like to be updated- I would like to change the target attribute of the links in the blog section to "_blank" to make them open in a new tab when clicked. This helps improve the user experience by keeping the user on the current page while still allowing them to access the linked content. Impacted page Thanks!
I'm not sure opening each and every blog in a new tab or window is the right choice for everyone.
hi, it is only opening the sidebar links.
/triage accepted
/area web-development


This page is outdated according to the comment of this ticket, because if you follow the instructions, you always get an error like the one below in any worker node when you execute: where is:{ "metadata": { "name": "nginx-sandbox", "namespace": "default", "attempt": 1, "uid": "hdishd83djaidwnduwk28bcsb" }, "linux": { } } E0107 22:25:16. ] "RunPodSandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found" FATA[0000] run pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "888e1ca106ad4e8439154c056cbf6d926b1417c43aba37f8a5052a916e5f8516": plugin type="calico" failed (add): pods "nginx-sandbox" not found` and seemingly it is due to "calico daemonset watch apiserver to get a list of pods, and apply network configuration based on the pod spec." So, the page may be deleted or the list of sections below removed:
Page reported in issue: /language en
/retitle “Debugging Kubernetes nodes with crictl” is outdated
/sig node
/triage accepted
Funny, one of the reviewers of the doc, is the same person, that posted the note in the containerd issue, In fact, we don't recommend user to run and on a Kubernetes node , those commands are there just for some special debug case.
As per my investigation, all example commands work fine in the except for the mentioned sections. As per the referenced issue, I think it should be safe to delete the specific sections instead of a whole page. The documentation also has a warning message under section which refers to the sections that need to be deleted. So, if these sections are to be deleted then the warning message should be deleted as well.
still has the same example as included in . So it can very well be a bug.


/cc Would it be okay to delete these sections in the documentation? If so I would like to raise a PR for the same.
thank you! Please propose a PR with the changes. We may also link to the official docs.
/assign


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I have a node in Minikube that's labelled with the key . This looks intended, but doesn't document that label. Proposed Solution: Document that label; as a side effect, this registers it. I can guess what this label does but I don't actually know. If you pick this issue up, part of your task is to find out that detail. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en /priority backlog PS. If this label isn't supposed to be used any more, we should also mark it as deprecated.
/triage accepted
/assign


The script actually defaults to k8s version 1.1.8, but the docs says it is 1.1.4
Thank you for the PR, Mike!


<!-- 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: In the 4th paragraph in the "What is a Pod?" section, there is a sentence: "Containers in different pods have distinct IP addresses and can not communicate by IPC." The paragraph seems to imply that different pods communicate via IP. But it is not clarified. Proposed Solution: Please clarify how different pods communicate since they cannot use IPC. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign


This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The version of the crictl in "install kubeadm" doc when installing without package managers is v1.17.0. It should be v1.22.0. Why is this needed I think it should be updated because newer versions are available unless there are compatibility issues with Kubelet. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --This is where problem exists:
/sig cluster-lifecycle /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 : /sig cluster-lifecycle /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
Hello, I would want to work on this issue as my 1st PR . Can you please assign this to me :)
Hi I think you can start working on it and submit a pull request. I do not know how to assign it to you.
/assign
Thanks. Just to confirm I have to change the crictl version to v1.22.0.
I'not sure. Maybe kubelet is not compatible with crictl v1.22.0 or there was another reason.
this matrix might be out of date, but according to it =1.16 critools are compatible with =1.16 kubernetes:
i'd say just send the PR to update and if something breaks for someone users will report it. (our current e2e tests are not using the latest 1.22 critools release...)
Okay sure. Thanks I will send the PR


Using a desktop or laptop PC and Brave: Many (all?) pages on waste a lot of screen space esp on the right edge. The pre-formatted text blocks on these pages are cut off, while there is plenty of unused screen space next to it (if you scroll down a bit). Sample: <img width="1519" alt="Screenshot 2021-10-15 at 05 52 52" src="https://user-"Of course you can scroll these text blocks horizontally, but esp on large pages with many code blocks this is distracting. I would like to read the text without scrolling horizontally. Obviously a lot of screen space is used for the menu on the right edge, even though it is not visible most of the time. Do you think this menu could be put somewhere else, e.g. on top of the page, below the index on the left side or to some kind of popup?
Thanks We use We'd definitely consider a different layout. I think for us to triage this, we'd want to see a sketch (wireframe? mock up?) of how the site would work differently. Perhaps a button to collapse / uncollapse the right-hand sidebar? Another thing we could do, because the cheat sheet is one of the most popular pages, is change how we render that one page. We definitely have the technical means for this. I'd want to be convinced that the change we'd make wouldn't adversely affect someone else's user experience. /language en /priority awaiting-more-evidence
/area web-development
Maybe this change would be enough (edit ): If someone wants to try that, go ahead. /triage accepted /priority backlog /remove-priority awaiting-more-evidence /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 : Maybe this change would be enough (edit ): If someone wants to try that, go ahead. /triage accepted /priority backlog /remove-priority awaiting-more-evidence /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
It feels a bit weird since the solution was already provided above, after adding the CSS from above it looks like this, should I go ahead and open a pull request for this. !
Happy to have someone work on this. Please go ahead! /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? 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 : Happy to have someone work on this. Please go ahead! 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 afro-coder was looking for issues with no assignee and this on propped up therefore the assignee :)


<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [ X] Bug Report Problem: SSH Tunneling link is broken Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--


This is a Bug Report Problem: page contains the following broken links: If we go through the Running ZooKeeper, A Distributed System Coordinator Introduction. If we go to click PersistentVolumes it should redirect us to PersistentVolumes Page but it shows us Volumes Page which we have to rectify here! ! Proposed Solution: Fix the broken links by Updating it to: Page to Update:
/sig docs /language en /assign
hey Can you look into this issue!!!!
/retitle Incorrect link redirection on "Running ZooKeeper" tutorial for "PersistentVolumes" /kind bug
/priority backlog (or lower) /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 : /priority backlog (or lower) /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
/retitle Incorrect link redirection in "Running ZooKeeper" tutorial page for "PersistentVolumes"
Thanks
But I have to work on this issue!!! I have self-assigned this issue to myself, Why someone else has raised a PR For this ??????


This is a Bug Report Problem: The of PodSecurityAdmission is mentioned under . Which is wrong, the correct one is . Proposed Solution: Change the from to . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /assign
Fixed it here:
/triage accepted


This seems to be a typo, shouldn't it be traffic-distribution and not trafic-distribution ?
/triage accepted /good-first-issue Yep, looks like that was a typo in the recent updates.
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/retitle Typo in "Service" concept page /kind bug


<!-- 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 [ ] Bug Report [x] Documentation request Problem: Can we use equality-based requirement selectors like this in yaml/json files: Proposed Solution: Clearly mention if this is possible and if so include a small example. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /assign


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: When somebody configures shell completion for , the instructions explain how to turn that on for your current session. However, that advice only works if the reader picked the approach in the “User” tab. If someone picked the “System” tab, the advice does not help them update their current session. Proposed Solution: Change that page to advise the user to run Some other change that also helps the user, regardless of which approach they took. Page to Update: Additional Information: Prompted by /language en /priority backlog
/triage accepted
/assign


This is a Feature Request Since v1.16, extensions/v1beta1 has been deleted and it should not be used in docs What would you like to be The following pages should be edited due to this deletion. [ ] [ ] [x] [ ] [ ] [ ] [ ] [ ] [x] [x] Why is this needed extensions/v1beta1 is deleted in 1.16 Comments
/kind cleanup /priority important-soon (I think)
If you are looking at this as potentially something to contribute to, it's OK to suggest a PR that fixes only one page, or only some pages. If you do that please mention “Partial fix for issue ” in the description of your PR.
thanks for contribution here. Could you please share which pages would you take? Let us make the assignment more clear and help other contributors easily start their work.
Thank you for your comments. I wrote the target file into PR titles. And I will write to the comment about netlify demo pages and original pages to enable checking the diff easily.


"The works with the NGINX webserver (as a proxy)." The URL given against the text "NGINX Ingress Controller for Kubernetes" is not working. It returned 404 error(Page not found) in my case.
/triage accepted /kind cleanup


This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be The documentation for container runtimes at: needs to have a clear warning that by adding the suggested change in , this will actually PREVENT from successfully initializing a cluster (this is my experience multiple times with K8s 1.20.4 on Ubuntu 20.04 with containerd - not Docker). Why is this needed The current wording does not indicate that the suggested change for containerd's will actually break things. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --It is not clear even why that suggestion is there given that it stops from working.
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
The current text reads: How would you reword this How about: When using kubeadm, you must manually configure the cgroup driver for kubelet. /language en /priority awaiting-more-evidence /sig cluster-lifecycle
Thank you for all the work that you do, related to Kubernetes and all other open source projects you contribute to. Your efforts are really appreciated. My own experience is that the configuration snippet there is actually harmful in the scope of using kubeadm. I realize now that the page is discussing how to use containerd with the systemd cgroup driver in general... but the typical person coming to the "" documentation is there to learn how to use containerd in the context of kubernetes. That makes that configuration snippet a bit out of place since it will actually prevent the usage of kubeadm. For this reason, I believe it is better to be crystal clear and explicitly mention all of that. "To use the systemd cgroup driver... [plugins... ... SystemdCgroup = true However, when using kubeadm to initialize the cluster, the above configuration should NOT be done (it will actually prevent kubelet from bringing up static pods).


Instead, manually configure the cgroup driver for kubelet."
i don't see anything invalid on the page, but ideas for clarification are welcome. When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager ... ^ the above already explains when the systemd driver is needed. it is the opposite. if you are using kubeadm, you must configure containerd with . and then pass the same driver to the kubelet as explained here: cgroup drivers have been confusing users for a long time and this is really a problem in the CRI spec. there is a plan to automatically handle them but this might take a while to complete.
this area of the docs is seeing some refactor, so you can add comments here too:
This is the source of our difference:. I have tried that setting multiple times (at least 4 times). It does NOT work for me on Ubuntu 20.04. When I do NOT specify that setting in containerd's , then and ONLY THEN does it work... for me.
i just tried following our documentation for installing containerd / installing kubeadm / creating kubeadm cluster. everything works fine for me: also a number of different CI setups are running kubeadm like so, you must be failing something in your setup. i doubt this is a containerd / OS bug of sorts, but it could be. /kind support
did you restart containerd after you : the step here should be after the driver is changed, so that's a documentation problem:
opened PR for this: (it also closes this issue)


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: Links to some ephemeral volume types are wrong. Proposed Solution: In , update links as follows: → → Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
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


Since is a page better suited for those learning Kubernetes, the , and forced storage detach on timeout section is better suited to be on the See comment thread:
/language en /sig docs
do you feel like there is any restructuring of content that needs to happen with this move? Or is it a request to straight move those sections from one page to another?
/triage accepted I think a straightforward move is the right change to prioritize. Extra help is welcome but not at the expense of delivering the fix later.
/priority important-longterm see
/assign
see if this PR does what you're looking for. Thanks


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


The existing documentation for Topology Aware Routing says however, this was before refactored and fixed the kube-proxy traffic policy problems caused by the lack of definitions on the Service traffic types This caused issues like fixed with , because we have mixed mode, If I understand correctly, right now and are not exclusive, since the former applies the traffic that is originated from "outside the cluster" and the later only applies to the traffic originated within the cluster. If that is correct , we should modify the documentation to say "Topology Aware Hints are not used when internalTrafficPolicy is set to Local on a Service. It is possible to use both features in the same cluster on different Services, just not on the same Service."
/assign /sig network
/retitle Stale docs for topology aware routing constraints
/language en
Thanks for catching this Agree with your proposed fix.
/triage accepted /kind bug
/assign


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 to Korean Page: Why is this needed Not translated yet Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ko /assign
/triage accepted


This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/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


This paragraph is a bit backwards. It would be more intuitive to start with the "Make sure that the br_netfilter module is loaded before this step..." phrases.
/language en /kind cleanup /priority backlog /good-first-issue Thanks
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /language en /kind cleanup /priority backlog /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig cluster-lifecycle


<!-- 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: [zh] Need trans for <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh
/assign


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 "" Why is this needed There is no Japanese translation for this page Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/area localization /language ja /assign
thank you!! /triage accepted


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 page has a heading, , that isn't actually needed. Readers can work out that the page has an introduction by reading the text from the start. Typically, we don't start our document pages with a heading such as Introduction; instead, we have introductory text before the first heading. Proposed Solution: Delete the line from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /good-first-issue /language en If you have already worked on an issue and have had your change merged, please consider holding back on this one. That will let other, less experienced, contributors find this to work on it.
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The page has a heading, , that isn't actually needed. Proposed Solution: Delete the line from <!--Kubernetes Version:--/good-first-issue /language en </details
/triage accepted /priority backlog
/assign
I'm closing my PR and expecting new folks to actually contribute to fixing this minor issue. Feel free to raise a PR for this issue! /unassign
can I work on this issue! /assign


Umbrella issue: Remove the following from L6-8:
/kind cleanup
/language ko
/assign
This issue is included in also.


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: Documentation contains an error: URL: chapter: kubeadm blocks when removing managed containers: Text in doc: Inspecting the logs for docker may also be useful: Error: This command runs into an error (on my ubuntu 18.04 distribution): Proposed Solution: Replace command with: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version: v1.18--<!--Additional Information:--
/sig cluster-lifecycle /good-first-issue /help /kind bug it should have been or just let's go with:
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cluster-lifecycle /good-first-issue /help /kind bug 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


A link reference from to has the title text whereas the current title of that page is It will be a little less confusing if the link title was adjusted to be the same as the page title.
/sig docs /language en /assign
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /kind suggestion I Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I Agree on your point. If triage accepted, i will update this reference text from to that can avoid confusion.
This issue got resolved with PR .
/triage accepted


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: Information regarding volume snapshot API in the following blog is not accurate. Volume snapshot API moved to GA in 1.20, so volume snapshot v1beta1 was deprecated in 1.20. Proposed Solution: Information regarding volume snapshot API in this blog is correct: Please update the API Removals Deprecations blog accordingly. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Incorrect information regarding VolumeSnapshot API in v1.24 upcoming removals article /area blog /language en What is the correct statement about the fate of the v1beta1 API for VolumeSnapshot When did (or will) that API version transition from deprecated to unsupported?
I suspect the fix is to edit: to: Does that sound right? /triage needs-information
Change 1: which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20 Change 2: Above has to be: [diff ]
The following is correct: . Volume snapshot and restore functionality for Kubernetes and the Container Storage Interface (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and is now unsupported. Refer to and for more information.
/assign
I completely agree with the contexts that has shared.
New PR has been raised for this issue.


This is a Bug Report Problem: The link for in  is incorrect. It is redirecting to but it should redirect to Proposed Solution: should redirect to instead of
/sig docs /kind bug
Page related to the issue:
/language en
I would to like to solve this issue if triage gets accepted.
/triage accepted
/assign
The issue is fixed here:


As part of "Remove Docker Engine", this page should probably also tell the user that may want to clean up space was consumed by docker, e.g. . Otherwise, potentially much space is left used but unmanaged on the node.
Sounds good. We could link to and similar page fragments; if we do, we should caution people that Docker's advice has a risk of trampling on containerd. Ideally, we provide just links to third party docs here. However, neither Docker Engine nor containerd has docs for migrating from one thing to the other (let alone any Kubernetes-specific considerations). I'm happy to treat that as a valid exception from the usual .
/sig node /triage accepted /language en /priority backlog
/assign


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: wrong command for strategic merge patch: "kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-" Proposed Solution: correct command: kubectl patch deployment retainkeys-demo --type strategic--patch-file patch-file- Page to Update:
/wg api-expression /language en
/assign
/triage accepted /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


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: Kubernetes previously paid attention to an annotation, . We now use instead. Even so, should document that annotation. Proposed Solution: Document that annotation; as a side effect, this registers it. I assume that we should also mark it deprecated. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /sig scheduling
/assign
/triage accepted


This is a Bug Report The doc about finalizers doesn't give any information about the fact that the API server considers a deleted service account or a deleted pod's token invalid after 1 minute the DeletionTimestamp. ref: <!--Required Information--Problem: Proposed Solution: Document with a note. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/sig apps


This is a Bug Report Problem: The of is mentioned in . which is wrong, As per mention in the the correct Feature state for is . Proposed Solution: Change the Feature State of from to . Page to Update:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig network /assign
Fixed it here:


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


This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. What would you like to be should mention field Why is this needed This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. Comments We might use a warning from as a draft and modify it accordingly. /sig auth /kind documentation
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : This is a Feature Request The chapter that describes volume should mention field and recommend to use it when possible. should mention field This improves cluster security and should be always used when possible. Without a warning users might not know or just forget to specify this flag. We might use a warning from as a draft and modify it accordingly. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or .


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


When re-syncing , found that are being translated into "" and "" on the same page. I am confused about which word would be better when looking for documents. So I think it would be great if we reach a rough consensus and write into the in the Mandarin localization guide. Including "": 56 files / 229 lines / 243 words Including "": 68 files / 182 lines / 196 words Including both terms: 31 files It's hard to tell the correctness of files including both terms without reviewing them, it will cost a lot of time. So here is just the line count for occurrence of two terms. <pre<code 17 19 2357 <a href=""content/zh-cn/docs/reference/access-authn-</a5 6 558 <a href=""content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-</a13 5 226 <a href=""content/zh-cn/docs/reference/access-authn-</a4 7 526 <a href=""content/zh-cn/docs/tasks/administer-cluster/securing-a-</a6 4 2410 <a href=""content/zh-cn/docs/reference/command-line-tools-reference/kube-</a3 25 1383 <a href=""content/zh-cn/docs/concepts/security/pod-security-</a3 4 903 <a href=""content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-</a3 4 1003 <a href=""content/zh-cn/docs/reference/command-line-tools-reference/kube-</a7 3 1981 <a href=""content/zh-cn/docs/reference/command-line-tools-reference/kube-controller-</a10 3 2033 <a href=""content/zh-cn/docs/reference/access-authn-</a2 4 1630 <a href=""content/zh-cn/docs/reference/using-api/api-</a2 2 2513 <a href=""content/zh-cn/docs/reference/command-line-tools-</a2 2 1151 <a href=""content/zh-cn/docs/reference/setup-tools/kubeadm/implementation-</a2 2 1091 <a href=""content/zh-cn/docs/concepts/security/multi-</a3 2 1374 <a href=""content/zh-cn/docs/reference/access-authn-authz/admission-</a15 2 603 <a


href=""content/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-</a1 4 849 <a href=""content/zh-cn/docs/reference/access-authn-authz/certificate-signing-</a1 3 668 <a href=""content/zh-cn/docs/tasks/configure-pod-container/migrate-from-</a1 2 500 <a href=""content/zh-cn/docs/tasks/configure-pod-container/configure-</a1 2 147 <a href=""content/zh-cn/docs/concepts/cluster-</a1 1 1182 <a href=""content/zh-</a1 1 344 <a href=""content/zh-cn/docs/concepts/cluster-administration/system-</a1 1 373 <a href=""content/zh-cn/docs/concepts/security/rbac-good-</a1 1 1140 <a href=""content/zh-cn/docs/setup/production-environment/tools/kubeadm/create-cluster-</a1 1 370 <a href=""content/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-</a1 1 431 <a href=""content/zh-cn/docs/tasks/administer-cluster/namespaces-</a1 1 519 <a href=""content/zh-cn/docs/tasks/administer-</a1 1 645 <a href=""content/zh-cn/docs/tasks/configure-pod-container/configure-service-</a2 1 2240 <a href=""content/zh-</a4 1 60 <a href=""content/zh-cn/docs/reference/access-authn-</a15 1 588 <a href=""content/zh-cn/docs/setup/production-</a</code</pre
Opinion: I found (Security Framework: identification, authorization, authentication, and permission control). As it said: mapping to authorization, and mapping to authentication.
According to the official bilingual vocabulary list of Taiwan (temporary unavailable for unknown reason): is recommended to be translated to / is recommended to be translated to / / / / (Just for the reference, it's not that suitable for translation.)
Hope we can get inputs from active translators. CC
/language zh
wow, in my understanding, current authentication is with less confusion. Authorizer is recommended to use , and is for authorize and authorization. For most people, authz (authorize, authorizer, authorization) is related to for their first impression.


This may cause some review efforts.
I agree.
+1
+1 I refer to the localized content of AKS and EKS, and hold the same opinion. /triage accepted
I think we all agree to the translation provided in . Hey may I ask you to add it into the glossary of terms?
Ok, let me have a try to add this glossary.


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


cc: Task docs referencing how to check if dockershim removal affects users to be to the discussions. Link to be : (/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Issue raised per
/sig docs /language en


Problem: do not have chinese docs: Proposed Solution: add chinese docs in website Comments /language zh /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/close New tracked in
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


in this section: we document the kubeadm skew against the control plane, but we do not mention the skew of kubeadm against: the kubelet kubeadm itself replace the section with the following to clarify all points:
/sig cluster-lifecycle /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /sig cluster-lifecycle /help </details
/assign
thanks for assigning your self. i've some quick edits to the text a couple of minutes ago.
found them
/triage accepted


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


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


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


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: At Line 398, The link for "Planning your cluster and worker node setup" might seems to be changed from Proposed Solution: The link has to be changed as "". Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /assign


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The Bold isn't effect in "Auditing", as shown below: ! Proposed Solution: Modify the format to make the bold effective. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
If this issue been triage/accepted, I think I can fix this. /assign
/sig docs /language zh
/triage accepted
Thanks for the catch! You can fix it if you want.
Sure, let me fix it.


Problem: The text on is not working, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. Page to Update: Suggested Solution: It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link to and not to this . /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text on is not working, on the official website of weave, it has mentioned that the service has ended so; I believe it should point to this Check the page Installing Addons  for the problem. It should resolve this issue by adding a simple link and enhancing the document line. Update the text Weave Cloud account link to and not to this . /assign /language en Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I'd change: to
/triage accepted
/sig docs
/assign


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Through the progress with many contributors, the content of got a little bit unclear. ] (Most of the sentences are updated about 3 years ago.) ] Let's call the sentence Consequently, a volume outlives any containers that run within the pod, and data is preserved across container restarts. "the sentence A". In the paragraphs of the current version, the sentences ahead of the sentence A is not a basis or reason of the sentence A. Proposed Solution: Page to Update: /assign
/triage accepted
/sig storage


<!-- 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 Link to at the end of Make this link particularly prominent. It should come before the other three links in the What's Next section of the page. Why is this needed directs readers to visit However, people who get to the end of do not see any link back to Comments This is a consequence of the Katacoda shutdown - - and our response to that shutdown. /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 Proposed fix in
/good-first-issue (retrospectively)


This is a Bug Report Problem: There is incorrectly translated content in docs/concepts/storage/volumes/#hostpath . in English: in Korean: Proposed Solution: Page to Update:
/kind bug /language ko
/triage accepted


This is a Bug Report Problem: The konnectivity docs: Include the following instruction: Setting to doesn't seem right: This will break authentication for all tokens that use the default audience value (taken from the value), which is most tokens. This will allow tokens with in them to authenticate directly to kube-apiserver. I don't think we want that. Instead, we should just depend on konnectivity-server specifying the right audience in . Also: is unlikely to be a valid value for . In practice is typically an URL. Proposed Solution: Instead of including incorrect flag values inline, just link out to the correct documentation at Page to Update:
/triage accepted
/assign cheftako
GitHub didn't allow me to assign the following users: jkh. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign jkh 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 jkh52
/cc
Hi thanks for pointing this out. I just wanted to link this issue with the unfinished discussion in BTW, wouldn't it be more correct to specify both audiences: - where is value for the cluster Please correct me if I'm wrong but do you suggest to specify already existing audience for konnectifity-server, eg. this one which is used in kubeadm clusters by default: - where is value for the cluster Agree on that. I have the following setup in my project right now: I'd like to change it to be more correct. Based on said above. I suppose we have few more options: All three configurations are working, now we need to choose the most correct one. Of course we can link to the documentation page, but as for now it has no any usable examples to allow user simple start using this. I'm not big fan of leaving user without proper examples because they will just start using random configuration which works. Let's define correct defaults instead. Other services (eg. istio, vault) can rely on this configuration snippets as well.


From my point of view option C is the most correct, what do you think?
The audience is meant for the konnectivity server, not kube-apiserver directly, correct? In other words, seems like those tokens should require proxying through the konnectivity server, kube-apiserver shouldn't accept them directly? ( this was the impression I got in our offline conversation - did I get that right?) I'm suggesting we can probably just leave unset and let it inherit from .
This is what I'm proposing:
Okay this is option B, but this way we would need to configure konnectivity-server with the flag: And konnectivity-agent with the volume: would it be correct configuration, or maybe better to use separate audience (option C)?
My current understanding is that we can use , since the konnectivity-server can tell kube-apiserver which audiences to validate against when it makes the request, and those apparently don't have to match kube-apiserver's :
I agree that we should link to the canonical documentation for setting up service account token issuer vs copying it here. These are now required flags so widespread adoption is imminent. We should leave Konnectivity server configured with . This means that Konnectivity server identifies as and will only accept tokens that are meant for audience . We shouldn't add to kube-apiserver, because we don't want kube-apiserver to accept tokens meant for connectivity server. Looking at the other docs, we likely don't have enough documentation on how to pick a value for . isn't great. is slightly better. Ideally, this is a globally unique URL (i.e. no private DNS or IPs) that supports OIDC discovery. In GKE, this is something like for in project in location . EKS is something similar.
Oh, got it! I don't remember exact reason why I started using this flag, but I just checked and confirm that it is working fine without it. Suppose it was just a configuration mistake. I'll prepare PR to fix this.
/assign
Hi, I was copied in. How can I help?
you're member of , we need an approval for to get it merged.
Best thing usually is to contact the if a review is urgent / not happening. Although, this week I'm sharing cover for that. So, consider me informed. I'll take a look.


Cloning is only supported within the same Storage Class. Cloning has supported different storage class
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
Hello It sounds like you might want to report that a web page is wrong. If that's right, what's the URL of the webpage? Also, could you quote or point out the text in that page that isn't right? /language en /triage needs-information
/sig storage
Hi i would like to explain this issue if i am not wrong wants to update this . As is merged so now users will be able to clone a volume with a different Storage Class. The destination volume no longer has to be the same storage class as the source. But in current documentation we have the behaviour as. Cloning is only supported within the same Storage Class. Destination volume must be the same storage class as the source
I would like to work on this. /assign
Sorry my bad.. Thanks for pointing it.
/remove-triage needs-information