I wish /docs/getting-started-guides/ listed both Ubuntu guides in the Bare Metal section, noting the networking for each (the listed one uses Flannel, the omitted one (but it is in the navigation panel on the left) uses Calico).
Ubuntu is getting a big rewrite as well.


I wish /docs/getting-started-guides/docker/ I wish this page existed


Cites looking at a cephfs example, that promptly 404's once clicked
It appears this should actually point to: not


A user linked to this guide from an issue: I believe that guide is unmaintained. It still specifies k8s 1.1.2. can we delete?
Thank you. Yes, this guide was unmaintained and community contributed. I am OK with this change. devin-donnelly wrote:


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


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


Problem: this page should mention concept as a way to create an external LB to an application. Page to Update:
There are some offhanded mentions of Ingress in samples, but they're likely to be more confusing than not. Agreed: more/better docs needed.
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


<!-- 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.


This is a... [x] Bug Report Problem: The documentation mentions "optional" in the restrictions for configmap, but doesn't explain how to use it anywhere else in the documentation. You must create a ConfigMap before referencing it in a Pod specification (unless you mark the ConfigMap as “optional”). If you reference a ConfigMap that doesn’t exist, the Pod won’t start. Likewise, references to keys that don’t exist in the ConfigMap will prevent the pod from starting. Please see for the feature. It appears it got lost in the 1.5-1.6 upgrade. Proposed Solution: Restore the copy from that wrote. Page to Update:
For clarity, the copy from got removed here:
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
/language en /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
/remove-lifecycle stale
/priority backlog
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
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 stale
/remove-lifecycle rotten
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
Relevant to /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
This awesome feature is still missing in the documentation, Can someone please add it ?
were you thinking of opening a pull request? We'd be happy to help you with that.
/remove-lifecycle stale
/lifecycle frozen
/triage accepted
I don't see any updates; so unassigning you. Please feel free to assign, if you come back here again and are willing to work on it. Thank you! /unassign
/assign


This is a Bug Report This issue appeared recently within kubernetes/website. Links in follow the next pattern , see a square bracket inside of the . I tried to follow in order to find a source of the issue, but wasn't able to do so. my best guesses: Source for generation for 1_17 branch was corrupted. Backend was replaced by something else but not commited (i don't believe in this). This can be temporary content (on ein PR) as toolset for kubernetes-sigs/reference-docs .
/kind bug /priority backlog
ping
I am looking now
, you are referring to a link problem in the reference? I don't immediately see a problem. Can you provide an example of a command that has a link issue? Thanks! I see a link that appears incorrectly formatted, such as the flag in the command, Though, the link does work for me.
I plan on updating the build instructions and README.
any link that follow pattern . If we ware talking about from the root of the kubernetes-sigs/reference-docs, it would be any link in usage block. Almost all of them are anchor links, so problem isn't visible at first. search for or , last symbol of the link is clearly not suppose to be a link (at least its not a link in source yaml) P.S. Is it worth time to update build instructions now? Isn't going to change generator backend to htmlwriter?
, I have a feeling there is a miscommunication. I am not sure what you are referring to. I thought you are logging an issue specifically to the kubectl reference. Please provide a specific example.
ok. for on link to for on link yourself why is in link. diff for kubernetes/website (kubectl-) and see how links are formed. -become right bracket in the href attribute. P.S. just updated one of the search links as i forgot to copy/paste last element of the link (). P.P.S. looks like regular expression issue.
I see. I think we are referring to the same problem -- the right bracket.
Should I close issue or you prefer to have it opened untill kubernetes-sigs/reference-docs is opened?
, I would leave this issue open as a reminder for next release. Thanks! NOTE: The links were manually fixed for the 1.17 release (search/replace).
got it!


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is out of date; it talks about Kubernetes releases v1.6 and v1.8 Proposed Solution: At a minimum, remove the reference to releases v1.6 and v1.8 from the glossary entry. It's OK to revise further as well. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /kind cleanup /help /language en /priority important-longterm Also see issue
I'll work on that! /remove-help /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 Revise to signpost new contributors to Why is this needed If someone arrives at (possible from ) and has not already contributed to the website, then it's good to let them know that there is a whole section of documentation aimed at exactly that target audience. Comments /language en /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Revise to signpost new contributors to If someone arrives at (possible from ) and has not already contributed to the website, then it's good to let them know that there is a whole section of documentation aimed at exactly that target audience. /language en /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
/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
/assign


