Question: ### AppArmor support This version introduces the initial support for AppArmor, allowing users to load and <del> unload AppArmor profiles into cluster nodes by using the new [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base/crds/apparmorprofile.yaml) CRD. </del> <ins> unload AppArmor profiles into cluster nodes by using the new [AppArmorProfile](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/deploy/base-crds/crds/apparmorprofile.yaml) CRD. </ins> To enable AppArmor support use the [enableAppArmor feature gate](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/config.yaml#L10) switch of your SPO configuration. Then use our [apparmor example](https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/examples/apparmorprofile.yaml) to deploy your first profile across your cluster.

This is a Bug Report Problem: Link for AppArmorProfile in is broken. Proposed Solution: Should be updated with correct link 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
/area blog /language en
/assign


Question: <del> apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: selector: matchLabels: app: nginx replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 </del>

The content of the file version showed in section is wrong. Previous versions where showing the right content, e.g. .
The one in the dev-1.26 branch is not a valid Deployment manifest. The API server will reject this YAML since it is missing some required fields.
Ah, the problem might be that we don't want a YAML file that is a valid Deployment manifest, since this is actually being used to generate a special document used for a with custom Kubernetes semantics. /kind bug I didn't actually know that would accept a thing that's not a valid manifest for ; that's going to be hard to teach / document. Is that even a supported / recommended way to do the change? (I can see that it works; whether it works is very different from whether we endorse it). I think this is a valid report. Maybe we should use an inline example rather than an external file; maybe we need a way to exempt this one YAML file from validation. If we use an inline example, that would mean changing we can keep would need to change.
If this YAML has to be an "invalid" Deployment manifest, using an inline example is more appropriate IMO.
I'll also ask SIG Architecture if this use of is one we endorse.
Exactly, this is one of the "tricks" behind SSA: you only provide (to the you indicate). Providing a fully compliant (from an schema pov) Deployment manifest would actually be a mistake if you only want to modify the field using SSA. Kubernetes client-go was updated to support these non-fully-conformant-from-an-schema-pov manifests: defining the new types for this to be possible as described in this .
/triage accepted /assign
OK, so the input to is no longer defined to be a manifest: it's actually an apply configuration, and all valid manifests are also valid apply configurations. However, defaults to validating that the supplied apply configuration is a valid manifest. You can then turn off that validation by using . Have I got that right? If so, I think we missed a key docs update when we made that change to / client-go. is the only mention of the term apply configuration on the Kubernetes site; the docs don't describe this at all. The rest of this comment assumes that the apply configuration concept does need documenting. I think we should clearly document which subcommands work with manifests and which with apply configurations.

For example, I'd have to turn to the source code to answer which kind the subcommand expects, and that's not something an end user should need to be doing. A few subcommands and plugins to consider: - -
I also think we should track a new issue for to document the apply configuration concept, and leave this issue to cover the specific bug that reported.
is solving the reported fault (so properly closing this issue), thanks for it. I think there is still room for improvement in the "Transferring Ownership" example this issue is targeting (maybe to consider it in a future update of these pages?): For the "more advanced" case (the one targeted by this issue) it is proposed to use a partial manifest; used term here should be "fully specified intent" as it is the introduced term at the beginning of this same SSA doc. page to name these "shorter" yamls we can use with SSA. In the final is not needed, better to remove it to not confuse the reader.


