Question: <ins> <div class="col-sm-6 col-md-6 col-lg-6 mx-auto py-3"> {{partial "search-input" .}} </div> </ins>  No newline at end of file

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


Question: * Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) to understand your options for an alternative. <del> * There is a [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917) to track the discussion about the deprecation and removal of dockershim. </del> * If you find a defect or other technical concern relating to migrating away from dockershim, you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose) to the Kubernetes project.

/kind feature /sig node docs for the flag pod-infra-container-image as dockershim is removed (also tracked here: ) how to transition from using this flag to Contained setting when migrating off dockershim Also see
/sig docs
/triage accepted
I'm not quite sure what needs to happen with this issue specifically. Is the umbrella issue going to cover this? What needs to change in relation to this issue?
Can you please describe more?
similar to this: The flag is deprecated. On migration - users needs to stop using this flag and instead configure the container runtime with the proper configuration setting. For containerd it is a
/milestone 1.24
Users should stop using the flag only when using a container runtime that supports image pinning. At the moment there's work being done on the containerd side. Other CRIs only have issues created for implementing image pining:
The current situation is that you end up with two (or more) versions of pod-infra-container: Depending on the actual versions of kubernetes and the container runtime being involved.
The pod-infra-container-image flag is only mentioned in two files currently. The one in reference docs will go away when reference docs are rebuilt for 1.24. The mention in will be removed in PR to be named later. If there are new feature to replace image pining for other runtimes, please create a new issue.
removes the option. So we should close this issue once that PR merges.
The dockershim work is ongoing, but as 1.24 is releasing today, i'm clearing the milestone. /milestone clear
The final instance of --pod-infra-container-image was removed with . /close
Closing this issue. <detailsIn response to : The final instance of --pod-infra-container-image was removed with . /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
/reopen this bug was suggesting to add a note to dockershim migration document to suggest customers what to replace this flag with on migration off dockershim. See comment This document will benefit from this instruction: This is one of the flags, other flags not documented in the migration document and causing confusion (see report: ):
Reopened this issue.

<detailsIn response to : /reopen This is one of the flags, other flags not documented in the migration document and causing confusion (see report: ): 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
For cri-dockerd, it is called :-) Eventually it will also be possible to set using configuration files: But I believe the current status (editing flags in systemd unit) is documented properly, on the container runtime page.
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]:
/remove-lifecycle rotten
Would it be appropriate to link right before starts? We could add a line asking our audience to refer to the linked guide to understand how to get Kubelet working with containerd. If that doesn't work, where else would you recommend placing it?