This is a Bug Report Problem: The text unclearly says: "Deprecated metric signal that the metric will eventually be deleted; to find which version, you need to check annotation, which includes from which kubernetes version that metric will be considered deprecated." (Note the problems, such as "Deprecated metric signal ...," "to check annotation," unclear references to versions (when metric will be gone, when declared deprecated, other?), etc.) Proposed Solution: Have a fluent English speaker (who knows Kubernetes) edit that. Page to Update:
/language en /sig instrumentation
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
/triage accepted
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
I'd like to try a pass at this. /assign
Not sure if I'm able to do this, but let's try: /remove-lifecycle rotten


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: Glossary tooltip code for "node" shouldn't be in the short_description section. It doesn't display it correctly. Proposed Solution: Change it like original document. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Page to check:
/language ko /assign


This is a Bug Report Problem: missing double quote (") after the word services in the last table Proposed Solution: Add the missing double quote (") Page to Update:


I would like to have the "Container Lifecycle Hooks" page to be translated into Italian page /language it /priority important-soon
/remove-priority important-soon /priority important-longterm
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
Hi I am taking this issue! :smile: /assign /lifecycle active
this can help (you can find specific instructions for the web-site) Ping me if you need help
Hi I have finished my issue! PR ! Let me know!


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: This line includes glossary. However, the displayed content is glossary. ! Proposed Solution: The contents should be glossary, but I don't know how. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language ja
/kind bug /priority backlog
/assign


At the quarterly planning meeting we agreed that we should update the PR wrangler document to be more relaxed about contributed PRs that are solid content but don't exactly meet to the style guide requirements. This was requested to help keep contributions flowing in since we are short staffed. I plan on making this update to the document.
/assign
/cc
/kind cleanup /priority important-soon


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: line 35~39, there are extra spaces(more than 4 spaces) in front of shell box. line 427~430, it should be a shell box. So, we need shell code. line 445~451, it should be a shell box. So, we need shell code. Proposed Solution: [1] : Specifies the . Resource types are case-insensitive and you can specify the singular, plural, or abbreviated forms. For example, the following commands produce the same output: [2] [3] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/assign


Umbrella issue: Remove the following from L6-8:
/assign inductor
/kind cleanup
On it!
/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


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--On the page: Under the section: Forward a local port to a port on the Pod This page suggests using kubectl port-forward to forward ports to your pod. However, kubectl port-forward does not return, it is not daemonized by default. The page does not note this fact Proposed Solution: Either: modify the page to indicate that kubectl port-forward will not return, and that the user needs to open another terminal window to continue with the exercises; OR modify the kubectl port-forward commands to include a & (ampersand) at the end of the line, so that the job will run in the background and return to the terminal prompt. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en
/assign
Maybe adding a flag to is a better way to solve this problem, such as ?
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


Problem: The 5 fields of the cronJob schedule format are not described on the page - there is only a link to some external documetation (). This documentation however is for a 6 field format which include an extra seconds field at the start. Also the use of in the examples isn't required because `` already means every minute. Proposed Solution: Linking to a page which describes the 5 field version of the cron format e.g. the Wikipedia page: Page to Update:
/kind bug /priority important-longterm /language en


This is a Bug Report Problem: The link (/docs/home/contribute/style/page-content-types/#concept) from the Concept page is not correct. Proposed Solution: Page to Update:
Thanks for spotting this. /kind bug /priority backlog /language en


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 to document that namespaces starting are reserved. Why is this needed According to all namespaces with names that start with are reserved. Comments /kind feature /language en /sig architecture /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --Update to document that namespaces starting are reserved. According to all namespaces with names that start with are reserved. /kind feature /language en /sig architecture /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
/assign me
GitHub didn't allow me to assign the following users: me. 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 me </details
/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 Add a facility to search the website to the main page, Why is this needed Let's say someone arrives at and wants to find the download page. Well, the top 3 results on look pretty relevant. The trouble is there's no form on to do that search, and it's not obvious that navigating round the site will reveal that search. Comments Consider both desktop and mobile browser use cases. The main page is some readers' first impression of Kubernetes, so it's important to make a good one. Most people known how to use Google (other search products exist) so fixing this need not be a priority.
I think this dovetails with as well. From an implementation perspective (from what I can tell) the site uses a custom google search engine. First step would be identifying who the admin(s) of that are. Second step would be identifying what directories are scanned Third step would be including the pages we now want to include. Fourth step is fairly easy – add to the layout template you want to see a search box on. The third step requires some thought, however. If we put a search box on the homepage, is the expectation that it searches the entire_ site or just the docs+blog? From a UX perspective, if I see a search box on the homepage I kind of expect it to search everything.
The site search already covers the whole site, so this is really about adding a form to the front page.
For an example of where to put a site search on the main page, see (I'm not proposing to move the search UI there across for the whole site; that would be a separate issue).
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
Also relevant: issue
/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
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
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
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-contributor-experience at . /lifecycle rotten
/remove-lifecycle rotten /lifecycle frozen
/triage accepted
/area web-development (ish)
/priority backlog
I'm more than happy to work on it and get this moving forward. /assign
/assign


Umbrella issue: Take Advanced Contributing Be a PR Wrangler for a week topic and create a new page, Participating in SIG Docs PR Wranglers.
/assign /kind cleanup
/language en


This is a Feature Request What would you like to be Translate docs/setup/production-environment/windows/intro-windows-in-kubernetes/ 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


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


/language zh
/sig auth
/remove-sig auth /assign
Is this not SIG Auth?
By mentioning 'SIG Auth', we mean we want members from that SIG to help review the localization. For one thing, I'm not convinced that will happen. For the other, such mentions are distracting that SIG's attention on PRs which needs their feedback.


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. --Document Volume and Claim Pre-binding feature. Why is this needed PVC & PV pre-binding is useful sometimes, but this feature is not documented in our official website. It's better to add a topic or subtopic for it. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/sig storage cc /assign working on it


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
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


This is an enhancement 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 Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. It is also OK to replace this page with a hand-written overview that achieves the same effect. Why is this needed ReplicationController is deprecated. Comments You can make this change by editing the attribute in the of pages inside . /language en /priority backlog /good-first-issue /kind cleanup
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is an enhancement Request <!-- See for guidance on writing an actionable issue description. --Change to list Deployment and ReplicaSet early (Deployment first), with ReplicationController at or near the end of the list. ReplicationController is deprecated. You can make this change by editing the attribute in the of pages inside . /priority backlog /good-first-issue /kind cleanup Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Just the order of list needs to be changed to list Deployments and then ReplicaSet early and ReplicationController at the end in the , right?
(and to anyone else) you can make the minimal change you described, or you can consider further tidying. Either approach is valid; if you like, there is a spectrum of thoroughness in how you deal with this.
Oh, I've fixed the link to front matter; it should be to
Hey folks, I can take care of it if OK with that.
Sure you can go ahead!
Thanks! /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: There is a remark that mixes up two issues: is not about , rather it is about . even actually relevant to kube-controller-manager? Ayodele Abejide and I can not see any relevant for it (). 1350 looks like a show-stopper for this recipe. Proposed Solution: Fix the recipe. Fix issue 1350. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig auth /language en
/kind bug (seems valid to me)
Note: Remove the flag --client-ca-file from the Kubernetes controller manager configuration. You can also replace the existing client CA file or change this configuration item to reference a new, updated CA. Issue 1350 tracks an issue with Kubernetes controller manager being unable to accept a CA bundle. i think the problem that --client-ca-file and --cluster-signing-cert-file flags share is that the KCM does not allow CA bundles for both of them. this also implies complications around this guide. the kubeadm ticket is noisy and i don't think it should be linked from this page. note that the step above mentions: Update Kubernetes controller manager's --root-ca-file to include both old and new CA and restart controller manager. at that point if the same file is a bundle the KCM would just error out because of --client-ca-file, thus the recommendation about removal or making it point to a separate CA. used for client certificate authentication to allow clients to validate the signature of the serving certificate. the KCM can still be served over HTTPs. i guess not if the flag is removed from from the KCM, until the old CA is removed from the bundle at which point the flag can be re-. i think there are wider problems here and we should have an issue in k/k tagged with sig/auth that tracks progress on the KCM supporting bundles. i've seen mentions around this being worked on here: the note in this document needs clarification: it should link to the k/k issue, if one day the KCM --client-ca-file supports bundles it should explain why the flag is being removed and what are the consequences of doing that (e.g. MITM?). should the flag removal be temporary until the bundle no longer has the old CA? cc
In my opinion, the flag is still needed, when I tested the recipe there were 2 problems at the start, one from and another from , that when I found to be problematic, the point that later only got caught when I removed chain from . That's why I included this in the recipe, that we should either remove it or replace it with the new CA, whichever fits the need cluster to cluster basis. It doesn't makes it show stopper but, yes, I agree that the page needs a bit reword in the paragraph to make it less confusing for people following it.
PS: Just in case someone wants to re-validate, the error I was getting with with old+new CA certs was similar to "certificate signed by unknown authority" and stopped when I replaced it with only new CA. So it was more like the first bundle in the chain was accepted but the newer one did not.
/priority awaiting-more-evidence Please feel free to /priority some-other-value and /triage accepted if this is confirmed valid.
would you like send a PR to amend the paragraph? EDIT: NVM i've sent the PR here, PTAL:
(sent the PR) /remove-priority awaiting-more-evidence /priority backlog
/triage accepted


This is a Feature Request What would you like to be Translate docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/ into Japanese. Why is this needed This page has not been translated. Comments /language ja /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: can be set to any value, but . If it's set to any value less than 10s the CronJob will be never scheduled. Proposed Solution: Force the value to be always greater than 10, or warn people there are non-working values Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: 1.15.12
/kind cleanup /language en /triage accepted
Thanks
Relevant to
I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. Specifically I would add a callout, with text similar to: /good-first-issue /sig apps
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 : I recommend adding a warning. There is a v2 controller for CronJob arriving in Kubernetes v1.20 that may eventually honor any setting for ; however, we want to document the shortcoming right now. if is set to a value less than 10 seconds then the CronJob may not be scheduled. /sig apps 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


This is a Bug Report <!--Required Information--Problem: In Dualstack doc updates for 1.18 , it only removes IPVS prerequisites in but not remove it in , you still can find "Kube-proxy running in mode IPVS" in the doc. Proposed Solution: remove "Kube-proxy running in mode IPVS" in Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en /priority important-soon /kind bug – Can you verify the issue described is correct? If so we can tag it as a good first issue and have someone tackle it.
Hi and Thank you very much for raising this. I can indeed validate that the issue is correct and that the proposed solution is correct and would be more than happy to review a PR if someone would be happy to contribute. Thanks again
/assign
– no further action from you needed, this was a small fix. Thank you!


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


A page just to provide a link another page? My be you are planning more links on this page. If not this page it self can point to target page.
Hi in this there is another link reference to kubectl commands refrence , so far i am understanding is that you want to replace reference Link for kubectl command to be in this ?
To fix this, edit  so that it redirects to /good-first-issue /language en
/triage accepted
/retitle No page content for
/assign
hi could you help to review the PR? Thanks
~reviewers~ approvers for the English localization (who are mainly volunteers) pick up that task on a . I can take a look though.
/remove-good-first-issue
/assign
I the redirect () but it doesn't seem to be working on the deploy preview or locally. Any advice would be appreciated:


/language zh /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 : /language zh /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted


/language zh /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 : /language zh /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
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 Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected. So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks


I am following the minikube tutorial () and find two different ways to getting the roll-out status of an deployment: vs. I am using locally: What is the difference between these two? Might be a good idea to add a node to step number 3 which explains this.
I think that an appropriate improvement that's in line with your comment is to change to run instead. That sounds reasonable to do. /language en /kind cleanup /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I think that an appropriate improvement that's in line with your comment is to change to run instead. /language en /kind cleanup /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 Multiple way to refer to Deployment resource confusing in Deployment concept page
/assign


translate into Chinese
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 /language zh


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is a page about performing a particular task, but it lives in the Concepts section. Tasks should be in the tasks section. Proposed Solution: Change the title of the page to “Garbage collection for container images” Hyperlink from within to the page (remember, this PR will just cover the English localization) Page to Update: Additional Information: /kind cleanup /language en /sig node /help Relevant to issue It is OK to clean up the content of the page beyond what this issue describes. Check whether it makes sense to remove the section. This could be because we or because the information is out of date.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: is a page about performing a particular task, but it lives in the Concepts section. Tasks should be in the tasks section. Change the title of the page to “Garbage collection for container images” Move the page inside Additional Information: /kind cleanup /language en /sig node /help Check whether it makes sense to remove the section. This could be because we or because the information is out of date. 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
No. I don't agree to this movement. The reason is that garbage collection is an administrator job. However, is mostly about concepts an end user need to know. If needed, we can add links to make sure users can learn what's happening behind the scene. Page movement like this is harmful rather than helpful.
I've revised the issue description /retitle Retitle “Configuring kubelet Garbage Collection” and add incoming links
/assign
To confirm, the goal of this issue is to: retitle the GC concept page (not move the page or retitle the file)? link from the containers concept page to the GC concept page
Note: I found 2 Garbage Collection concept pages: The "cluster-administration" GC concept page focuses on the kubelet flags. This page is not listed in the "cluster-administration" index page. Could the index page list the GC page under the "Managing a Cluster" section? A side note, where is defined?


Nginx https 404
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
Hi It sounds like you wanted to provide feedback about a web page. Which web page was that? /triage needs-information


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: ! ! Proposed Solution: Page to Update: <!--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
/kind bug
/assign


It‘s Content have no change from following link:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
hi, can you better explain the problem and re-open the issue after that? thanks /sig docs cluster-lifecycle /priority awaiting-more-evidence /close
Closing this issue. <detailsIn response to : hi, can you better explain the problem and re-open the issue after that? thanks /priority awaiting-more-evidence /close </details
After some testing and guessing, I think the problem is that the fancy tab list on the install-kubeadm page doesn't work for people from China. The reason behind that is the "" is not loaded by the browser. The damn firewall blocked the site used for serving bootstrap JS module. Back to the website, I can see the script reference comes from , which can be overridden. Maybe we should do that because we already have one cached () which is a newer version.
this seems like a good idea. /reopen /retitle tab list component should use the cached bootstrap-
Reopened this issue. <detailsIn response to : Back to the website, I can see the script reference comes from , which can be overridden. Maybe we should do that because we already have one cached (static/js/bootstrap-) which is a newer version. /retitle tab list component should use the cached bootstrap- Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Yes, I cann't open this link() from china.
The problem is that switching tab page from ubuntu16.04 to ubuntu 18.04/20.04 content no change. access this link failed.


command: wget "-O" "/work-" : command: wget "-O" "/work-"
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
why?
sync from en


This is a Bug Report <!--Required Information--Problem: It appears as if the Secret documentation references a feature that isn't currently implemented. Specifically, it includes the following: Prior to this was accompanied by the text: However, PodPresets have been dropped from Kubernetes. Accordingly, this section should reference a different mechanism to achieve the same goal if such a mechanism exists. If it doesn't it should be dropped. From my research, it looks like no such alternate mechanism exists. In another previous revision of that section, the section read: states that PodPresets should be used for secret automounting. It does not mention other options. It also does not imply that ServiceAccounts are relevant. It seems like the ServiceAccount association was back around 2015-2017. Proposed Solution: Unless a mechanism exists which associates Secrets with ServiceAccounts for the purpose of automounting Secrets in Pods associated with a specific ServiceAccount, this section should be dropped. If such a mechanism does exist, the section should be updated to reflect its use or refer to other docs that do. Page to Update:
/kind bug Relevant SIG is SIG Service Catalog, but anyone can tidy up (remove the mention of PodPreset). /triage accepted /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 : /kind bug Relevant SIG is SIG Service Catalog, but anyone can tidy up (remove the mention of PodPreset). /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


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


This is a Bug Report Problem: The dockershim alias () now directs to the Chinese localized version () because the same alias exists in multiple files. Proposed Solution: Removal of the alias in the Chinese version of the blog post or updated to be A policy or linter might be worth putting in place for aliases as well to prevent future issues. Page to Update:
/triage accepted /kind bug /language zh
A similar problem occurred some time ago with aliases in security. I just checked a few other files. Aliases field is set: content/zh/docs/reference/issues- content/zh/docs/reference/issues- Aliases field not set (set in version): content/zh/docs/reference/access-authn- Should add a note to the localization or documentation about how to update the field.
/assign


doc address: The link address is invalid after the field is clicked, return http code 404  SORRY /  /  This page does / ] not exist yet. [ ,'| ] [ / | ] [ ,' | ] ] /[ [ ] ]  / [ [ ] ] ] [ [ [ ] ] ] [ [ [ ] ] ] ] /[ [ [ [ ] ] ] ] (#) [ [ [ [ :====' ] ] ]].nHn.[_[ [ [ ] ] ] HHHHH. [ [ [ ] ] / `HH("N  [ [ ]]/ HHH " [[ ] NNN [ ] N/" [ ] N H [ / N  / q,  /
/assign
/kind bug /sig storage /priority backlog /language en /triage accepted
/reopen
Reopened this issue. <detailsIn response to : /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
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


! Chinese page link can not open
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
/kind bug


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 https://v1- explains how to upgrade a Kubernetes cluster created with kubeadm from version 1.20.x to version 1.21.x, and from version 1.21.x to 1.21.y. (Should be from version 1.19.x to version 1.20.x, and from version 1.20.x to 1.20.y.) Proposed Solution: In Replace =- =- ... Page to Update: https://v1- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/assign
I think we should fix the shortcode to use the documented version, rather than the most recent release. /sig cluster-lifecycle /language en
the intent behind seems to be misleading if is fed at build time pointing at the latest current k8s version. while extending the latestVersion shortcodes i expected to be static and hardcoded per k/website release branch. i can send PRs for this but i'd need to understand more about the "documented" version that you mentioned. i.e. making latestVersion fixed to 1.20 in the 1.20 release branch seems reasonable to me.
^ for additional opinions.
Despite a misleading name, is supposed to use not . AIUI.
i can see is being used in a few places: should all of these be modified to use or only the shortcodes in ? and for which branches - and ?
is useful, it does represent the most recent release.
ok, i can PR the change for 1.20, and master since this is only a problem for the kubeadm upgrade docs. is also used here, but the versions there are just examples. https://v1-
here are the PRs:
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
/remove-lifecycle stale
/triage accepted
/priority-important longterm
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /priority-important longterm Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/priority important-longterm


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , the link is broken. Proposed Solution: In Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/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
already logged here: /close /sig cluster-lifecycle
Closing this issue. <detailsIn response to : already logged here: /sig cluster-lifecycle 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: There exist bugs in . [Part number 1] [Part number 2] Proposed Solution: [Part number 1] [Part number 2] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/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
[As-is] [To-be]
Hello . Note: The release notes are auto-generated. What do you think about logging an issue with the release team (release notes)?
Hi Following your advice, I posted an on . Thank you!
release notes team here. yes this was autogenerated but we had to make manual fix to k/k (ref: ) a few days after the official release went out. i think it's the right move to fix it here as well


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


This is a Bug Report concepts page for spanish links doesn't take to spanish pages <!--Required Information--Problem: The page is the Spanish translation, the links on this page should take you to the Spanish version of the link when available, if not available then ok to leave it pointing to English Proposed Solution: Update the page links to point to Spanish version (ie. es) Page to Update: I intended to review and submit a PR
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language es
/assign
/assign
Thanks for the report, this is quite common as the translation is a work in progress and we don't have (yet) a way to easily detect where a page is referenced. Let me know if you have any issue working with the PR.
I will work on this page as one-off, and think about how can we automate the detection for all links that should point to the Spanish version.
Maybe something that can be done at build time? Don't know how is the site is build I guess Hugo but not how much pre-processing is done


lists RemainingItemCount as alpha but shows it went beta. /kind bug /language en /sig api-machinery
/triage accepted
What was the version when it was promoted to beta? (The PR seems quite old). Was it if I am not wrong? /assign


This is a Feature Request translate /docs/tasks/administer-cluster/enabling-topology-aware- into Chinese. What would you like to be /zh/docs/tasks/administer-cluster/enabling-topology-aware- /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


A on is broken and returning 404 page.
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 Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , when user clicks , ! user lands on , which is for KubeCon & CloudNativeCon North America 2021. Proposed Solution: In , [As-is] [To-be] Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en
/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 href of contains unwanted . A slash () is missing in the href of . Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language en /assign
/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: Visiting provides inaccurate default values for shutdownGracePeriod (30s rather than 0s) and shutdownGracePeriodCriticalPods (10s rather than 0s). Proposed Solution: Correct the documentation to match the actual default values. 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
I would like to take up this ticket.


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In , sub-items are not displayed in sidebar tree. ! FYI Chinese version: ! Japanese version: ! English version: ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
zh: Some Chinese-translated files exist in ko: No Korean-translated file exists in I guess this is the reason why the sidebars of version and version are displayed differently. FYI: On 2021-03-19, the -version sidebar was like this: (screenshot is from the issue ) Even if no Korean-translated file exists in , sub-items are displayed (which are the links to the English version of subcommands). !
/triage accepted
This will affect all localizations /priority important-soon
/retitle [l10n] Sub-items are not displayed in sidebar tree
/area web-development
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]:
Can I work on this issue?
Sure! Please go ahead! /remove-lifecycle rotten
/assign
/lifecycle frozen
/unassign
/assign I'd like to take a look at this
To summarize: Localizations should have the same links listed in their side nav as in the english language docs, regardless of whether the pages have been translated. This is because there is a "fallback" set up to display a link to the english language docs if a page has not yet been translated. The fallback links to english docs for generated reference docs (kubeadm docs) are missing in localize docs sets. (or anyone else), does this sound accurate? I'd like to make sure i understand whats broken before trying to troubleshoot hugo/docsy/mystery code section :)
I've been spending time investigating this and learning how the navigation is built :) I believe i've found the issue. I'll try to summarize below, but I think this is a template issue which should be addressed by docsy. There is a check in () that compares all the pages and sections and then filters out pages that have . We then test for the number of child pages, to determine if we continue to build the next level down in the navigation tree. At this point, because some localizations have the Kubeadm page translated, this check will only find the translated file (files in the kubeadm/generated folder are filtered out bc the file has ). The logic as written determines that kubeadm has no child pages, because it doesn't know about the English pages at this point. This means the rest of the kubadm sub pages links will not be built in the navigation. Theres There is a check later in that merges the localized pages with the missing the English language pages and to inserts links to untranslated pages in the side nav. (). But it only gets to this point if there are child pages, because its wrapped in a conditional (). In my testing i the checking for untranslated pages, replacing lines 49-51 to be the following. This appears to add in the links that were missing. <img width="1569" alt="Screen Shot 2022-09-09 at 11 27 38 AM" src="https://user-"If we agree that this looks and is a docsy issue, I can open an issue there and propose the solution. cc: I would appreciated your thoughts on this, thanks!