Question: 输出中包含 `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}， 类似这样： <del> ```none </del> <ins> ``` </ins> "kind": "Deployment", "apiVersion": "apps/v1", "metadata": {

There is a bug: ,%E4%BA%86%E8%A7%A3%E5%9E%83%E5%9C%BE%E6%94%B6%E9%9B%86.,-%E5%8F%8D%E9%A6%88 This hyperlink is 404, it should be ""
/assign
/triage accepted
The issue was solved by PR . If there is any problem, please give feedback again. /close
Closing this issue. <detailsIn response to : The issue was solved by PR . If there is any problem, please give feedback again. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: </center> </div> <div class="main-section landscape-section"> <del> {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}} </del> <ins> {{< cncf-landscape helpers=false category="special--kubernetes-training-partner" >}} </ins> </div> </div>

This is a Bug Report In Kubernetes Training page in hindi the link is not valid which do not show the several Kubernetes Training Partners. <!-- 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 embedded link is not valid. ! Proposed Solution: Update with the valid link Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language hi /sig docs /assign
/area localization
/triage accepted
This issue is resolved under pull request
so i am closing this issue marking as resolved and completed
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: {{< /tabs >}} <del> 2. Test to ensure the version you installed is up-to-date: </del> <ins> 1. Test to ensure the version you installed is up-to-date: </ins> ```powershell kubectl version --client ``` <del> 3. Navigate to your home directory: </del> <ins> 1. Navigate to your home directory: </ins> ```powershell # If you're using cmd.exe, run: cd %USERPROFILE% cd ~ ``` <del> 4. Create the `.kube` directory: </del> <ins> 1. Create the `.kube` directory: </ins> ```powershell mkdir .kube ``` <del> 5. Change to the `.kube` directory you just created: </del> <ins> 1. Change to the `.kube` directory you just created: </ins> ```powershell cd .kube ``` <del> 6. Configure kubectl to use a remote Kubernetes cluster: </del> <ins> 1. Configure kubectl to use a remote Kubernetes cluster: </ins> ```powershell New-Item config -type file

There are no details or instructions on how to validate the binary downloaded from this page via some form of checksum, sha256 or otherwise. For automation purposes, eg. ansible playbook, being able to validate any binary downloads is a requirement of project stakeholders.
The site doesn't allow browsing, but the file is there as kubectl.sha256 afterall. Might be worth mentioning this in the document?
/retitle Document how to validate kubectl binary against checksum / signature /language en /kind feature /triage accepted The page in question is
To fix this: update to use download links from for example also explain to readers that checksum files are available that they can use to compare binaries obtained from elsewhere for example The and shortcodes are useful for automatically filling in the current Kubernetes version. /help /sig cli
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 : To fix this: update to use download links from explain to readers that checksum files are available that they can use to compare binaries obtained from elsewhere /sig cli Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I may be able to help with this /assign


Question: {{< /note >}} Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. <ins> To enable bash autocompletion in current session of shell, source the ~/.bashrc file: ```bash source ~/.bashrc ``` </ins>

/kind documentation /sig docs Bash Auto Completion has a missing step to enable autocompletion in current shell session If you have an alias for kubectl, you can extend shell completion to work with that alias: Note: bash-completion sources all completion scripts in /etc/bashcompletion.d. Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. If you have an alias for kubectl, you can extend shell completion to work with that alias: Note: bash-completion sources all completion scripts in /etc/bashcompletion.d. Both approaches are equivalent. After reloading your shell, kubectl autocompletion should be working. To enable autocompletion in current session of shell, source the file:
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
/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
/assign
/assign


Question: <ins> --- title: "ポリシー" weight: 90 --- </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Why is this needed This document is not translated in Japanese. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --Copy a file from en contents to concepts/policy/resource- and translate it into Japanese.
/assign /language-ja
/language ja
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
/assign
/unassign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: Here's an example. Suppose this is the configuration file for a Deployment object: <del> {% include code.html language="yaml" file="update_deployment.yaml" ghlink="/docs/concepts/tools/update_deployment.yaml" %} </del> <ins> {% include code.html language="yaml" file="update_deployment.yaml" ghlink="/docs/tutorials/object-management-kubectl/update_deployment.yaml" %} </ins> Also, suppose this is the live configuration for the same Deployment object:

<!-- 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: 404 on Proposed Solution: Update location of Page to Update:


Question: For example: <del> ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: csr-approver rules: - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests verbs: - get - list - watch - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests/approval verbs: - update - apiGroups: - certificates.k8s.io resources: - signers resourceNames: - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain verbs: - approve ``` </del> <ins> {{< codenew file="access/certificate-signing-request/clusterrole-approve.yaml" >}} </ins> To allow signing a CertificateSigningRequest:

/language zh
/reopen This was incorrectly
Reopened this issue. <detailsIn response to : /reopen This was incorrectly Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: "service/networking": { "curlpod":                                 {&apps.Deployment{}}, "custom-dns":                              {&api.Pod{}}, <ins> "default-ingressclass":                    {&networking.IngressClass{}}, </ins> "dual-stack-default-svc":                  {&api.Service{}}, "dual-stack-ipfamilies-ipv6":              {&api.Service{}}, "dual-stack-ipv6-svc":                     {&api.Service{}},

While working through the Killer Shell scenario for NetworkPolicies to prep for my CKA, I used the example but it failed validation. When I looked at their solution it had one tiny difference, they had a - in front of "ports:" and you guys didn't. Based on the reference docs it appears ports does expect an array which would mean that you are missing the hyphen. docs: solution from
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 indentation of list items may be the source of confusion. Once you indent all list items under a given key, the parent element of the 'ports' attribute becomes more evident. The example on the website is correct. I'm not sure about the solution from If you put as the first key of a list item object, if will carry the bar for that list item, if is not the the first key, you will indent it rather than adding another before it. Anyway, I'm fixing the example in hope things become clearer for readers.


Question: The output displays the pod created: ``` <del> NAME                            READY     STATUS    RESTARTS   AGE redis-master-765d459796-258hz   1/1       Running   0          50s </del> <ins> NAME                     READY   STATUS    RESTARTS   AGE mongo-75f59d57f4-4nd6q   1/1     Running   0          2m4s </ins> ``` View the Deployment's status:

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

On Forward a local port to a port on the Pod section this should be
/triage needs-information
Could you please link the page
This page
/triage accepted /kind bug /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /kind bug /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-triage needs-information
/assign


Question:
  -v, --v int

number for the log level verbosity

  --version version[=true]

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: ! xref: Has references to some CLI arguments that are not valid for . Seem to be side effect of changes went into Proposed Solution: Remove the invalid flags from the documentation in Page to Update:
/language en /triage accepted
/assign
/assign
Thanks for taking care of this :)


Question: demonstrates how to create, delete, scale, and update the Pods of StatefulSets. --> <del> 本教程介绍如何了使用 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) 来管理应用。 </del> <ins> 本教程介绍了如何使用 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) 来管理应用。 </ins> 演示了如何创建、删除、扩容/缩容和更新 StatefulSets 的 Pods。

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
Link: /retitle [zh] Issue with /zh/docs/tutorials/stateful-application/basic-stateful-set
/assign


Question: ### Version removal <del> An older API version cannot be dropped from a CustomResourceDefinition manifest until existing persisted data has been migrated to the newer API version for all clusters that served the older version of the custom resource, and the old version is removed from the `status.storedVersions` of the CustomResourceDefinition. </del> <ins> An older API version cannot be dropped from a CustomResourceDefinition manifest until existing stored data has been migrated to the newer API version for all clusters that served the older version of the custom resource, and the old version is removed from the `status.storedVersions` of the CustomResourceDefinition. </ins> ```yaml apiVersion: apiextensions.k8s.io/v1

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

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

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

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

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


Question: {{< feature-state for_k8s_version="1.22" state="stable" >}} The Kubernetes control plane sets an immutable {{< glossary_tooltip text="label" term_id="label" >}} <del> `kubernetes.io/metadata.name` on all namespaces, provided that the `NamespaceDefaultLabelName` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. </del> <ins> `kubernetes.io/metadata.name` on all namespaces. </ins> The value of the label is the namespace name.

It looks like the feature gate "NamespaceDefaultLabelName" has been removed as described on this page: But it's noted on this page that it can be enabled: Maybe that the "Namespaces" page needs to be updated.
/language en /sig docs
/retitle Unclear documentation on feature gate The documentation is not wrong; however, we can clean up to avoid mentioning the feature gate at all (we'd keep the feature-state shortcode). /priority backlog /help /triage accepted
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 : /retitle Unclear documentation on feature gate to avoid mentioning the feature gate at all (we'd keep the feature-state shortcode). /help /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
/assign
I had the same doubts before, and I changed it by the way, please help review, thanks


Question: * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) --> * [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) <del> * [为 kubectll 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) </del> <ins> * [为 kubectl 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) </ins> * [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) * [为上游 Kubernetes 项目做贡献以改进文档](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/)

This is a Bug Report There is a typo in the Chinese documentation. The text " kubectll " contains an extra "l" in "kubectl". Proposed Solution: The correct text should be " kubectl ". Page to Update:
/area localization /language zh
/triage accepted
/retitle Typo in localized page Kubernetes


Question: * runc：v1.1 或更新版本 * crun: v1.8.6 或更新版本 <ins> * Linux 内核: v5.12 或更新版本 </ins> <!-- ## What's next?

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: Compared with [en] The [zh] miss in section Proposed Solution: add in section 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


Question: scroll-margin-top: 35px; } </style>

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: uses the wrong background color(s); it's but should be (Kubernetes blue). I think the orange color was copied from by mistake. Proposed Solution: Revise the shortcode. Consider making the color be set once and then reused (“”). Page to Update: You would see the change on We should use blue backgrounds whether or not an announcement banner is showing. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: PR updated the shortcode. /area web-development /triage accepted /priority backlog If fixing this, consider also moving the iframe scroll-margin-top fix to be more general. See and
this is a nit against PR but fixing it isn't at all urgent.
/lifecycle frozen We should fix this eventually.
I would like to help with this. /assign
/assign