This is a Feature Request Port this: to the migration guide documentation: as a known issue. Note, CRI-O behavior may be different.
/sig node
/language en
Is the ask here to port the Google doc into the Kubernetes docs or just link to the Google documentation (which isn't necessarily allowed)?
We can't really do either, unless Google licenses to the CNCF. We could write new docs to highlight the same known issue (what's the issue? - I deliberated haven't looked).
Here is the GH issue: These metrics are missing in endpoint with Containerd (they were present with Dockershim): Also the format of container name dimension of many metrics was with dockershim, but the format on the containerd node is . This is coming from this file: that even has an internesting note that this is implementaiton details, but changing it will likely break somethings (btw, maybe this may be noted as well in the list of known issues). So workaround for both issues (missing metrics and the name of metric dimension) is to use a standalone cAdvisor, and use one of the releases with the suffix "-containerd-cri"
That sounds quite involved - should we open a related issue to track explaining how folks would do that?
Do we have a document that can be followed for using a standalone cadvisor? I checked the tags in cadvisor and turns out 2 versions have containerd as suffix but none have the "-containerd-cri" suffix. Ex: v0.41.0-containerd-fix-rc.2 Does the latest version v0.44.0 contain the fix?
can you please help here?
The fix was in I think but not sure which releases contain it
So what do we need to do next, Align versions?
/assign
Yeah I'm not sure how to tell which version has the changes. It's for sure in 0.43.x but the current "Latest" tag is 0.39.x and doesn't seem to have the fix. I think we should wait for or to verify.
It looks like updates the page's docker-specific information related to cAdvisor to be more generic to container runtimes. Would that be enough to address this issue or does more runtime-specific information need to be ?
what's your opinion in respect of ?

It's due to it being reverted in which is a real bummer for those of us using GKE and the default for new node pools is containerd.
/triage accepted
What should the next steps on this issue look like?
my thoughts: This doesn't belong on the suggested page because it's specific to containerd. I'd say let's update as follows: In Before you begin, add a line to "Read the known issues section" Add a section at the end, before What's Next, called "Known issues after migrating" Add "Versions of containerd prior to 0.45.0 didn't collect some metrics in the endpoint. For a list of missing metrics, refer to . To collect these metrics, install a containerd package that is version 0.45.0 or later that has the suffix." In , mention "To avoid the missing metrics in [Known issues after migrating](#known-issues-after-migrating), install a containerd package that is version 0.45.0 or later that has the suffix."
According to the comment at the only current work-around for containerd users is to deploy and scrape a standalone cadvisor daemonset, built from the branch. The stats exposed by the kubelet will be broken until 1.25 or 1.26 when is complete. Since it is the kubelet's cadvisor that is broken (and I would argue that it is broken/regressed by this issue), it should be covered in the kubernetes docs.
Is there a more involved process then than just installing the package?
it's not a package, it's a branch of the cadvisor project: I'm not sure if they're publishing binaries or images from that branch. A sample DaemonSet is available, which could be modified to use :
Could we say: "To collect these metrics, . Set the $VERSION variable to any cAdvisor version that has the suffix, such as " ?
I think that needs more work, for example the default DaemonSet only mounts the docker socket path; it does not mount the containerd socket, and even when I modify it to do so the metrics appear to be missing most of the important labels. Perhaps has some suggestions.

This feels like it would need to be its own task page, possibly linked from our existing Metrics doc as well
I've put a ready to run temporary solution here
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


Question: [context.master] # This context is triggered by the `master` branch and allows search indexing <del> # DO NOT REMOVE THIS (contact @chenopis or @sig-docs-maintainers) </del> <ins> # DO NOT REMOVE THIS (contact @kubernetes/sig-docs-leads) </ins> publish = "public" command = "make production-build"

The  group in OWNERSALIASES is a historical artifact with no permissions associated with it. Remove the team from OWNERS_ALIASES. I'm also proposing to update the description of from "Website admins" to "Website chairs and tech leads" and add and to the group. For more information, see We need to update the to replace with I propose continuing to limit repo admin access to current chairs. /assign


Question: # Defined below are the security contacts for this repo. # <del> # They are the contact point for the Product Security Committee to reach out </del> <ins> # They are the contact point for the Security Response Committee to reach out </ins> # to for triaging and handling of incoming issues. # # The below names agree to abide by the

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 change We should find the term “product security committee” anywhere within the English-language docs, and replace that term with “security response committee”. We don't need to revise any blog articles. If we feel there are some blog articles where an exception is justified, I'd revise those in a separate PR per article as the review process is different. Why is this needed renamed the product security committee to “Security Response Committee” Comments /language en /sig docs /sig security /help /triage accepted Relevant to
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 Feature Request <!-- See for guidance on writing an actionable issue description. --We should find the term “product security committee” anywhere within the English-language docs, and replace that term with “security response committee”. We don't need to revise any blog articles. If we feel there are some blog articles where an exception is justified, I'd revise those in a separate PR per article as the review process is different. renamed the product security committee to “Security Response Committee” /language en /sig docs /sig security /help /triage accepted Relevant to 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
thanks , PR's are incoming org wide for the change.
Hi, I would like to take this up /assign


Question: - [RBAC Good Practices](/docs/concepts/security/rbac-good-practices/) for further information on authorization. <ins> - [Securing a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/) for information on protecting a cluster from accidental or malicious access. </ins> - [Cluster Multi-tenancy guide](/docs/concepts/security/multi-tenancy/) for configuration options recommendations and best practices on multi-tenancy. - [Blog post "A Closer Look at NSA/CISA Kubernetes Hardening Guidance"](/blog/2021/10/05/nsa-cisa-kubernetes-hardening-guidance/#building-secure-container-images)

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --We have two pages with similar aims: We should ensure that the advice in the two documents is aligned, and also make sure that the two documents link to each other. Why is this needed It's a bad idea to document multiple ways to make sure that your cluster is secure, unless those are well aligned. Comments /sig security /sig docs /language en
Relevant to
Regarding this: We can use a reference section/note/what's next section in the end of stating: -
/triage accepted
Hey I would like to work on this.
/assign


Question: * [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs. <del> * [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls. </del> <ins> * [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls. </ins> * AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`.

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


Question: ## Introduction This document describes how to build a high-availability (HA) Kubernetes cluster.  This is a fairly advanced topic. <del> Users who merely want to experiment with Kubernetes are encouraged to use configurations that are simpler to set up such as the simple [Docker based single node cluster instructions](/docs/getting-started-guides/docker), </del> <ins> Users who merely want to experiment with Kubernetes are encouraged to use configurations that are simpler to set up such as [Minikube](/docs/getting-started-guides/minikube/) </ins> or try [Google Container Engine](https://cloud.google.com/container-engine/) for hosted Kubernetes. Also, at this time high availability support for Kubernetes is not continuously tested in our end-to-end (e2e) testing.  We will

This is a... [ X ] Bug Report Problem: The for the Docker based single node cluster instructions is outdated Proposed Solution: fix the link: Page to Update:


Question: ``` ロードバランサーをサポートするクラウドプロバイダーでは、Serviceにアクセスするための外部IPアドレスが提供されます。 <del> Minikube では、`LoadBalancer`タイプは`minikube service`コマンドを使用した接続可能なServiceを作成します。 </del> <ins> minikube では、`LoadBalancer`タイプは`minikube service`コマンドを使用した接続可能なServiceを作成します。 </ins> 3. 次のコマンドを実行します:

This is a Feature Request In the documentation available in , as well as in the link, the term is written as . I'd like to suggest updating it to to align with the and . <!-- 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 occurrences of to . Why is this needed Using the incorrect casing can be misleading, especially for newcomers. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --
/assign
/language ja
/triage accepted


On the Kubernetes case studies page (), certain company icons are not visible. !
/retitle Some company logos not rendering on "Case Studies" page /kind bug
I would like to fix this. /assign
We should investigate and fix this. /priority backlog /triage accepted
/area web-development


Question: ## {{% heading "whatsnext" %}} <del> [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) has instructions on running and managing the cloud controller manager. To upgrade a HA control plane to use the cloud controller manager, see [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/). Want to know how to implement your own cloud controller manager, or extend an existing project? The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.26/cloud.go#L43-L69) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider). The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface. For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). </del> <ins> * [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) has instructions on running and managing the cloud controller manager. * To upgrade a HA control plane to use the cloud controller manager, see [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/). * Want to know how to implement your own cloud controller manager, or extend an existing project? - The cloud controller manager uses Go interfaces, specifically, `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider) to allow implementations from any cloud to be plugged in. - The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface. - For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). </ins>  No newline at end of file

This is a Bug Report <!--Required Information--Problem: Thesection in the cloud- is not in right format. Given as:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en /sig docs /assign
the content seems confusing as it does not mention how to implement your own cloud controller manager, or extend an existing project? We can add more references or change the wording to direct links and briefly explain their cause. I'd like to hear what the community think about this.
Raised a for the obvious change. I'll be open to make further changes if anyone has input regarding the content of section mentioned
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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 as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale


Question: ### Upgrade kubelet and kubectl <del> 1.  Upgrade the kubelet and kubectl on all worker nodes: </del> <ins> -  Upgrade the kubelet and kubectl on all worker nodes: </ins> <del> {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </del> <ins> {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </ins> # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubelet kubectl &&  apt-get update && apt-get install -y kubelet=1.18.x-00 kubectl=1.18.x-00 &&  apt-mark hold kubelet kubectl <ins> - </ins> # since apt-get version 1.1 you can also use the following method apt-get update &&  apt-get install -y --allow-change-held-packages kubelet=1.18.x-00 kubectl=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </ins> # replace x in 1.18.x-0 with the latest patch version yum install -y kubelet-1.18.x-0 kubectl-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> <del> 1.  Restart the kubelet </del> <ins> -  Restart the kubelet </ins> ```shell sudo systemctl restart kubelet

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--indentation issue Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--18 <!--Additional Information:--fix the page indentation
/sig cluster-lifecycle docs hi, can you show which section you think is wrong or maybe provide a screenshot?
/sig cluster-lifecycle docs Attached screenshots
i don't see the attachments, possibly because you replied via email. try adding them using the GitHub web UI.
! ! ! !
Page alignment or indentation not proper looks.
ok, i can confirm this. hi, was this broken by this PR, or maybe something on the hugo side changed recently?
The Hugo upgrade was PR
/kind bug /priority important-longterm
I've tried to make a work around for this. It looks like tabs shortcodes with code snippets inside them don't play well with shortcodes (see issue ).
I will take a stab at cleaning this up assuming work isn't currently being done. We might have to adjust the page slightly until capture is removed. /assign
I can share some WIP in case it helps
thanks for taking a look and
oof, sorry I saw this after I opened the PR. That does help! I was scratching my head on some of these bugs. Let me know if you want me to modify my PR to incorporate some of your suggestions or vice versa. I was poking fun of the page on twitter and felt obligated to try to fix it :smile:
Busy at the moment I'm afraid. Feel free to snarf any bits that look useful.


Question: - mikedanese - thockin title: Debug Pods <del> content_type: concept </del> <ins> content_type: task </ins> weight: 10 ---

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 , is broken. Proposed Solution: In , Page to Update: Problem: The of these pages is , but it seems that it should be . 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
/assign
GitHub didn't allow me to assign the following users: PrajwalBorkar. 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 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
already opened 4 days before this issue filed, please take a look.
/assign
Hey are you trying to help with this issue? There is already another PR done this, please take a look at above comments.
The first part is solved by . Sorry for missed the second part of this issue about wrong . Hey would you still like to give a try?


Question: これらの変数に加えて、kubeletは、通常、最も古いものから順に、定義されていない削除されたコンテナをガベージコレクションします。 <del> `MaxPerPodContainer`と`MaxContainer`は、Podごとのコンテナーの最大数(`MaxPerPodContainer`)を保持すると、グローバルなデッドコンテナの許容合計(`MaxContainers`)を超える状況で、互いに競合する可能性があります。 この状況では、kubeletは`MaxPodPerContainer`を調整して競合に対処します。最悪のシナリオは、`MaxPerPodContainer`を1にダウングレードし、最も古いコンテナーを削除することです。 </del> <ins> `MaxPerPodContainer`と`MaxContainers`は、Podごとのコンテナーの最大数(`MaxPerPodContainer`)を保持すると、グローバルなデッドコンテナの許容合計(`MaxContainers`)を超える状況で、互いに競合する可能性があります。 この状況では、kubeletは`MaxPerPodContainer`を調整して競合に対処します。最悪のシナリオは、`MaxPerPodContainer`を1にダウングレードし、最も古いコンテナーを削除することです。 </ins> さらに、削除されたPodが所有するコンテナは、`MinAge`より古くなると削除されます。 {{<note>}}

This is a Feature Request What would you like to be We need to update content/ja/docs/concepts/architecture/garbage- according to the English text, because it is outdated. Why is this needed content/ja/docs/concepts/architecture/garbage- is outdated. A link text to this page from other pages have already been fixed. The current page is still "" and it should be fixed "". Comments /language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: to the kubelet, or set `PodPidsLimit` in the kubelet [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). <del> {{< note >}} Before Kubernetes version 1.20, PID resource limiting for Pods required enabling the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. {{< /note >}} </del> ## PID based eviction You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources.

This is a Bug Report <!--Required Information--From k8s v1.24 the and are no longer available as a feature gate in k8s. From v1.25 there is a separate document that contains information on feature gates that have been removed i.e. . In the and feature gate link to the page which is incorrect, instead of that, it should be page. The information for both feature gates is on the Feature Gates (removed) page not on the Feature Gates page. Proposed Solution: SupportNodePidsLimit and SupportPodPidsLimit feature gates should be linked 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
/kind documentation /assign
For GA'ed feature or deprecated feature, if the gate is removed, we may want to remove the linking texts altogether rather than having existing text pointing to the outdate gate names.
Hi Just want to confirm it: So for this, you want to remove the whole note section for both feature gates, because both feature gates are removed. Am I understanding right?
is it seems good to you?
I meant this: move the "removed" feature to the dedicated page, if this is not done yet. The "removed" features will stay there for the sole purpose of reference. For all texts (including notes) that reference these gates, remove those references. If a feature is deprecated and removed, those texts may well become invalid. If a feature is GA'ed and removed, those texts may be still valid, but the reference to the gate should disappear.
Thanks, for your response.
and both feature gates were graduated in v1.20 and removed in v1.23. Both are present on the dedicated page i.e. . So I will remove the reference to these gates.
I will create PR for it soon.
Fixed it here:


Question: You can use `kubectl patch` to update API objects in place. This command supports JSON patch, JSON merge patch, and strategic merge patch. See <del> [Update API Objects in Place Using kubectl patch](/docs/tasks/run-application/update-api-object-kubectl-patch/) </del> <ins> [Update API Objects in Place Using kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) </ins> and [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch).

This is a Feature Request We have a pretty good doc on various ways to patching an object: However, the current location of the content is wrong. It is not about an application. It is about more generic ways to change an API object. What would you like to be Revise and move the content to object management section so that readers would enjoy playing with the many ways of patching an object.
/assign
/kind cleanup /language en /priority backlog


Question: ### Restricting profiles with the PodSecurityPolicy <ins> {{< note >}} PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. {{< /note >}} </ins> If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:

Page to Update: Kubernetes is deprecating as mentioned . But in the page linked there is not even a mention of PSP being deprecated. Either that section should be removed or a deprecation notice needs to be so that the users wouldn't end following those steps if they are on higher versions.
For anyone's information: In PodSecurityPolicy is being replaced by a new, simplified admission controller. For more details on this change, see . Follow these guidelines to simplify migration from PodSecurityPolicy to the new admission controller: /triage accepted /language en
/assign I would like to work on this.
fixed it here:


Question: ### curlを使用してWindowsへkubectlのバイナリをインストールする <del> 1. [こちらのリンク](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< param "fullversion" >}}をダウンロードしてください。 </del> <ins> 1. [こちらのリンク](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe)から、最新リリースである{{< skew currentPatchVersion >}}をダウンロードしてください。 </ins> または、`curl`をインストールされていれば、次のコマンドも使用できます: ```bash <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> ``` 最新の安定版を入手する際は(たとえばスクリプトで使用する場合)、[https://dl.k8s.io/release/stable.txt](https://dl.k8s.io/release/stable.txt)を参照してください。

Problem: Based on , I have created this issue/task to help update the [ja] language documentation. Proposed Solution: Page to Update: In the branch, I found: Results for "fullversion" in "k8s-website/content/ja" /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/containers/container- 46: IPDNS /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- 146: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- 283: )Service /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- 220: {{< param "fullversion" }}: 223: minikube start --kubernetes-version {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- 34: Linux{{< param "fullversion" }}: 37: curl -LO {{< param "fullversion" }}/bin/linux/amd64/kubectl 116: macOS{{< param "fullversion" }}: 119: curl -LO {{< param "fullversion" }}/bin/darwin/amd64/kubectl 181: {{< 181: "fullversion" }}){{< param "fullversion" }} 186: curl -LO {{< param "fullversion" }} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- 107: Kubernetes{{< param "fullversion" }} 111: releases/latest/download/kube- kubectl apply -f - 150: .PrepareNode.

ps1 -KubernetesVersion {{% param "fullversion" %}} /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- 35: # {{% param "fullversion" %}} 36: -Lo C:k {{% param "fullversion" %}} 70: -Lo C:k {{% param "fullversion" %}} 86: {{< param "fullversion" }}: 89: releases/latest/download/kube- kubectl apply -f - /sig docs /sig localization /language ja cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : Problem: All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: Page to Update: /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services-networking/connect-applications- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/concepts/services- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/setup/learning- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/tools/install- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows- /home/rdlugyhe/kubernetes/k8s-website/content/ja/docs/tasks/administer-cluster/kubeadm/upgrading-windows- /sig localization /language ja cc: 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
cc:
/triage accepted /area localization /priority backlog


Question:
Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the containerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."

ref: Some of the case studies need a bit of rewording to remove unnecessary mention of docker. Note: the case studies are HTML + CSS rather than markdown - you need to be familiar with that in order to update these! I'd reword “Docker containers” to “containers” I'd reword “Dockerize” to “containerize” I'd reword “Docker file” to “Dockerfile” I'd change “just over two years ago” to “in 2015” I'd also change “Dockerized” to “containerized” /priority backlog /triage accepted
Hi there, I would like to work on this issue. /assign
I have an question does the PR need to made against the branch or the branch? Thanks
You need to make a PR against the branch.
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /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
Hi I have opened a regarding this a few days ago. If you are free can you PTAL at the PR. Thanks.
Please close your PR as has already it earlier. Kindly look into those issues which are not already assigned to someone. Thank you.
/assign


Question: cid: docsHome layout: docsportal_home class: gridPage gridPageHome <del> linkTitle: "होम" </del> <ins> linkTitle: "प्रलेखन" </ins> main_menu: true weight: 10 hide_feedback: true

This is a Bug Report While the left hand side navigation menu in Hindi and English is not fully matching and can create some issues for a native hindi reader . <!-- 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 option in English has been changed to in Hindi which can be an issue while navigating for a native Hindi reader. Proposed Solution: I have 2 options, I can change it to or . Suggestions required Page to Update: Screenshot(can be easily compared up) Hindi ! English <img width="960" alt="image" src=""<!--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 hi
/retitle [hi] Navigation menu displays 'Home' instead of 'Documentation'
It appears that there is already an existing (umbrella) issue , addressing this request for all the different langauges. Additionally, there is already a PR raised specifically for the fix in Hindi language.
Marking this as a duplicate. /triage duplicate
if possible assign it to me i can work on it
You don't need an assignment to work on issues, Anybody is welcome to propose a fix Being said that, If someone will/has already proposed a PR, It's polite to co-author with them (but not mandatory)
This issue although addresses same type of issue as in , but in different place. is addressing specifically for footer across all localizations. And in this issue it is for Navigation menu and that too for specifically Hindi localized page. So, i think its better not to consider it a duplicate. For those, who want to work on it. Changing this key-value pair with value can probably fix it. !
Can I plz solve this issue?

I want try do some localization cjhange to deepen my udnerstanding and help languages team where i can :)
/remove-triage duplicate Based on info provided in
Anyone is free to propose a fix by submitting a pull request; you don't require anybody's permission as we operate in the spirit of open source collaboration. Just a friendly reminder, these changes pertain to Hindi localization, so having familiarity with the Hindi language would be advantageous, although it's not mandatory.
Okay got it. Thanks! I will assign to myself in that case. /assign
I have riased plz review and let me know if its okay. Thanks in advance.


Question: {{% capture overview %}} <ins> {{< feature-state for_k8s_version="v1.5" state="beta" >}} </ins> This page shows how to limit the number of concurrent disruptions that your application experiences, allowing for higher availability while permitting the cluster administrator to manage the clusters

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: does not mention that PodDisruptionBudget is beta. Proposed Solution: Add a shortcode to Page to Update: There may well be other pages that describe PodDisruptionBudget without mentioning its feature state. <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.18 <!--Additional Information:--/help /kind bug /priority backlog
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: does not mention that PodDisruptionBudget is beta. Add a shortcode to There may well be other pages that describe PodDisruptionBudget without mentioning its feature state. Kubernetes Version: v1.18 /help /kind bug /priority backlog 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 don't see on this page -
Looks like it is since .
/assign


Question: for more information. --> <del> ### 容器运行时类 {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}} </del> <ins> ### 容器运行时类 {#runtimeclass} {{< feature-state for_k8s_version="v1.16" state="alpha" >}} </ins> [容器运行时类](/docs/concepts/containers/runtime-class/)定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 pod.Spec.Overhead 字段。

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: Page /zh/docs/reference/access-authn-authz/admission-controllers/ display abnormally, these anchor points should start on a new line. Proposed Solution: fix the anchor point format. abnormal format: normal format: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign /language zh


Question: ### はじめに Bashにおけるkubectlの補完スクリプトは`kubectl completion bash`コマンドで生成できます。 <del> シェル内で補完スクリプトをsourceすることでkubectlの自動補完が有効になります。 </del> <ins> 補完スクリプトをシェル内に読み込ませることでkubectlの自動補完が有効になります。 </ins> ただし、補完スクリプトは[**bash-completion**](https://github.com/scop/bash-completion)に依存しているため、事前にインストールしておく必要があります。

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update Why is this needed Reflect the following feedback on this file, too. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/area localization /triage accepted


Question: <ins> apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 </ins>  No newline at end of file

The example Deployment resource is duplicated in (code import shortcode and in-line code)
/language en
/kind bug We should keep the shortcode and drop the inline manifest.
/triage accepted /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /triage accepted /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
we should contain the Service resource following to the Deployment in the as well, right? (or should we create a new file for Service?)
Hey I would like to work on this issue. Do assign me this issue so I can start working on this.
/assign
BTW our convention in SIG Docs is very much that anyone is welcome to start work on an issue, and the best way to indicate that you're starting work is to open a PR (either a draft or the final thing). If anyone else wanted to work on this, please do try to liaise with first.
Thanks for your piece of advice, I will definitely keep this in mind for the next time.
The page to fix is Ah yes. The Service: should go in a new example manifest file and we'll need a second shortcode to cover that. Ideally we also explain how to use to deploy those. For example, for the Deployment, it's
Hey I have linked a PR against this issue, please do review it.
PR is submitted by another first time contributor to address the same problem before this issue was created. I will let other members decide on the best remediation of this situation.

ah sorry, that was my bad, I only searched issues before filing this issue... :bow:
I created PR after I searched both issues and PRs and there was nothing at that time... since this could be my first PR to the repo.
To make PR more likely to be my first contribution to the repo, I have in the beginning, and in addition, a missing step in the middle to get the info of the pods. To promote a bit: PR was created before this issue was created. is and uses the common YAML reference to A single YAML is used so that it can be deleted with a single . A missing step to get the info of the pods is .
Hey i have recently started my journey in open source and want to learn more looking for correct mentorship and guidance. If this issue is not resolved completely in that case can i also work on this??
Hi this issue is already resolved, I've also linked a PR to this issue. You can look for another good-first-issue to get started with.
Hey, anyone working on this, can you assign it to me. /assign
this issue is already resolved. As you can see I've also linked a PR to this issue. You can search for another good-first-issue to get started with.
This issue isn't yet resolved, but at least one reviewable PR is already open with a potential fix.
/assign
/assign
is issuse still open if yes then please assign me with issuse???


Question: <ins> --- layout: blog title: "Kubernetes 1.25 的移除说明和主要变更" date: 2022-08-04 slug: upcoming-changes-in-kubernetes-1-25 --- <!-- layout: blog title: "Kubernetes Removals and Major Changes In 1.25" date: 2022-08-04 slug: upcoming-changes-in-kubernetes-1-25 --> <!-- **Authors**: Kat Cosgrove, Frederico Muñoz, Debabrata Panigrahi --> **作者**：Kat Cosgrove、Frederico Muñoz、Debabrata Panigrahi <!-- As Kubernetes grows and matures, features may be deprecated, removed, or replaced with improvements for the health of the project. Kubernetes v1.25 includes several major changes and one major removal. --> 随着 Kubernetes 成长和日趋成熟，为了此项目的健康发展，某些功能特性可能会被弃用、移除或替换为优化过的功能特性。 Kubernetes v1.25 包括几个主要变更和一个主要移除。 <!-- ## The Kubernetes API Removal and Deprecation process The Kubernetes project has a well-documented [deprecation policy](/docs/reference/using-api/deprecation-policy/) for features. This policy states that stable APIs may only be deprecated when a newer, stable version of that same API is available and that APIs have a minimum lifetime for each stability level. A deprecated API is one that has been marked for removal in a future Kubernetes release; it will continue to function until removal (at least one year from the deprecation), but usage will result in a warning being displayed. Removed APIs are no longer available in the current version, at which point you must migrate to using the replacement. --> ## Kubernetes API 移除和弃用流程 {#the-kubernetes-api-removal-and-deprecation-process} Kubernetes 项目对功能特性有一个文档完备的[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 该策略规定，只有当较新的、稳定的相同 API 可用时，原有的稳定 API 才可能被弃用，每个稳定级别的 API 都有一个最短的生命周期。 弃用的 API 指的是已标记为将在后续发行某个 Kubernetes 版本时移除的 API； 移除之前该 API 将继续发挥作用（从弃用起至少一年时间），但使用时会显示一条警告。 移除的 API 将在当前版本中不再可用，此时你必须迁移以使用替换的 API。 <!-- * Generally available (GA) or stable API versions may be marked as deprecated but must not be removed within a major version of Kubernetes. * Beta or pre-release API versions must be supported for 3 releases after deprecation. * Alpha or experimental API versions may be removed in any release without prior deprecation notice. --> * 正式发布（GA）或稳定的 API 版本可能被标记为已弃用，但只有在 Kubernetes 大版本更新时才会移除。 * 测试版（Beta）或预发布 API 版本在弃用后必须支持 3 个版本。 * Alpha 或实验性 API 版本可能会在任何版本中被移除，恕不另行通知。 <!-- Whether an API is removed as a result of a feature graduating from beta to stable or because that API simply did not succeed, all removals comply with this deprecation policy. Whenever an API is removed, migration options are communicated in the documentation. --> 无论一个 API 是因为某功能特性从 Beta 进入稳定阶段而被移除，还是因为该 API 根本没有成功， 所有移除均遵从上述弃用策略。无论何时移除一个 API，文档中都会列出迁移选项。 <!-- ## A Note About PodSecurityPolicy In Kubernetes v1.25, we will be removing PodSecurityPolicy [after its deprecation in v1.21](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). PodSecurityPolicy has served us honorably, but its complex and often confusing usage necessitated changes, which unfortunately would have been breaking changes. To address this, it is being removed in favor of a replacement, Pod Security Admission, which is graduating to stable in this release as well. If you are currently relying on PodSecurityPolicy, follow the instructions for [migration to Pod Security Admission](/docs/tasks/configure-pod-container/migrate-from-psp/). --> ## 有关 PodSecurityPolicy 的说明 {#a-note-about-podsecuritypolicy} [继 PodSecurityPolicy 在 v1.21 弃用后](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)， Kubernetes v1.25 将移除 PodSecurityPolicy。PodSecurityPolicy 曾光荣地为我们服务， 但由于其复杂和经常令人困惑的使用方式，让大家觉得有必要进行修改，但很遗憾这种修改将会是破坏性的。 为此我们移除了 PodSecurityPolicy，取而代之的是 Pod Security Admission（即 PodSecurity 安全准入控制器）， 后者在本次发行中也进入了稳定阶段。 如果你目前正依赖 PodSecurityPolicy，请遵循指示说明[迁移到 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。 <!-- ## Major Changes for Kubernetes v1.25 Kubernetes v1.25 includes several major changes, in addition to the removal of PodSecurityPolicy. ### [CSI Migration](https://github.com/kubernetes/enhancements/issues/625) The effort to  move the in-tree volume plugins to out-of-tree CSI drivers continues, with the core CSI Migration feature going GA in v1.25. This is an important step towards removing the in-tree volume plugins entirely. --> ## Kubernetes v1.25 的主要变更 {#major-changes-for-kubernetes-v1.25} Kubernetes v1.25 除了移除 PodSecurityPolicy 之外，还包括以下几个主要变更。 ### [CSI Migration](https://github.com/kubernetes/enhancements/issues/625) 将树内卷插件迁移到树外 CSI 驱动的努力还在继续，核心的 CSI Migration 特性在 v1.25 进入 GA 阶段。 对于全面移除树内卷插件而言，这是重要的一步。 <!-- ### Volume Plugin Deprecations and Removals Several volume are being deprecated or removed. [GlusterFS will be deprecated in v1.25](https://github.com/kubernetes/enhancements/issues/3446). While a CSI driver was built for it, it has not been maintained. The possibility of migration to a compatible CSI driver [was discussed](https://github.com/kubernetes/kubernetes/issues/100897), but a decision was ultimately made to begin the deprecation of the GlusterFS plugin from in-tree drivers. The [Portworx in-tree volume plugin](https://github.com/kubernetes/enhancements/issues/2589) is also being deprecated with this release. The Flocker, Quobyte, and StorageOS in-tree volume plugins are being removed. --> ### 卷插件弃用和移除 {#volume-plugin-deprecation-and-removals} 若干卷将被弃用或移除。 [GlusterFS 将在 v1.25](https://github.com/kubernetes/enhancements/issues/3446) 中被弃用。 虽然为其构建了 CSI 驱动，但未曾得到维护。 社区[曾讨论](https://github.com/kubernetes/kubernetes/issues/100897)迁移到一个兼容 CSI 驱动的可能性， 但最终决定开始从树内驱动中弃用 GlusterFS 插件。 本次发行还会弃用 [Portworx 树内卷插件](https://github.com/kubernetes/enhancements/issues/2589)。 Flocker、Quobyte 和 StorageOS 树内卷插件将被移除。 <!-- ### [Declare Unsupported vSphere Versions](https://github.com/kubernetes/kubernetes/pull/111255) From Kubernetes v1.25, the in-tree vSphere volume driver will not support any vSphere release before 7.0u2. Check the v1.25 detailed release notes for more advice on how to handle this. --> ### [声明不支持的 vSphere 版本](https://github.com/kubernetes/kubernetes/pull/111255) 从 Kubernetes v1.25 开始，树内 vSphere 卷驱动将不支持任何早于 7.0u2 的 vSphere 版本。 查阅 v1.25 详细发行说明，了解如何处理这种状况的更多建议。 <!-- ### [Signing Release Artifacts](https://github.com/kubernetes/enhancements/issues/3031) An additional step in improving the security posture of the release process, the signing of Kubernetes release artifacts will graduate to Beta in this release. This is in line with the proposed enhancement of targeting SLSA Level 3 compliance for the Kubernetes release process. --> ### [签署发行工件](https://github.com/kubernetes/enhancements/issues/3031) 作为改善发行过程安全状况的附加步骤，Kubernetes 发行工件的签署将在本次发行中进入 Beta 阶段。 这与提议的加强 Kubernetes 发行流程的 SLSA 3 级合规性的目标相一致。 <!-- ### [Support for cgroup v2 Graduating to Stable](https://github.com/kubernetes/enhancements/issues/2254) The new kernel cgroups v2 API was declared stable more than two years ago, and in this release we're taking solid steps towards full adoption of it. While cgroup v1 will continue to be supported, this change makes us ready to deal with the eventual deprecation of cgroup v1 and its replacement by cgroup v2. --> ### [对 cgroup v2 的支持进入稳定阶段](https://github.com/kubernetes/enhancements/issues/2254) 新的内核 cgroups v2 API 在两年多前就被宣布进入稳定阶段。 在本次发行中，我们又为全面采用此 API 迈出了坚实的步伐。 虽然还会继续支持 cgroup v1，但这一变更使我们准备好应对 cgroup v1 的最终弃用并被 cgroup v2 取代。 <!-- ### [Cleaning up IPTables Chain Ownership](https://github.com/kubernetes/enhancements/issues/3178) From the Kubernetes 1.25 release, the iptables chains created by Kubernetes will only support for internal Kubernetes use cases. Starting with v1.25, the Kubelet will gradually move towards not creating the following iptables chains in the `nat` table: --> ### [清理 IPTables 链的所有权](https://github.com/kubernetes/enhancements/issues/3178) 从 Kubernetes 1.25 版本开始，Kubernetes 创建的 iptables 链将仅支持 Kubernetes 内部的使用场景。 从 v1.25 开始，Kubelet 将逐渐迁移为不在 `nat` 表中创建以下 iptables 链： - `KUBE-MARK-DROP` - `KUBE-MARK-MASQ` - `KUBE-POSTROUTING` <!-- This change will be phased in via the `IPTablesCleanup` feature gate. --> 此项变更将通过 `IPTablesCleanup` 特性门控分阶段完成。 <!-- ## Looking ahead The official [list of API removals planned for Kubernetes 1.26](/docs/reference/using-api/deprecation-guide/#v1-26) is: * The beta FlowSchema and PriorityLevelConfiguration APIs (flowcontrol.apiserver.k8s.io/v1beta1) * The beta HorizontalPodAutoscaler API (autoscaling/v2beta2) --> ## 展望未来 {#looking-ahead} [Kubernetes 1.26 计划移除的 API 的正式列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-26)为： * Beta 版 FlowSchema 和 PriorityLevelConfiguration API（flowcontrol.apiserver.k8s.io/v1beta1） * Beta 版 HorizontalPodAutoscaler API（autoscaling/v2beta2） <!-- ### Want to know more? Deprecations are announced in the Kubernetes release notes. You can see the announcements of pending deprecations in the release notes for: --> ### 了解更多 {#want-to-know-more} Kubernetes 发行说明公布了弃用信息。你可以在以下版本的发行说明中查看待弃用特性的公告： <!-- * [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation) * [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation) * [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation) * [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) * We will formally announce the deprecations that come with [Kubernetes 1.25](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#deprecation) as part of the CHANGELOG for that release. --> * [Kubernetes 1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation) * [Kubernetes 1.22](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#deprecation) * [Kubernetes 1.23](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#deprecation) * [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) * 我们将正式宣布 [Kubernetes 1.25](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#deprecation) 的弃用信息，作为该版本 CHANGELOG 的一部分。 <!-- For information on the process of deprecation and removal, check out the official Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) document. --> 有关弃用和移除流程的信息，请查阅 Kubernetes 官方[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)文档。 </ins>

This is a Feature Request Will localize this blog: Why is this needed Missing zh-cn text
/assign
/language zh
/triage accepted


Question:
 --- title: Update API Objects in Place Using kubectl patch description: Use kubectl patch to update Kubernetes API objects in place. Do a strategic merge patch or a JSON merge patch. content_template: templates/task weight: 50 --- {{% capture overview %}} This task shows how to use `kubectl patch` to update an API object in place. The exercises in this task demonstrate a strategic merge patch and a JSON merge patch. {{% /capture %}} {{% capture prerequisites %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{% /capture %}} {{% capture steps %}} ## Use a strategic merge patch to update a Deployment Here's the configuration file for a Deployment that has two replicas. Each replica is a Pod that has one container: {{< codenew file="application/deployment-patch.yaml" >}} Create the Deployment: ```shell kubectl apply -f https://k8s.io/examples/application/deployment-patch.yaml ``` View the Pods associated with your Deployment: ```shell kubectl get pods ``` The output shows that the Deployment has two Pods. The `1/1` indicates that each Pod has one container: ``` NAME                        READY     STATUS    RESTARTS   AGE patch-demo-28633765-670qr   1/1       Running   0          23s patch-demo-28633765-j5qs3   1/1       Running   0          23s ``` Make a note of the names of the running Pods. Later, you will see that these Pods get terminated and replaced by new ones. At this point, each Pod has one Container that runs the nginx image. Now suppose you want each Pod to have two containers: one that runs nginx and one that runs redis. Create a file named `patch-file.yaml` that has this content: ```yaml spec: template: spec: containers: - name: patch-demo-ctr-2 image: redis ``` Patch your Deployment: {{< tabs name="kubectl_patch_example" >}} {{{< tab name="Bash" codelang="bash" >}} kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} kubectl patch deployment patch-demo --patch $(Get-Content patch-file.yaml -Raw) {{< /tab >}}} {{< /tabs >}} View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The output shows that the PodSpec in the Deployment has two Containers: ```shell containers: - image: redis imagePullPolicy: Always name: patch-demo-ctr-2 ... - image: nginx imagePullPolicy: Always name: patch-demo-ctr ... ``` View the Pods associated with your patched Deployment: ```shell kubectl get pods ``` The output shows that the running Pods have different names from the Pods that were running previously. The Deployment terminated the old Pods and created two new Pods that comply with the updated Deployment spec. The `2/2` indicates that each Pod has two Containers: ``` NAME                          READY     STATUS    RESTARTS   AGE patch-demo-1081991389-2wrn5   2/2       Running   0          1m patch-demo-1081991389-jmg7b   2/2       Running   0          1m ``` Take a closer look at one of the patch-demo Pods: ```shell kubectl get pod <your-pod-name> --output yaml ``` The output shows that the Pod has two Containers: one running nginx and one running redis: ``` containers: - image: redis ... - image: nginx ... ``` ### Notes on the strategic merge patch The patch you did in the preceding exercise is called a *strategic merge patch*. Notice that the patch did not replace the `containers` list. Instead it added a new Container to the list. In other words, the list in the patch was merged with the existing list. This is not always what happens when you use a strategic merge patch on a list. In some cases, the list is replaced, not merged. With a strategic merge patch, a list is either replaced or merged depending on its patch strategy. The patch strategy is specified by the value of the `patchStrategy` key in a field tag in the Kubernetes source code. For example, the `Containers` field of `PodSpec` struct has a `patchStrategy` of `merge`: ```go type PodSpec struct { ... Containers []Container `json:"containers" patchStrategy:"merge" patchMergeKey:"name" ...` ``` You can also see the patch strategy in the [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json): ```json "io.k8s.api.core.v1.PodSpec": { ... "containers": { "description": "List of containers belonging to the pod. ... }, "x-kubernetes-patch-merge-key": "name", "x-kubernetes-patch-strategy": "merge" }, ``` And you can see the patch strategy in the [Kubernetes API documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). Create a file named `patch-file-tolerations.yaml` that has this content: ```yaml spec: template: spec: tolerations: - effect: NoSchedule key: disktype value: ssd ``` Patch your Deployment: ```shell kubectl patch deployment patch-demo --patch "$(cat patch-file-tolerations.yaml)" ``` View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The output shows that the PodSpec in the Deployment has only one Toleration: ```shell tolerations: - effect: NoSchedule key: disktype value: ssd ``` Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because the Tolerations field of PodSpec does not have a `patchStrategy` key in its field tag. So the strategic merge patch uses the default patch strategy, which is `replace`. ```go type PodSpec struct { ... Tolerations []Toleration `json:"tolerations,omitempty" protobuf:"bytes,22,opt,name=tolerations"` ``` ## Use a JSON merge patch to update a Deployment A strategic merge patch is different from a [JSON merge patch](https://tools.ietf.org/html/rfc7386). With a JSON merge patch, if you want to update a list, you have to specify the entire new list. And the new list completely replaces the existing list. The `kubectl patch` command has a `type` parameter that you can set to one of these values:

Parameter value	Merge type

json	JSON Patch, RFC 6902

merge	JSON Merge Patch, RFC 7386

strategic	Strategic merge patch

 For a comparison of JSON patch and JSON merge patch, see [JSON Patch and JSON Merge Patch](http://erosb.github.io/post/json-patch-vs-merge-patch/). The default value for the `type` parameter is `strategic`. So in the preceding exercise, you did a strategic merge patch. Next, do a JSON merge patch on your same Deployment. Create a file named `patch-file-2.yaml` that has this content: ```yaml spec: template: spec: containers: - name: patch-demo-ctr-3 image: gcr.io/google-samples/node-hello:1.0 ``` In your patch command, set `type` to `merge`: ```shell kubectl patch deployment patch-demo --type merge --patch "$(cat patch-file-2.yaml)" ``` View the patched Deployment: ```shell kubectl get deployment patch-demo --output yaml ``` The `containers` list that you specified in the patch has only one Container. The output shows that your list of one Container replaced the existing `containers` list. ```shell spec: containers: - image: gcr.io/google-samples/node-hello:1.0 ... name: patch-demo-ctr-3 ``` List the running Pods: ```shell kubectl get pods ``` In the output, you can see that the existing Pods were terminated, and new Pods were created. The `1/1` indicates that each new Pod is running only one Container. ```shell NAME                          READY     STATUS    RESTARTS   AGE patch-demo-1307768864-69308   1/1       Running   0          1m patch-demo-1307768864-c86dc   1/1       Running   0          1m ``` ## Alternate forms of the kubectl patch command The `kubectl patch` command takes YAML or JSON. It can take the patch as a file or directly on the command line. Create a file named `patch-file.json` that has this content: ```json { "spec": { "template": { "spec": { "containers": [ { "name": "patch-demo-ctr-2", "image": "redis" } ] } } } } ``` The following commands are equivalent: ```shell kubectl patch deployment patch-demo --patch "$(cat patch-file.yaml)" kubectl patch deployment patch-demo --patch 'spec:n template:n  spec:n   containers:n   - name: patch-demo-ctr-2n     image: redis' kubectl patch deployment patch-demo --patch "$(cat patch-file.json)" kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"containers": [{"name": "patch-demo-ctr-2","image": "redis"}]}}}}' ``` ## Summary In this exercise, you used `kubectl patch` to change the live configuration of a Deployment object. You did not change the configuration file that you originally used to create the Deployment object. Other commands for updating API objects include [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate), [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit), [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands/#replace), [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale), and [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands/#apply). {{% /capture %}} {{% capture whatsnext %}} * [Kubernetes Object Management](/docs/concepts/overview/working-with-objects/object-management/) * [Managing Kubernetes Objects Using Imperative Commands](/docs/tasks/manage-kubernetes-objects/imperative-command/) * [Imperative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/imperative-config/) * [Declarative Management of Kubernetes Objects Using Configuration Files](/docs/tasks/manage-kubernetes-objects/declarative-config/) {{% /capture %}}

This is a Feature Request We have a pretty good doc on various ways to patching an object: However, the current location of the content is wrong. It is not about an application. It is about more generic ways to change an API object. What would you like to be Revise and move the content to object management section so that readers would enjoy playing with the many ways of patching an object.
/assign
/kind cleanup /language en /priority backlog


Question: The response should be similar to this: ``` <del> NAME       TYPE        CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE frontend   ClusterIP   10.51.242.136   109.197.92.229     80:32372/TCP   1m </del> <ins> NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)        AGE frontend   LoadBalancer   10.51.242.136   109.197.92.229     80:32372/TCP   1m </ins> ``` 1. Copy the external IP address, and load the page in your browser to view your guestbook.

4 ordered lists have wrong indexes. For example, the number below should be 3. ! Page to update: /language en /kind cleanup
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


Question: I instrumented the [example webhook](https://github.com/kubernetes-sigs/controller-runtime/tree/master/examples/builtins) with OpenTelemetry (I had to [patch](https://github.com/dashpole/controller-runtime/commit/85fdda7ba03dd2c22ef62c1a3dbdf5aa651f90da) controller-runtime, but it makes a neat demo), and routed traces to Jaeger as well.  I collected traces like this one: <del> <img width="1440" alt="Jaeger screenshot showing API server, admission webhook, and etcd trace" src="https://user-images.githubusercontent.com/3262098/128613167-e7a14cdf-5635-422f-9fd8-f32744ce639d.png"> </del> <ins> ![Jaeger screenshot showing API server, admission webhook, and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-2.png "Jaeger screenshot showing API server, admission webhook, and etcd trace") </ins> Compared with the previous trace, there are two new spans: A teal span from the API Server making a request to the admission webhook, and a brown span from the admission webhook serving the request.  Even if you didn't instrument your webhook, you would still get the span from the API Server making the request to the webhook.

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: adds a blog article but the images are not hosted within ; they should be. Proposed Solution: Create a PR that adds those images (see other articles that use images for examples) into this repo, and change the article's Markdown source to use them. It might be easiest to make a directory for the article, again following how other articles do it. Page to Update: (after the 3rd of September 2021). It's OK to fix it now. Additional Information: /language en /area blog /kind cleanup /priority important-soon
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
/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 : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi, I would like to take this up /assign


Question: kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' # List Names of Pods that belong to Particular RC <del> # "jq" command useful for transformations that are too complex for jsonpath, it can be found at https://stedolan.github.io/jq/ </del> <ins> # "jq" command useful for transformations that are too complex for jsonpath, it can be found at https://jqlang.github.io/jq/ </ins> sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "(.key)=(.value),"')%?} echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

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 download page for is now (previously ) Proposed Solution: Throughout the English pages, replace the old download URL with the new one. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /priority backlog /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Bug Report <!-- See for guidance on writing an actionable issue description. --Problem: The download page for is now (previously ) Throughout the English pages, replace the old download URL with the new one. <!--Kubernetes Version:--/language en /priority backlog /triage accepted /help </details
I want to help with this. /assign
Hello I would like to work on this issue are you working on the issue?
I have riasd PR to help with this issue.


Question: ### Differences from regular containers Init containers support all the fields and features of app containers, <del> including resource limits, volumes, and security settings. However, the </del> <ins> including resource limits, [volumes](/docs/concepts/storage/volumes/), and security settings. However, the </ins> resource requests and limits for an init container are handled differently, as documented in [Resources](#resources).

This is a Bug Report Problem: section of page does not cover all required reference points which are mentioned throughout page. Proposed Solution: Add references of below topics under what's next section of page. learn about service, volume. kubelet, kubectl overview. Garbage Collection that Kubernetes uses to clean up cluster resources. Types of probes. Liveness, Readiness and Startup Probes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/sig docs /language en /assign
/remove-kind bug /triage accepted I'm not sure how much we need to tell people about Services and Volumes; maybe we should instead signpost readers to learn more about Pods in general - perhaps links to specific fragments of relevant Pod pages? Same for garbage collection really.
Thanks for reply. In that case i will add one link in general to know more about pods and service under What's next section. For garbage collection its already available under what's next section. So i will not add reference link inside page.
Oops! it was my mistake, there is no reference link provided for under what's next section. will add this too.
Hi , Below, i prepared the preview changes what i am planning to do as per my understanding based your comment above. I would like to confirm is these changes you were expecting to do for this issue. ! Please suggest.
Hi Could you please confirm on above comment.
Hi Could you please take a look on Hi Please confirm if these changes sounds good to you. So that i can go ahead and work on it, Thanks.
When adding links, please use links that have words like “volumes”; readers don't need to see the URL. If you send in a pull request we can offer feedback on it directly. Ideally we can accept it as is!
Thanks for your response, i will soon open a PR for it.
Fixed it here .


Question: ![Services overview diagram for iptables proxy](/images/docs/services-iptables-overview.svg) <ins> ### Proxy-mode: ipvs[alpha] **Warning:** This is an alpha feature and not recommended for production clusters yet. In this mode, kube-proxy watches Kubernetes `services` and `endpoints`, call `netlink` interface create ipvs rules accordingly and sync ipvs rules with Kubernetes `services` and `endpoints`  periodically, to make sure ipvs status is consistent with the expectation. When access the `service`, traffic will be redirect to one of the backend `pod`. Similar to iptables, Ipvs is based on netfilter hook function, but use hash table as the underlying data structure and work in the kernal state. That means ipvs redirects traffic can be much faster, and have much better performance when sync proxy rules. Furthermore, ipvs provides more options for load balancing algorithm, such as: - rr: round-robin - lc: least connection - dh: destination hashing - sh: source hashing - sed: shortest expected delay - nq: never queue **Note:** ipvs mode assumed IPVS kernel modules are installed on the node before running kube-proxy. When kube-proxy starts, if proxy mode is ipvs, kube-proxy would validate if IPVS modules are installed on the node, if it's not installed kube-proxy will fall back to iptables proxy mode. ![Services overview diagram for ipvs proxy](/images/docs/services-ipvs-overview.svg) </ins> ## Multi-Port Services Many `Services` need to expose more than one port.  For this case, Kubernetes

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [x] Bug Report Problem: For users using K8S versions 1.8 and lower that don't have the fix contained in it may be necessary to set for the OpenStack cloud provider when installing on OpenStack clusters that expose their Cinder endpoint using paths rather than ports to avoid auto-detection errors such as: This includes for users trying out K8S on a devstack environment, and potentially other deployment tools. In this situation it is possible to resolve using: Valid values for are: With being the default. Proposed Solution: Highlight the bs-version parameter as optional (so not minimal configuration) but required in some circumstances. Page to Update:


Question: following matches only Pods in the `kube-system` namespace. ```shell <del> kubectl get pods --namespace kube-system -o jsonpath="{..image}" </del> <ins> kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" </ins> ``` ## List Container images using a go-template instead of jsonpath

Hi, I've tested this example : It returns image names double, because "{..image}" recursively search in the output of JSON, So at the first, it will find the "image" word in "" and at the second time, it will find the "image" word in "". It means you will see the image name two times for each pod at least. Please change your example. Best Regards, Alireza Bahmani.
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 What's the URL of the page where you've seen a problem?
here are the links to the: kubernetes docs website page ~ markdown file(s) where it require changes ~
The issue is, the following command produces 2 times (the count of image in a single pod). As mentioned, it is because the command count both the occurrence from the & sections from a single pod json manifest. Ideally it should be:
Following could be one of the fix for it:
/assign
There are other references . These would return duplicate images as well, right? I've updated those as well for now.
Hi yes, I feel those also need to be fixed. Let's wait for to provide their review. :)


Question: ```shell # Add Docker's official GPG key: <del> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/docker.gpg - </del> <ins> curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add - </ins> ``` ```shell

[UBUNTU 20.04] specifies the following command: This runs into the following error: Update the command to: Or... use the command which is also mentioned on the
Thanks for reporting this. I wonder if we should also recommend that readers ? /kind bug /triage accepted /priority important-longterm /language en /sig node
That is a possibility. But I think it would be logical to take over the official documentation of docker.
Did PR help here? /triage needs-information /remove-triage accepted
/retitle Incorrect commands for adding PGP keys to APT configuration
/triage accepted /remove-triage needs-information


Question: | `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | 1.20 | | `BoundServiceAccountTokenVolume` | `true` | Beta | 1.21 | | <ins> | `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | | </ins> | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |

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: doesn't list ControllerManagerLeaderMigration although there is a page that mentions it. Proposed Solution: Update / write the documentation for the feature, including a mention of in Page to Update: Additional Information: /sig cloud-provider
I think there's a plan to graduate this to beta; if so, we should definitely look at getting it properly documented.
yup, agreed. I think we can address it once they open a doc for their enhancement /cc /triage accepted
/assign


Question: - Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) --> <del> - 阅读更多有关 [Secret 概念](/docs/concepts/configuration/secret/) - 了解如何 [使用配置文件管理 Secret](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - 了解如何 [使用 kustomize 管理 Secret](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) </del> <ins> - 阅读更多有关 [Secret 概念](/zh/docs/concepts/configuration/secret/) - 了解如何 [使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) - 了解如何 [使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is missing in Chinese version. See for more info. Proposed Solution: Add /docs/tasks/configmap-secret/ to zh version with three articles to be translated. [x] /zh/docs/tasks/configmap-secret/managing-secret-using-config-[x] /zh/docs/tasks/configmap-secret/managing-secret-using-[x] /zh/docs/tasks/configmap-secret/managing-secret-using- Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--
/language zh /assign


Question: replicationcontroller "my-nginx-v4" rolling updated ``` <del> You can also run the [update demo](/docs/tasks/run-application/rolling-update-replication-controller/) to see a visual representation of the rolling update process. </del> ## Troubleshooting If the `timeout` duration is reached during a rolling update, the operation will

This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: [update demo] link doesn't do anything. It links to the same page. Proposed Solution: ? Page to Update:


Question:
Type: Gauge

Labels:componentgroupresourcescopesubresourceverbversion

apiserver_request_duration_seconds

Response latency distribution in seconds for each verb, dry run value, group, version, resource, subresource, scope and component.

Stability Level:STABLE

Type: Histogram

Labels:componentdry_rungroupresourcescopesubresourceverbversion

apiserver_request_total

Counter of apiserver requests broken out for each verb, dry run value, group, version, resource, scope, component, and HTTP response code.

Stability Level:STABLE

Type: Counter

Labels:codecomponentdry_rungroupresourcescopesubresourceverbversion

apiserver_requested_deprecated_apis

Gauge of deprecated APIs that have been requested, broken out by API group, version, resource, subresource, and removed_release.

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: removed metric from the documented metrics for Kubernetes v1.30, but the metric is still collected for the API server (ref: and ). Proposed Solution: Reinstate the documentation for such metric. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--Kubernetes Version: v1.30 <!--Additional Information:--
/sig instrumentation
/triage accepted
This metrics exists in the file generated by . Or there is a problem with the file generated by before. Let me generate the metrics file again and see. /assign
After I re-ran the script, some metrics were indeed missing (not just metrics ), it was a problem with the generated script, I will take a closer look.


Question: <ins> --- title: Ports and Protocols content_type: reference weight: 50 --- When running Kubernetes in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud, it is useful to be aware of the ports and protocols used by Kubernetes components ## Control plane | Protocol | Direction | Port Range | Purpose                 | Used By                   | |----------|-----------|------------|-------------------------|---------------------------| | TCP      | Inbound   | 6443       | Kubernetes API server   | All                       | | TCP      | Inbound   | 2379-2380  | etcd server client API  | kube-apiserver, etcd      | | TCP      | Inbound   | 10250      | Kubelet API             | Self, Control plane       | | TCP      | Inbound   | 10259      | kube-scheduler          | Self                      | | TCP      | Inbound   | 10257      | kube-controller-manager | Self                      | Although etcd ports are included in control plane section, you can also host your own etcd cluster externally or on custom ports. ## Worker node(s) {#node} | Protocol | Direction | Port Range  | Purpose               | Used By                 | |----------|-----------|-------------|-----------------------|-------------------------| | TCP      | Inbound   | 10250       | Kubelet API           | Self, Control plane     | | TCP      | Inbound   | 30000-32767 | NodePort Services†    | All                     | † Default port range for [NodePort Services](/docs/concepts/services-networking/service/). All default port numbers can be overridden. When custom ports are used those ports need to be open instead of defaults mentioned here. One common example is API server port that is sometimes switched to 443. Alternatively, the default port is kept as is and API server is put behind a load balancer that listens on 443 and routes the requests to API server on the default port. </ins>

What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Why is this needed Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update Slack thread: /sig security node docs architecture /area security
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : What would you like to be Create a dedicated ports and protocols page for Kubernetes Clusters. Currently, the closest page that provides this information is under KubeAdm install setup . This is hard to find for any cluster administrator trying to deploy Kubernetes Documented Ports for and are incorrect and need an update /area security 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
Hi Would you be OK to have this as a reference page, rather than as a concept?
/sig network
/sig cluster-lifecycle Given the PR touches kubeadm docs.
Moved it under . This was the kind of feedback I was looking for from SIG Docs. Thank you


Question: title: Container Environment Variables id: container-env-variables date: 2018-04-12 <del> full_link: /docs/concepts/containers/container-environment-variables.md </del> <ins> full_link: /zh/docs/concepts/containers/container-environment/ </ins> short_description: > Container environment variables are name=value pairs that provide useful information into containers running in a Pod.

could you please be more specific? I cannot find the broken link...
if you enter [], you can see next describtion: Pod PodPreset Secret Pod . and you click ‘’ the link is broken
thank you, I'm fixing it now ~
/assign
/language zh


Question: <!-- {{< note >}}For more information about `kubectl`commands, see the [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}} --> <del> {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/user-guide/kubectl-overview/)。{{< /note >}} </del> <ins> {{< note >}}有关 kubectl 命令的更多信息，请参阅 [kubectl 概述](/zh/docs/reference/kubectl/overview/)。{{< /note >}} </ins> <!-- ## Create a Service

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. --kubectl reference link to shows 404. and wont redirect to correct page <!--Required Information--Problem: /language zh Reference Link did not update/ not support redirect Proposed Solution: Update link to in document Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--


Question: ```powershell # replace {{< skew currentPatchVersion >}} with your desired version <del> curl.exe -Lo <path-to-kubeadm.exe>  "https://dl.k8s.io/{{< skew currentPatchVersion >}}/bin/windows/amd64/kubeadm.exe" </del> <ins> curl.exe -Lo <path-to-kubeadm.exe>  "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubeadm.exe" </ins> ``` --> 1. 在 Windows 节点上升级 kubeadm： ```powershell # 将 {{< skew currentPatchVersion >}} 替换为你希望的版本 <del> curl.exe -Lo <kubeadm.exe 路径>  "https://dl.k8s.io/{{< skew currentPatchVersion >}}/bin/windows/amd64/kubeadm.exe" </del> <ins> curl.exe -Lo <kubeadm.exe 路径>  "https://dl.k8s.io/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubeadm.exe" </ins> ``` <!--

<!--Required Information--Problem: We've deprecated the param () and now English documents are using instead. (by ) All the other documents need to change into or appropriatly. Since several languages are involved, I'd like to share this issue to check all localizations complete the task. Proposed Solution: For each localization team, search and change appropriately. (See the reference, ) Please check the following task box if the localization task is complete. Page to Update: [x] de [x] es [x] fr [x] hi [x] id [x] ja [x] ko [x] pt-br [x] ru [x] vi [ ] zh-ch [previously done]Once all localizations have switched over, we can remove the parameter from the site.
/assign for the Korean contents.
PR: [ko] Replace deprecated fullversion shortcode for Korean :) The task for Korean can be completed after is merged into the main branch.
/assign For Brazilian Portuguese changes
/triage accepted
/assign For Hindi changes
The Brazilian Portuguese localization has replaced all occurrences via /.
/assign for french content
/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
/remove-help
I reopened as there is one more page to fix.
Really done! Thanks folks. /close
Closing this issue. <detailsIn response to : Really done! 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