Affected page: Move this page from Concepts to Tasks (potentially under Tasks Networking). Update to redirect the old URL to the new location (use a 301 code, similar to other entries in this file). /sig docs /language en
/triage accepted /help
/remove-help
I'd like to work on this one to learn something new in website page organizing. Thanks. /assign


What would you like to be In Seccomp should link to instead of Why For a better understanding of how Seccomp works in k8s. As Seccomp is stable fetaure in k8s.
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
Fixed it here


Document's section: Currenty it says: Kubernetes creates one PersistentVolume for each VolumeClaimTemplate That is not wrong, but not exact. What about replacing it by something like this: Per each StatefulSet triggered pod Kubernetes creates a PersistentVolumeClaim object for each VolumeClaimTemplates entry defined in the StatefulSet object /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
I would like to work on this /assign
Hi i have raised a this.
Thanks ;-)


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 saw by accident very big page files on Kubernetes documentation. For example is lines long and the lines 286- are taken for the sidebar menu containing a lot of whitespace (do right-mouse and "view page source"). Proposed Solution: I reported the issue already with Docsy: and proposed a pull request. But this will not be enough. Somebody has to update too. 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
/assign
The hugo Docsy theme side issue is resolved and closed: When will somebody review and implement pull request ? You can do this separate from a Docsy theme update at It is only about (huge) whitespace reduction, not a functional change. But k8s website users will benefit in user experience.


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 statement seems grammatically incorrect due to missing "on" after "information". Proposed Solution: -Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--/language en /good-first-issue <!--Kubernetes Version:--<!--Additional Information:--
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The statement seems grammatically incorrect due to missing "on" after "information". /language en /good-first-issue <!--Kubernetes Version:--</details
/assign
/sig cluster-lifecycle /triage accepted


According to the : this feature has been graduated to GA in 1.22 The doc still indicates:
/retitle Incorrect feature state for Server-side Apply /kind bug /language en Which page is wrong, ? Can you provide the URL for it?
/wg api-expression
I think the page is /triage accepted
/assign


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.


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: Certain pages have the document.querySelector("body div.container-") element rendering much too wide. The header/nav is the proper width. <img width="1458" alt="Screen Shot 2021-11-15 at 11 19 42 AM" src="https://user-"Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--N/A <!--Additional Information:--Microsoft Edge Version 95.0.1020.40 (Official build) (x86_64) MacOS 11.6
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


links to the wrong Anchor for the CSI Provisioner. It links to #csi-provisioner but should be linking to #vsphere-provisioner-csi Also the link referering to the vsphere CSI repository in delivers a HTTP 404 Status.
/kind bug /language en /triage accepted
/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 docs for  say that this label is set on namespaces when you enable a feature gate, . However that's no longer true. In current Kubernetes the control plane always sets that label on namespaces. Proposed Solution: Reword that section to make it clear that the control plane always sets that label Page to Update: Kubernetes Version: v1.22 Additional Information: /language en /kind bug /help /priority backlog
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The docs for  say that this label is set on namespaces when you enable a feature gate, . However that's no longer true. In current Kubernetes the control plane always sets that label on namespaces. Reword that section to make it clear that the control plane always sets that label Kubernetes Version: v1.22 /language en /kind bug /help /priority backlog </details
/triage accepted
Hi, I would like to work on this issue. /assign
Any questions about how to fix it?
I have a few technical questions: the sets the label on the namespaces instead of enabling the , so there would be no role of K8s API server in this process? will the set label on the namespaces? I mean will it do it automatically or we need to do something to set the labels like enabling something?
The API server is part of the control plane - see The component within the control plane that sets the label isn't a detail we need to specify here. All we need to mention is that it happens, and phrase it to make it clear it's not optional.
Just to be clear that the will set the labels of the namespace and this setting of the labels is compulsorily (i.e. it is not optional).?
(also, we'll get the API Machinery folks to check technical accuracy anyway - it's not on the docs contributors to thoroughly verify this kind of detail).
Okay thanks . I now have an idea on how to fix the issue, I will file the PR soon :)
I have a doubt: The phrase which tells that ,would it be better to included it as a shortcode or it should be kept as a normal text.?
the best way for folks to review your proposed changes is to open a pull request. (Also: anyone else who wants to work on this is welcome to - please liaise with if that's feasible).
I have filed a PR but if anyone wants to work on this they are welcome to share their suggestions in the PR Conversation. Thanks.


Why not use PowerShell Get-FileHash instead of certutil for getting/checking file hashes?
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 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]:
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]:
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: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. 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 closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] 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-lifecycle stale
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /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
-- makes sense. I've raised a PR here -


This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: In the page , there exists a section "Accessing services running on the cluster". When someone clicks the hyperlink in that section, it goes to again. Proposed Solution: I guess that the hyperlink should go to . Page to Update: https://v1- <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign
/triage accepted


Ref: The page is centered around Docker examples and needs a rewrite in light of the Dockershim removal. /triage accepted /milestone 1.24
/sig node
Hi, I would like to work on this but I may need a little help. When we say "rewrite in light of the Dockershim removal", does it just means removing the Docker references on the page ( i.e removing "" on this page) or something more is expected.
Thanks for taking this on. In my opinion, there are two issues to deal with here. The first is easy. Change "Docker image" to "container image". I believe the second instance refers to a legacy Docker feature called . I think it is safe to just remove that sentence.
Thankyou :) I'll make a PR by tomorrow /assign


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


This is a Bug Report In /content/zh/includes/user-guide-content- I think it's better to translate "user guide" into “”
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
File: /language zh
/assign
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted 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
/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 : /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
/language zh /kind feature


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


There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
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 /kind bug
/assign


This is a Feature Request Our workflow has been a great way to meet our commitment in keeping PR numbers at a manageable amount. We've recently introduced a way for new contributors to understand the PR Wrangling process, as a way to onboard possible new reviewers, approvers, and wranglers. What would you like to be The above-mentioned shadowing process was brought up and discussed in a late 2021 SIG Docs meeting, however, has no documentation to explain the process or the expectations of the PR Wrangler and their shadow. We should put together information, to our existing PR Wranglers , that lists details about this program, how to become a shadow, and what participants can expect to learn. Why is this needed To ensure our shadow process is successful, a clearly documented guide is needed so we can better recruit for this program and evangelize it. Given we'll be reporting on this addition to our training in the 2021 Kubernetes Annual Report, we should prioritize the creation of these docs. cc:
/language en /sig docs /triage accepted
Hi, I would like to work on this issue. Thanks. /assign


Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
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 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]:
Thanks for reporting, I can open a PR to fix this! /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 <!-- 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
/retitle [ja] Translate /docs/reference/scheduling/policies/ into Japanese
Re-titling can only be requested by trusted users, like repository collaborators. <detailsIn response to : /retitle [ja] Translate /docs/reference/scheduling/policies/ into Japanese 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 [ja] Translate /docs/reference/scheduling/policies/ into Japanese
/triage accepted


In the v1beta1 admission config example, I had to use rather than See
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
Page:
/sig auth /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: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/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 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
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


Update , job-tracking-with-finalizers section, as k/k PR is disabling by default due to an unresolved bug.
Specifically the note () says that "it is enabled by default."
this feature is currently enabled by default in v1.23 and will be disabled in v1.24, right?
/sig apps /language en
I also proposed to disable it by default in 1.23 , but the release managers haven't approved it yet.
/triage accepted /sig apps
/assign
Thanks


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 link at the top of the homepage () seems to currently redirect to I assume this is the same issue as Proposed Solution: Remove the /dockershim alias from the ZH blog page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Same symptoms, different PR. /triage accepted Thanks. /priority important-soon
/assign