Question: It conflicts with the [core values of the Kubernetes project](https://git.k8s.io/community/values.md) and our community does not tolerate it. - name: Kubecon 2021 EU <del> startTime: 2021-04-30T00:00:00 endTime: 2021-05-07T00:00:00 </del> <ins> startTime: 2021-04-30T00:00:00 endTime: 2021-05-07T00:00:00 </ins> style: "background-image: linear-gradient(90deg, rgb(249, 145, 6) 0%, rgb(252, 29, 68) 100%)" title: | <img src="/images/announcements/kubecon-eu-2021-white.svg" style="float: right; height: 80px;" />

Problem: The text opportunites is mistyped on the announcement section of . For the problem, check the page . File to Update: /good-first-issue /kind document /assign /language en
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: The text opportunites is mistyped on the announcement section of . For the problem, check the page . /kind document /assign /language en Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-good-first-issue Banner changes are actually a bit weird.
/language en
/triage accepted


Question: This example turned off client-side validation to demonstrate the API server's behavior, by adding the `--validate=false` command line option. <del> Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi-v2) </del> <ins> Because the [OpenAPI validation schemas are also published](#publish-validation-schema-in-openapi) </ins> to clients, `kubectl` also checks for unknown fields and rejects those objects well before they would be sent to the API server.

This is a Bug Report Problem: The hyperlinks for OpenAPI validation schemas are also published and Validation Schema Publishing under the task page is not working. They both redirect to which is incorrect, the correct one is Proposed Solution: OpenAPI validation schemas are also published and Validation Schema Publishing should redirect to instead of 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
/assign
/sig api-machinery /language en /sig docs
Fixed the issue here:


Question: - `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources `GetAllocatableResources` functionality. This API augments the [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) <del> - `KubeletPodResourcesDynamiceResources`: Extend the kubelet's pod resources gRPC endpoint to </del> <ins> - `KubeletPodResourcesDynamicResources`: Extend the kubelet's pod resources gRPC endpoint to </ins> to include resources allocated in `ResourceClaims` via `DynamicResourceAllocation` API. See [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) for more details. with informations about the allocatable resources, enabling clients to properly

The "KubeletPodResourcesDynamiceResources" feature gate is not in the feature gates tables ( or ), it's only on the . I think it should be 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 en
is a typo, notice the extra before the last word. PRs welcome.
I have raised PR to fix the typo
I should have mentioned the page where I saw the typo — there are still two typos there.
These typos should be fixed now after merge of PR


Question: <del> --- reviewers: - dchen1107 - roberthbailey - liggitt title: Master-Node Communication content_template: templates/concept weight: 20 --- {{% capture overview %}} This document catalogs the communication paths between the master (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider). {{% /capture %}} {{% capture body %}} ## Cluster to Master All communication paths from the cluster to the master terminate at the apiserver (none of the other master components are designed to expose remote services). In a typical deployment, the apiserver is configured to listen for remote connections on a secure HTTPS port (443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver. The master components also communicate with the cluster apiserver over the secure port. As a result, the default operating mode for connections from the cluster (nodes and pods running on the nodes) to the master is secured by default and can run over untrusted and/or public networks. ## Master to Cluster There are two primary communication paths from the master (apiserver) to the cluster. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality. ### apiserver to kubelet The connections from the apiserver to the kubelet are used for: * Fetching logs for pods. * Attaching (through kubectl) to running pods. * Providing the kubelet's port-forwarding functionality. These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and **unsafe** to run over untrusted and/or public networks. To verify this connection, use the `--kubelet-certificate-authority` flag to provide the apiserver with a root certificate bundle to use to verify the kubelet's serving certificate. If that is not possible, use [SSH tunneling](/docs/concepts/architecture/master-node-communication/#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an untrusted or public network. Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authentication-authorization/) should be enabled to secure the kubelet API. ### apiserver to nodes, pods, and services The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials so while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted and/or public networks. ### SSH Tunnels Kubernetes supports SSH tunnels to protect the Master → Cluster communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running. SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel. ### Konnectivity service {{< feature-state for_k8s_version="v1.18" state="beta" >}} As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the Master → Cluster communication. The Konnectivity consists of two parts, the Konnectivity server and the Konnectivity agents, running in the Master network and the Cluster network respectively. The Konnectivity agents initiate connections to the Konnectivity server and maintain the connections. All Master → Cluster traffic then goes through these connections. See [Konnectivity Service Setup](/docs/tasks/setup-konnectivity/) on how to set it up in your cluster. {{% /capture %}} </del>

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 am not clearly able to differentiate the Cluster to Master. The topic states that its about Master and Node. What do you typically mean to say Cluster and Master in many places inside the doc. It should be Master and Node or Cluster and Node. There is something illogical to say Cluster and Master, since Master is part of the Cluster and we typically mean Cluster and Master interchangeably. So I would request that clarification is provided to the reader before getting into the topic. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
that's a valid observation. I would reword: “Cluster to Master” → “Node to control plane” “Master to Cluster” → “Control plane to node” and make sure that the page makes it clear that it's common and typical to have several nodes (not just one). Note If anyone is picking this up, also consider renaming the page and adding a redirect. If you're not sure how to do those things you can ask for help using , or open a work-in-progress PR with your question in the comments. /help /language en /kind cleanup /priority important-longterm
Is this issue still open to contributon?
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
/remove-help /assign


Question: ## Running the website locally using Hugo <del> Make sure to install the Hugo extended version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L11) file. </del> To install dependencies, deploy and test the site locally, run: - For macOS and Linux

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 tried to run the cloned website, which I forked on my Ubuntu Machine, but am getting error. I tried both running via docker and my running locally using Hugo but getting some issues in both. Following is the error while running via docker ! and this is while running locally via Hugo ! I also initialized modules by running the command: make module-init
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
/kind support
I tried to analyze a bit. On first investigation, it seems like a valid issue. However, I do not know the root cause. I created a new Ubuntu VM, and tried to setup k/w from scratch. On running , the hugo command was stuck at: I then executed and managed to reproduce the issue you reported. (Note that at times this command gets stuck without an output as well). On my local machine, I have older versions of npm, hugo, go and docker and k/w builds fine. It could be related to one of the upgrades in the dependencies (most probably Hugo), however I cannot state for certain.
The issue is in the Hugo version. Upon changing the version, it worked perfectly. Thanks for your input. I think this issue should be raised.
Can you please mention the exact combination of versions (npm, Hugo, go, docker) that worked for you?
here, it is but I think the issue is with Hugo's version only.
Try whilst you have the latest main branch checked out. That works for me. You should find that you're using Hugo 0.121.2 (see ). If you want to test a Hugo upgrade, run before .
The instruction to install a specific Hugo extended version as defined in is mentioned in the section. However, I believe it would be helpful to move the instruction to the section.

This would prevent readers from inadvertently installing the latest Hugo extended version (currently v0.124.1) which is incompatible with k/w. I'll try to work on a PR for this.
/assign


Question: [options_heading] other = "选项" <ins> [post_create_child_page] other = "创建子页面" </ins> [prerequisites_heading] other = "准备开始"

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: Submodule need to updatecurrent version lack of i18n translation for Upgrade of can solve this problem, see it in ! <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/kind bug /triage accepted /priority backlog /good-first-issue This issue is a good first issue because the single step needed to fix it is to update the version of the submodule.  has some contextual information; the command to use is .
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 : /kind bug /triage accepted /priority backlog /good-first-issue  has some contextual information; the command to use is . 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
:information_source: Note that PR is already open to address this.
/remove-label "help wanted"


Question: `ControllerPublishVolume` and `ControllerUnpublishVolume` calls. This field is optional, and may be empty if no secret is required. If the Secret contains more than one secret, all secrets are passed. <del> `nodeExpandSecretRef`: A reference to the secret containing sensitive </del> <ins> * `nodeExpandSecretRef`: A reference to the secret containing sensitive </ins> information to pass to the CSI driver to complete the CSI `NodeExpandVolume` call. This field is optional, and may be empty if no secret is required. If the object contains more than one secret, all

Declared "CSIMigration" feature gate only exists in . According to "CSIMigration" could be a switchable feature gate, but it looks like it is always on and cannot be switched off, so it it's strange that it's mentioned in the v1.27 documentation. All of this is probably more or less OK, as it's suitable for earlier versions of Kubernetes especially since there are deprecation warnings. But it’s also unclear for which components this feature gate is intended. According to it's intended for . <brIt is not clear for which components "CSIMigrationAzureFile" feature gate is intended. <brIt is not clear which controller manager is meant — cloud controller manager or kube-controller-manager. According to it's intended for . It is not clear for which components "CSIMigrationRBD" feature gate is intended: <brIt is not clear for which components "SizeMemoryBackedVolumes" feature gate is intended. <brThe description of "nodeExpandSecretRef" field does not start with a new line in the list. <brThe double word "node".
/language en
/assign RakshitKumar04
Let's stop mentioning in You can specify feature gates for all Kubernetes components (some might be no-ops). We could document that, but it'd be better to track that change as a separate issue. Let's remove the double use of node Let's fix the formatting for these are useful things to point out. Thank you! If you find more, you can help further by opening one issue per thing that will need fixing.
/triage accepted
If you prefer to track this as separate issue, whether I should do something extra or not?
If you're willing to file a separate issue about that clarification please do.
I created separate issue , so this issue should be closed after solving everything except point 2.
Hey, should I raise a PR That fixes the following typos here? The description of "nodeExpandSecretRef" field does not start with a new line in the list. The double word "node". For Linux worker nodes, containerized CSI node node plugins are typically deployed as privileged containers.
If it leads to a documentation fix, sure. Sorry, but I don't know enough about the workflow adopted here. I just feel it is my duty to help make the documentation better and I do my best.
Hey, Should I raise a PR correcting the documentation?


Question: apiVersion: rbac.authorization.k8s.io/v1 metadata: name: system:kube-dns-autoscaler <del> labels: addonmanager.kubernetes.io/mode: Reconcile </del> subjects: - kind: ServiceAccount name: kube-dns-autoscaler

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: mentions an annotation prefix that is deprecated / not actually official. Proposed Solution: Remove all mention of annotations from that page. Page to Update: and specifically Additional Information: This is a follow-up to /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Remove labels from ”Autoscale the DNS Service in a Cluster”
/assign


Question: * See [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core). * See the `imagePullSecrets` field of [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).

This link "" appears to be broken in the line: " <your-registry-serveris your Private Docker Registry FQDN. ( for DockerHub) "
According to , the V1 API has been deprecated.
/triage accepted /assign


Question: ### Container image lifecycle Kubernetes manages the lifecycle of all images through its *image manager*, <del> which is part of the kubelet, with the cooperation of cadvisor. The kubelet </del> <ins> which is part of the kubelet, with the cooperation of {{< glossary_tooltip text="cadvisor" term_id="cadvisor" >}}. The kubelet </ins> considers the following disk usage limits when making garbage collection decisions:

Kubernetes manages the lifecycle of all images through its image manager, which is part of the kubelet, with the cooperation of cadvisor. Needs pop up note on cadvisor
/kind feature /language en I think by pop up note, you're talking about a . Good suggestion, thanks! To fix this, someone should: add a new glossary entry read for context look in copy an existing item to use as a template (make sure to change everything that needs changing) add a glossary tooltip for cadvisor to /help /triage accepted
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 : /kind feature /language en add a new glossary entry /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
/priority backlog


Question: date: 2018-04-12 full_link: /docs/concepts/overview/working-with-objects/labels/ short_description: > <del> ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。 </del> <ins> セレクターを利用すると、ユーザーはラベルに基づいてリソースのリストをフィルタリングできます。 </ins> aka: tags: - fundamental --- <del> ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。 </del> <ins> セレクターを利用すると、ユーザーは{{< glossary_tooltip text="ラベル" term_id="label" >}}に基づいてリソースのリストをフィルタリングできます。 </ins> <!--more-->

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


Question: If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. {{< /note >}} <del> ### Install with PowerShell from PSGallery If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell. 1. Run the installation commands (making sure to specify a `DownloadLocation`): ```powershell Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force install-kubectl.ps1 [-DownloadLocation <path>] ``` {{< note >}} If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory. {{< /note >}} The installer creates `$HOME/.kube` and instructs it to create a config file. 1. Test to ensure the version you installed is up-to-date: ```powershell kubectl version --client ``` {{< note >}} Updating the installation is performed by rerunning the two commands listed in step 1. {{< /note >}} </del> ### Install on Windows using Chocolatey or Scoop 1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer.

This is a Bug Report Since 3/4 days, we are no longer able to deploy kubectl using the install-kubectl script from PSGallery as described in documentation -- <!--Required Information--Problem: script installation --### OK ##[debug]Using the provider 'PowerShellGet' for searching packages. ##[debug]The -Repository parameter was not specified. PowerShellGet will use all of the registered repositories. ##[debug]Getting the provider object for the PackageManagement Provider 'NuGet'. ##[debug]The specified Location is '' and PackageManagementProvider is 'NuGet'. ##[debug]Searching repository '()?id='install-kubectl'' for ''. ##[debug]Total package yield:'1' for the specified package 'install-kubectl'. ##[debug]The installation scope is specified to be 'CurrentUser'. ##[debug]The specified script will be installed in 'C:WindowsServiceProfilesNetworkServiceDocumentsWindowsPowerShellScripts' and its dependent modules will be installed in 'C:WindowsServiceProfilesNetworkServiceDocumentsWindowsPowerShellModules'. ##[debug]The specified Location is 'NuGet' and PackageManagementProvider is 'NuGet'. ##[debug]Downloading script 'install-kubectl' with version '1.7' from the repository ''. ##[debug]Searching repository '()?id='install-kubectl'' for ''. ##[debug]InstallPackage' - name='install-kubectl', version='1.7',destination='C:WindowsServiceProfilesNetworkServiceAppDataLocalTemp' ##[debug]DownloadPackage' - name='install-kubectl', version='1.7',destination='C:WindowsServiceProfilesNetworkServiceAppDataLocalTempinstall-kubectlinstall-', uri='' ##[debug]Downloading ''. ##[debug]Completed downloading ''. ##[debug]Completed downloading 'install-kubectl'. ##[debug]Hash for package 'install-kubectl' does not match hash provided from the server. ##[debug]Script 'install-kubectl' was installed successfully to path install-Script -Name 'install-kubectl' -Scope CurrentUser -Force script execution --### KO ==Getting download link from ==analyzing Downloadlink ==starting Download from using Bitstransfer Cannot validate argument on parameter 'Source'. The argument is null or empty.

Provide an argument that is not null or empty, and then try the command again. detected issue The content of the Uri seems modified few days ago. the script install-kubectl.ps1 is no longer able to get the download link because there is no href matching the executable try { Write-Host -ForegroundColor White "==analyzing Downloadlink" req.Links | where href -Match "").href } catch { Write-Warning "Error Parsing Link" Break } Proposed Solution: Add the necessary href or change the match value <!--Kubernetes Version:--ALL
Honestly, I think that's a bug in the PSGallery script. We can fix this by removing the section The Kubernetes project does not maintain that script. We should remove the link to it. /sig windows
Related, I think is also not something we'd link to based on the .
thanks for mentioning this!
I don't think removing the section is the solution. many customers already have automated kubectl installation using this method according this documentation (including me ^^) Can you put back the "" downloadLink ? req.Links | where href -Match "").href
The documentation for Kubernetes is not a stable API and Kubernetes makes no guarantee about the format of documentation. It's OK if that tool wants to work out a better way to find a download link. In fact, I recommend it. As the Kubernetes project does not maintain that script, we should remove the link to it - it's unhelpful to users to give the impression that that tool is considered secure.
Duplicated by
/triage accepted /priority important-longterm
Change Installation Script Line 29: To: Would resolve this issue. Because download link to is no longer at the previous page.
Package managers are considered out of scope as the Kubernetes org just provides binaries and relies on the community to handle distribution past that. If the documentation here is out of date I think we should remove it to avoid confusion. If someone fixes or creates a new installation script for PSGallery we could easily add it back. I can open a PR - thoughts?
It looks like the was just grabbing a link with from the docs. Definitely not a reliable way to handle installation.

If anyone wants to make a new script it should rely on something like or better yet use to grab or
:+1: If, later, there's a replacement script, it'd be even better for that tool to live in-project. Inside perhaps?
Thanks for taking care of this. would be a good place so it can be updated by sig-windows members


Question: ### Installer le binaire kubectl avec curl sur Windows <del> 1. Téléchargez la dernière version {{< param "fullversion" >}} depuis [ce lien](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). </del> <ins> 1. Téléchargez la dernière version {{< skew currentPatchVersion >}} depuis [ce lien](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe). </ins> Ou si vous avez `curl` installé, utilisez cette commande: ``` <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe </ins> ``` Pour connaître la dernière version stable (par exemple, en scripting), jetez un coup d'oeil à [https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt).

This is a Bug Report Problem: The param is deprecated. Proposed Solution: Replace the shortcode (French pages), for example with when possible and append when needed. Part of /language fr /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question:
 Buy your ticket now! 19 - 22 March | Paris, France   - name: KubeCon 2024 China startTime: 2024-07-26T00:00:00  #Added in https://github.com/kubernetes/website/pull/46431 endTime: 2024-08-23T18:00:00 style: >- background: linear-gradient(90deg, rgba(229,64,216,1) 60%, rgba(0,212,255,1) 100%); color: #fffff; title: |  KubeCon + CloudNativeCon + Open Source Summit China 2024 message: | Join us for three days of incredible opportunities to collaborate, learn and share with the cloud native community.
  Buy your ticket now! 21 - 23 August | Hong Kong

This is a Feature Request What would you like to be Set a banner to announce KubeCon 2024 China Why is this needed We usually turn on a banner for the upcoming KubeCon about 4 weeks ahead of the event. for EU and NA, we did several times for 4 or 5 weeks. the first time for KubeCon China is the 2021 virtual KubeCon China, we have the banner for 2 weeks. 2-4 weeks are OK for me. Logos are not available yet: Also see the config from a previous year's KubeCon(KubeCon China 2021 for 2 weeks). Comments This change will need approval. I would like to set the banner to start on the July 26th, 2024 and to end on the August 23, 2024 at 1800 CST (UTC+8).
/committee steering /triage accepted
I can help with this. I helped with last Kubecon EU banner too. /assign
Ping , if you are busy, I would like to take this job :)
PR to add banner as requested (Sorry for the delay! I was waiting for the logo to be available)


Question: {{< /caution >}} 1.  Apply the CNI plugin of your choice: <del> [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable. </del> <ins> [Follow these instructions](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#pod-network) to install the CNI provider. Make sure the configuration corresponds to the Pod CIDR specified in the kubeadm configuration file if applicable. </ins> In this example we are using Weave Net:

This is a Bug Report Formatting is off (broken HTML rendering) on page since earlier this week (Wednesday sometime?) per my comment in - I'm adding as a separate ticket for tracking. Some fixes to Hugo were made in and but the issues on this page are persisting. Problem: Seeing poor formatting and plaintext HTML due to some incorrect syntax on the page: ! - screenshot taken in FireFox, but replicated in Chromium (Brave) as well. Page to Update: Thank you! [EDIT] heh - I switched GitHub accounts - the comments I was referring to were by my other account
thanks for the report. cc possibly caused by the hugo bump too? /sig docs cluster-lifecycle /kind bug
Relates to tracking issue
This is almost fixed. There are some leftovers related to the ordered list. /assign


Question: path: /docs/getting-started-guides/ovirt/ - title: OpenStack Heat path: /docs/getting-started-guides/openstack-heat/ <del> - title: CoreOS on Multinode Cluster path: /docs/getting-started-guides/coreos/coreos_multinode_cluster/ </del> - title: rkt section: - title: Running Kubernetes with rkt

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: