Question: <ins> --- title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する content_type: concept weight: 60 min-kubernetes-server-version: 1.7 --- <!-- overview --> Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやその他の選択肢を利用できない場合に、Podレベルでホスト名の名前解決を上書きできるようになります。このようなカスタムエントリーは、PodSpecのHostAliasesフィールドに追加できます。 HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。 <!-- body --> ## デフォルトのhostsファイルの内容 Nginx Podを実行すると、Pod IPが割り当てられます。 ```shell kubectl run nginx --image nginx ``` ``` pod/nginx created ``` Pod IPを確認します。 ```shell kubectl get pods --output=wide ``` ``` NAME     READY     STATUS    RESTARTS   AGE    IP           NODE nginx    1/1       Running   0          13s    10.200.0.4   worker0 ``` hostsファイルの内容は次のようになります。 ```shell kubectl exec nginx -- cat /etc/hosts ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.4	nginx ``` デフォルトでは、`hosts`ファイルには、`localhost`やPod自身のホスト名などのIPv4とIPv6のボイラープレートだけが含まれています。 ## 追加エントリーをhostAliasesに追加する デフォルトのボイラープレートに加えて、`hosts`ファイルに追加エントリーを追加できます。たとえば、`foo.local`と`bar.local`を`127.0.0.1`に、`foo.remote`と`bar.remote`を`10.1.2.3`にそれぞれ解決するためには、PodのHostAliasesを`.spec.hostAliases`以下に設定します。 {{< codenew file="service/networking/hostaliases-pod.yaml" >}} この設定を使用したPodを開始するには、次のコマンドを実行します。 ```shell kubectl apply -f https://k8s.io/examples/service/networking/hostaliases-pod.yaml ``` ``` pod/hostaliases-pod created ``` Podの詳細情報を表示して、IPv4アドレスと状態を確認します。 ```shell kubectl get pod --output=wide ``` ``` NAME                           READY     STATUS      RESTARTS   AGE       IP              NODE hostaliases-pod                0/1       Completed   0          6s        10.200.0.5      worker0 ``` `hosts`ファイルの内容は次のようになります。 ```shell kubectl logs hostaliases-pod ``` ``` # Kubernetes-managed hosts file. 127.0.0.1	localhost ::1	localhost ip6-localhost ip6-loopback fe00::0	ip6-localnet fe00::0	ip6-mcastprefix fe00::1	ip6-allnodes fe00::2	ip6-allrouters 10.200.0.5	hostaliases-pod # Entries added by HostAliases. 127.0.0.1	foo.local	bar.local 10.1.2.3	foo.remote	bar.remote ``` ファイルの最後に追加エントリーが指定されています。 ## kubeletがhostsファイルを管理するのはなぜですか？ {#why-does-kubelet-manage-the-hosts-file} kubeletがPodの各コンテナの`hosts`ファイルを[管理する](https://github.com/kubernetes/kubernetes/issues/14633)のは、コンテナ起動後にDockerがファイルを[編集する](https://github.com/moby/moby/issues/17190)のを防ぐためです。 {{< caution >}} コンテナ内部でhostsファイルを手動で変更するのは控えてください。 hostsファイルを手動で変更すると、コンテナが終了したときに変更が失われてしまいます。 {{< /caution >}} </ins>

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


Question: Below is a diagram showing how the extension points interact with the Kubernetes control plane.      ![Extension Points and the Control Plane](/docs/concepts/extend-kubernetes/control-plane.png)  ## Extension Points This diagram shows the extension points in a Kubernetes system.      ![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png)  1.   Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. 2.   The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section.

Images which are located in are blocked by enterprise firewall, any plan to move the images to other places such as
Hi Can you identify the images that are blocked? For example, mention the URL of the documentation page that uses those images.
This page, , all images are blocked, such as
This will affect all users behind a state-level censoring filter that blocks Google Docs. /kind cleanup /triage accepted /language en
/assign


Question: アドオンはKubernetesの機能を拡張するものです。 <del> このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 </del> <ins> このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。この一覧は、すべてを網羅するものではありません。 </ins> <!-- body --> <del> ## ネットワークとネットワークポリシー </del> <ins> ## ネットワークとネットワークポリシー {#networking-and-network-policy} </ins> * [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 * [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。

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 file might be outdated. Currently in , there is no "Romana" section. It was removed by the PR . there is no section relevant to "AOS from Apstra". there is no section relevant to "Big Cloud Fabric from Big Switch Networks". there is no section relevant to "Google Compute Engine (GCE)". there is no section relevant to "Nuage Networks VCS (Virtualized Cloud Services)".Also see: Proposed Solution: Update . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ja
/triage accepted
/assign
/assign I'll also check if there are any other differences.


Question: add nodes by setting up your own machines and either adding them manually or having them register themselves to the cluster’s apiserver. See the [Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. <del> - *Add Windows nodes to the cluster*: Kubernetes offers support for Windows worker nodes, allowing you to run workloads implemented in Windows containers. See [Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. </del> - *Scale nodes*: Have a plan for expanding the capacity your cluster will eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) to help determine how many nodes you need, based on the number of pods and

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 mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Proposed Solution: Remove the paragraph that starts “Add Windows nodes to the cluster” from Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: We missed that removal from PR Also relevant (a bit) to issue /language en /kind bug /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 mentions adding Windows nodes to your cluster as a production consideration. In fact, you might want to do this whether your cluster is running in production or not. Remove the paragraph that starts “Add Windows nodes to the cluster” from <!--Kubernetes Version:--We missed that removal from PR Also relevant (a bit) to issue /kind bug /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/triage accepted
/assign


Question: `.spec.ipFamilies`, on the Service. {{< note >}} <del> The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service. </del> <ins> The `.spec.ipFamilies` field is conditionally mutable: you can add or remove a secondary IP address family, but you cannot change the primary IP address family of an existing Service. </ins> {{< /note >}} You can set `.spec.ipFamilies` to any of the following array values:

In concept docs (): but in API docs (): It's also a bit unclear what "primary IP family" means. My first thought was the primary IP family is what's used for (as opposed to which includes all IP families, not just the primary). Is that interpretation correct? If so, it might be better to avoid that terminology because there's also this text in the concept docs which makes "primary" overloaded:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs /sig network
What i have to do in this issue?
The "conditionally mutable" part is correct; that was later and we must have missed updating some places. Yes "Primary/secondary IP family" is widely used. If you think it's confusing then the "primary/secondary field" wording should be changed, not the "primary/secondary IP family". Though really, "primary/secondary IP family" is not really that relevant in the context of individual services... the cluster as a whole has a primary service IP family, which is the family that will get assigned to single-stack services that don't explicitly request an IP family. But for services that request dual-stack, the only difference between "IPv4-primary" and "IPv6-primary" is the fact that old pre-dual-stack clients might treat them as single-stack of that family.
In the Service API docs, I think "primary IP family" is referring to the first family in the list, which may or may not be the same as the cluster's primary service IP family. Maybe we can use "first" and "second" IP families in the context of individual services:
This is feedback on documentation. I think is the page that should change. /transfer website
We might also want to reword: however, the focus of this issue is removing an inconsistency.
/assign
/triage accepted Let's make this clearer.
/unassign This issue is open to work on. Feel free to assign.
/assign


Question: ``` At the bottom of the output, there are messages indicating that the liveness <del> probes have failed, and the containers have been killed and recreated. </del> <ins> probes have failed, and the failed containers have been killed and recreated. </ins> ``` Type     Reason     Age                From               Message

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 documentation on readiness probes is unclear. It describes how to configure readiness for a single container, but when it comes to the restart behavior, it's not exactly clear, if just the container or the complete pod is restarted: the documentation says: but then command is used to show that the restart counter of the pod has been increased. It is not clear in the documentation, if this restart counter relates to all containers in the pod (meaning that all containers in that pod have been restarted due to failed readiness checks of a single container in that pod) or just a single container in the pod. In the example it does not matter because the pod consists of just a single container. Proposed Solution: Please clarify if a single failing container causes a restart of the whole pod or just of the affected container, and how it relates to the RESTARTS field of the output of the command. Page to Update:
/remove-kind bug This is a request to improve docs; the existing docs are unclear, not wrong. /language en /sig node /triage accepted
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
I would like to work on it.
/assign


Question: Your container runtime must support at least v1alpha2 of the container runtime interface. <del> Kubernetes {{< skew currentVersion >}}  defaults to using v1 of the CRI API. If a container runtime does not support the v1 API, the kubelet falls back to </del> <ins> Kubernetes [starting v1.26](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal) _only works_ with v1 of the CRI API. Earlier versions default to v1 version, however if a container runtime does not support the v1 API, the kubelet falls back to </ins> using the (deprecated) v1alpha2 API instead. ## Container runtimes

/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: ## Labels, annotations and taints used on API objects <ins> ### app.kubernetes.io/component Example: `app.kubernetes.io/component=database` Used on: All Objects The component within the architecture. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/created-by Example: `app.kubernetes.io/created-by=controller-manager` Used on: All Objects The controller/user who created this resource. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/instance Example: `app.kubernetes.io/instance=mysql-abcxzy` Used on: All Objects A unique name identifying the instance of an application. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/managed-by Example: `app.kubernetes.io/managed-by=helm` Used on: All Objects The tool being used to manage the operation of an application. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/name Example: `app.kubernetes.io/name=mysql` Used on: All Objects The name of the application. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/part-of Example: `app.kubernetes.io/part-of=wordpress` Used on: All Objects The name of a higher level application this one is part of. One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). ### app.kubernetes.io/version Example: `app.kubernetes.io/version="5.7.21"` Used on: All Objects The current version of the application (e.g., a semantic version, revision hash, etc.). One of the [recommended labels](/docs/concepts/overview/working-with-objects/common-labels/#labels). </ins> ### kubernetes.io/arch Example: `kubernetes.io/arch=amd64`

The page does not mention labels, listed on the page .
The trivial (and still useful approach) is to have hyperlink to We can do that and then later look at merging the two pages.
Thanks /kind cleanup /language en /triage accepted /priority backlog
/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
/assign sladyn98
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
/retitle Recommended app labels missing from Well-Known Labels, Annotations and Taints /kind bug /lifecycle frozen
/sig apps
Hey should I change the hyperlink of to , if so then what files should I look at??
The page to change is . We should edit so that it mentions the labels that are already listed at
do you mean add new/additional sections for in the by adding sections/blocks for each of the common labels? has 7 labels, so we'd add 7 blocks? !
/assign
That is what I mean, yes. There would be an extra heading and block for each of the 7 missing labels.
/unassign sladyn98
Sorry it's been so long FYI Updated page: https://deploy-preview---kubernetes-io-main-


Question: other = "You are viewing documentation for Kubernetes version:" [deprecation_warning] <del> other = " documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date documentation, see the " </del> <ins> other = " documentation is no longer actively maintained. The version you are currently viewing is a static snapshot. For up-to-date information, see the " </ins> [deprecation_file_warning] other = "Deprecated"

When a Kubernetes release happens, like 1.22, the now "old" site becomes a subdomain snapshot (ie: https://v1-). This is great for archival purposes, however, if you navigate to the snapshot's release page (https://v1-) it is stuck at that point in time. This problem exists because each older site is a branch. 1.21 is on the branch. We should have a single source of truth () and all other subdomains should automatically point to the current documentation. I would recommend adding a shortcode, much like we do to create the yellow box* on older pages. ! The yellow box shortcode exists on all versions and branches of k/website, but is contingent on a hugo configuration value (set ). For example: 1.22 on the branch does not have the box appear and the is set to false (). 1.21 on the branch does have the box appear and the is set to true () The bit of code that actually generates the parameter is in the following layout partial: The "T" before the value references using the translated strings that are localized in the relative language files. For example, the English translation is located . For more information on the releases page and how it's made, check out the PR: This is a well scoped issue, but maybe slightly more advanced for a first issue. I will mark it as such either way. /sig docs /good-first-issue
/triage accepted
I would like to work on this. /assign
Would it be OK to redirect https://v1- to ? At the point we make a release we could commit in some extra redirects (for v1.21, that'd be retrospective).
I believe this would disrupt the assumed UX, "I thought I was on the 1.21 docs" or the subsequent navigation. In addition, baking it into a shortcode similar to deprecations, there is no additional work for the docs release team. I think that would be a fine solution short term though.
We could use a Hugo layout rather than a shortcode for this. If we copy the way that the docs pages do that, I think that could work. Maybe with a tweak to say “release information” rather than “documentation”; maybe use shared wording but tweak it to be more neutral.

Sorry, for the noise, (I replied and deleted it) I thought this was a comment to a different issue. If we use a layout, we're still in the same problem of the release data contained on the branch never getting touched, right?
/area web-development
That layout can have a conditional, “is this the current release?” and skip rendering part of the page if the answer is . (The yellow deprecation warning is actually a layout not a shortcode) /retitle Create a Hugo layout to not display release information on older versions of As this has confused two experienced contributors(!) I'll leave this marked as Help Wanted but not as a good first issue. /remove-good-first-issue
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen I'd like to see this change happen.
Reopened this issue. <detailsIn response to : /reopen I'd like to see this change happen. 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
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/reopen /lifecycle frozen
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen 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'm happy to jump in and work on this issue to help move it forward. /assign


Question: - architecture - operation --- <!-- <del> --- </del> title: Cloud Controller Manager id: cloud-controller-manager date: 2018-04-12 full_link: /docs/concepts/architecture/cloud-controller/ short_description: > <del> Cloud Controller Manager is an alpha feature in 1.8. In upcoming releases it will be the preferred way to integrate Kubernetes with any cloud. </del> <ins> Control plane component that integrates Kubernetes with third-party cloud providers. </ins> aka: tags: - core-object - architecture - operation <del> --- </del> --> <!-- A Kubernetes {{< glossary_tooltip text="control plane" term_id="control-plane" >}} component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster. --> 云控制器管理器是指嵌入特定云的控制逻辑的 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。 <del> 云控制器管理器允许您链接集群到云提供商的应用编程接口中， 并把和该云平台交互的组件与只和您的集群交互的组件分离开。 </del> <ins> 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 </ins> <!--more-->

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 reference/glossary/cloud-controller- is wrong Proposed Solution: In , In : In : and so on... Page to Update: [No webpage should be affected by the changes which this issue is suggesting.] <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh
/triage accepted /language zh /kind bug /assign


Question: --- title: Contributing new content <ins> content_type: concept main_menu: true </ins> weight: 20 --- <ins> <!-- overview --> This section contains information you should know before contributing new content. <!-- body --> ## Contributing basics - Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/). - The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory. - [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo. - In addition to the standard Hugo shortcodes, we use a number of [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content. - Documentation source is available in multiple languages in `/content/`. Each language has its own folder with a two-letter code determined by the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For example, English documentation source is stored in `/content/en/docs/`. - For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization). ## Before you begin {#before-you-begin} ### Sign the CNCF CLA {#sign-the-cla} All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md). Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA. ### Choose which Git branch to use When opening a pull request, you need to know in advance which branch to base your work on. Scenario | Branch :---------|:------------ Existing or new English language content for the current release | `main` Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-<version>`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch. Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information. If you're still not sure which branch to choose, ask in `#sig-docs` on Slack. {{< note >}} If you already submitted your pull request and you know that the base branch was wrong, you (and only you, the submitter) can change it. {{< /note >}} ### Languages per PR Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language. ## Tools for contributors The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly. </ins>

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Copy the page contents from into Redirect to (edit ) Delete Why is this needed The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. Comments /language en /good-first-issue /sig contributor-experience
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : This is a Feature Request <!-- See for guidance on writing an actionable issue description. --- Copy the page contents from into Redirect to The page at is an overview for the “Contributing new content” new section. Making this change means that is detailed, rather than blank. /language en /good-first-issue /sig contributor-experience 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
Please try some other alternatives. Let's be cautious when moving pages. Every relocation has to be replicated into all localizations. It may look straightforward for English to add a redirect entry. The fact is we may need to a dozen of redirect entries for all localizations. I don't see a compelling reason to move pages like this.
Perhaps it'd help to have some tooling to make it easy to copy redirects to a localization? Would that toil reduction change your mind
hello i want to work on this issue.
/assign
Hi , Happy to take care of this, but to be safe... Was there a consensus on how to handle the redirects for this issue? Thank you.
/triage accepted what would you like to know about redirects?
/assign
/assign
/assign
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
is this issue still open? if yes, can I contribute to this?


Question: [examples_heading] other = "उदाहरण" <ins> [feature_state] other = "फ़ीचर स्थिति:" </ins> [feedback_heading] other = "प्रतिक्रिया"

Updated with new strings from Didn't remove any strings from , even if they're missing from
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/language hi
Completed.


Question:
as a bearer token.  See [above](#putting-a-bearer-token-in-a-request) for how the token is included in a request.  ![Kubernetes OpenID Connect Flow](/images/docs/admin/k8s_oidc_login.svg)   {{< mermaid >}} sequenceDiagram participant user as User participant idp as Identity Provider participant kube as Kubectl participant api as API Server user ->> idp: 1. Login to IdP activate idp idp -->> user: 2. Provide access_token,
id_token, and refresh_token deactivate idp activate user user ->> kube: 3. Call Kubectl
with --token being the id_token
OR add tokens to .kube/config deactivate user activate kube kube ->> api: 4. Authorization: Bearer... deactivate kube activate api api ->> api: 5. Is JWT signature valid? api ->> api: 6. Has the JWT expired?(iat+exp) api ->> api: 7. user authorized? api -->> kube: 8. Authorized: Perform
action and return result deactivate api activate kube kube --x user: 9. Return result deactivate kube {{< /mermaid >}}  1.  Login to your identity provider 2.  Your identity provider will provide you with an `access_token`, `id_token` and a `refresh_token`

This is a Feature Request What would you like to be Replace the sequence diagram on with the one by . This is the follow-up of . Why is this needed There are several pros to use mermaid to draw the sequence diagram: mermaid format is more readable easy to modify better styling Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/assign
/kind cleanup /language en /triage accepted /priority backlog


Question: .resources { width: 100%; <del> margin-top; 5%; </del> <ins> margin-top: 5%; </ins> margin-bottom: 3%; float: left; }

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: (Despite the PR has been merged, it seems that the error still exists. So opening an issue here. ) From the PR : [As-is] ! ! [To-be] ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--CC /area web-development
/triage accepted
Hello Thanks for reporting this issue. May i kindly know some more details to reproduce the issue. 1) Browser & Version ? 2) Resolution of your display ? I'm trying to reproduce it on wide viewport !
Hello Here is the info of my env: Windows 10 Enterprise 20H2 Google Chrome 97.0.4692.99 (64bit) Monitor resolution: 3840 1600 Chrome window size: [1868 1592] ! [1868 1592] [3767 1600] ! [3767 * 1600]
I can replicate this with Chromium and with Firefox.
/priority backlog
Thanks for the information. Please can you assign this issue to me.
try this Prow command: /assign ravikiranr26 (reply in a comment with that command on a line by itself)
/assign ravikiranr26


Question: <ins> --- title: 拡張リソースをNodeにアドバタイズする content_type: task --- <!-- overview --> このページでは、Nodeに対して拡張リソースを指定する方法を説明します。拡張リソースを利用すると、Kubernetesにとって未知のノードレベルのリソースをクラスター管理者がアドバタイズできるようになります。 ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} <!-- steps --> ## Nodeの名前を取得する ```shell kubectl get nodes ``` この練習で使いたいNodeを1つ選んでください。 ## Nodeの1つで新しい拡張リソースをアドバタイズする Node上の新しい拡張リソースをアドバタイズするには、HTTPのPATCHリクエストをKubernetes APIサーバーに送ります。たとえば、Nodeの1つに4つのドングルが接続されているとします。以下に、4つのドングルリソースをNodeにアドバタイズするPATCHリクエストの例を示します。 ```shell PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 Accept: application/json Content-Type: application/json-patch+json Host: k8s-master:8080 [ { "op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4" } ] ``` Kubernetesは、ドングルとは何かも、ドングルが何に利用できるのかを知る必要もないことに注意してください。上のPATCHリクエストは、ただNodeが4つのドングルと呼ばれるものを持っているとKubernetesに教えているだけです。 Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 ```shell kubectl proxy ``` もう1つのコマンドウィンドウを開き、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 ```shell curl --header "Content-Type: application/json-patch+json"  --request PATCH  --data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]'  http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status ``` {{< note >}} 上のリクエストにある`~1`は、PATCHのパスにおける`/`という文字をエンコーディングしたものです。JSON-Patch内のoperationのpathはJSON-Pointerとして解釈されます。詳細については、[IETF RFC 6901](https://tools.ietf.org/html/rfc6901)のsection 3を読んでください。 {{< /note >}} 出力には、Nodeがキャパシティー4のdongleを持っていることが示されます。 ``` "capacity": { "cpu": "2", "memory": "2049008Ki", "example.com/dongle": "4", ``` Nodeの説明を確認します。 ``` kubectl describe node <選択したNodeの名前> ``` 出力には、再びdongleリソースが表示されます。 ```yaml Capacity: cpu:  2 memory:  2049008Ki example.com/dongle:  4 ``` これで、アプリケーション開発者は特定の数のdongleをリクエストするPodを作成できるようになりました。詳しくは、[拡張リソースをコンテナに割り当てる](/docs/tasks/configure-pod-container/extended-resource/)を読んでください。 ## 議論 拡張リソースは、メモリやCPUリソースと同様のものです。たとえば、Nodeが持っている特定の量のメモリやCPUがNode上で動作している他のすべてのコンポーネントと共有されるのと同様に、Nodeが搭載している特定の数のdongleが他のすべてのコンポーネントと共有されます。そして、アプリケーション開発者が特定の量のメモリとCPUをリクエストするPodを作成できるのと同様に、Nodeが搭載している特定の数のdongleをリクエストするPodが作成できます。 拡張リソースはKubernetesには詳細を意図的に公開しないため、Kubernetesは拡張リソースの実体をまったく知りません。Kubernetesが知っているのは、Nodeが特定の数の拡張リソースを持っているということだけです。拡張リソースは整数値でアドバタイズしなければなりません。たとえば、Nodeは4つのdongleをアドバタイズできますが、4.5のdongleというのはアドバタイズできません。 ### Storageの例 Nodeに800GiBの特殊なディスクストレージがあるとします。この特殊なストレージの名前、たとえばexample.com/special-storageという名前の拡張リソースが作れます。そして、そのなかの一定のサイズ、たとえば100GiBのチャンクをアドバタイズできます。この場合、Nodeはexample.com/special-storageという種類のキャパシティ8のリソースを持っているとアドバタイズします。 ```yaml Capacity: ... example.com/special-storage: 8 ``` 特殊なストレージに任意のサイズのリクエストを許可したい場合、特殊なストレージを1バイトのサイズのチャンクでアドバタイズできます。その場合、example.com/special-storageという種類の800Giのリソースとしてアドバタイズします。 ```yaml Capacity: ... example.com/special-storage:  800Gi ``` すると、コンテナは好きなバイト数の特殊なストレージを最大800Giまでリクエストできるようになります。 ## クリーンアップ 以下に、dongleのアドバタイズをNodeから削除するPATCHリクエストを示します。 ``` PATCH /api/v1/nodes/<選択したNodeの名前>/status HTTP/1.1 Accept: application/json Content-Type: application/json-patch+json Host: k8s-master:8080 [ { "op": "remove", "path": "/status/capacity/example.com~1dongle", } ] ``` Kubernetes APIサーバーに簡単にリクエストを送れるように、プロキシーを実行します。 ```shell kubectl proxy ``` もう1つのコマンドウィンドウで、HTTPのPATCHリクエストを送ります。`<選択したNodeの名前>`の部分は、選択したNodeの名前に置き換えてください。 ```shell curl --header "Content-Type: application/json-patch+json"  --request PATCH  --data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]'  http://localhost:8001/api/v1/nodes/<選択したNodeの名前>/status ``` dongleのアドバタイズが削除されたことを検証します。 ``` kubectl describe node <選択したNodeの名前> | grep dongle ``` (出力には何も表示されないはずです) ## {{% heading "whatsnext" %}} ### アプリケーション開発者向け * [拡張リソースをコンテナに割り当てる](/ja/docs/tasks/configure-pod-container/extended-resource/) ### クラスター管理者向け * [Namespaceに対してメモリの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) * [Namespaceに対してCPUの最小値と最大値の制約を設定する](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: release in order to get access to the packages of the desired Kubernetes minor version. <del> {{< tabs name="k8s_install_versions" >}} </del> <ins> {{< tabs name="k8s_upgrade_versions" >}} </ins> {{% tab name="Ubuntu, Debian or HypriotOS" %}} 1. Open the file that defines the Kubernetes `apt` repository using a text editor of your choice:

In the "" section of the "" document, the steps for switching CentOS/RHEL/Fedora are the same as those for Ubuntu/Debian. There should be specific steps for RHEL based distributions. Suggest the following: Open the file that defines the Kubernetes apt repository using a text editor of your choice: nano You should see a single line with the URL that contains your current Kubernetes minor version. For example, if you're using v1.27, you should see this: Change the version in the URL to the next available minor release, for example: Save the file and exit your text editor. Continue following the relevant upgrade instructions.
Page reported in issue: /language en /sig docs
I see that the content is present in the file but isn't displaying correctly within the tab layout on the page. /kind bug /priority backlog /triage accepted
I'll try to investigate this issue and see if I can offer assistance. /assign


Question: release in order to get access to the packages of the desired Kubernetes minor version. <del> {{< tabs name="k8s_install_versions" >}} </del> <ins> {{< tabs name="k8s_upgrade_versions" >}} </ins> {{% tab name="Ubuntu, Debian or HypriotOS" %}} 1. Open the file that defines the Kubernetes `apt` repository using a text editor of your choice:

: "Switching to another Kubernetes package repository" and particularly the one for CentOS/REHL shows commands for Debian based system, not REHL based rpm
I'm not seeing this. Can you point out where there are deb commands for RHEL? !
Excuse me it is for old versions: https://v1- https://v1- https://v1- !
I'm also not able to see this for Old version?? !
/retitle Broken tab layout on "Changing The Kubernetes Package Repository" page in older doc versions /kind bug
The problem stems from the existence of two tab layouts on this page having the same name "k8sinstallversions". This issue has been resolved in the branch. To address this issue in old docs versions, we'll need to backport and apply the fix to each corresponding old branch (release-1.25, release-1.26, release-1.27, release-1.28). Considering that the older versions of the documentation are no longer actively maintained, there's a question of whether it's worth investing efforts into fixing this issue.
I don't think it much important!
I'd support a backport. One of the things we do want people to learn to do with older Kubernetes versions is: to upgrade them! /triage accepted /priority backlog
I can try to help with this. /assign
I think the backporting is done which resolves this issue
If it is ok we can close this issue
The fixes have been back-ported to the older release branches. Closing this as completed. /close
Closing this issue. <detailsIn response to : The fixes have been back-ported to the older release branches. Closing this as completed. Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: ## {{% heading "whatsnext" %}} <del> Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). </del> <ins> - Learn more about [Labels and Selectors](/docs/concepts/overview/working-with-objects/labels/). - Find [Well-known labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) </ins>

This page should probably link to resources for defining standard annotations. Especially the thinks mentioned as examples. That would unify it a bit (for example contact address). Maybe link to
Page related to issue: /language en
/retitle Signpost from "Annotations" to "Well-Known Labels, Annotations and Taints" reference page
We can enhance the section by including a link to the reference page, as well as any other relevant pages. This will be beneficial in guiding readers to explore those additional pages.
/kind feature /triage accepted /priority backlog
please i will want to work in this! /assign
i have riased pull request please review.


Question: - name: about title: ドキュメントについて description: このWebサイトには、Kubernetesの最新バージョンと過去4世代のドキュメントが含まれています。 <ins> button: "利用可能なバージョンを見る" button_path: "/docs/home/supported-doc-versions" </ins> ---

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Add button for "" in Why is this needed Because it exists in en() but not in ja( ). Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/retitle [ja] Add button in /area localization /triage accepted


Question: Kubernetes imposes on them. | Built-in Type                         | Usage                                   | <del> | ------------------------------------- | --------------------------------------- | | `Opaque`                              | arbitrary user-defined data             | </del> <ins> | ------------------------------------- |---------------------------------------- | | `Opaque`                              | arbitrary user-defined data            | </ins> | `kubernetes.io/service-account-token` | ServiceAccount token                    | | `kubernetes.io/dockercfg`             | serialized `~/.dockercfg` file          | | `kubernetes.io/dockerconfigjson`      | serialized `~/.docker/config.json` file |

Umbrella issue: contains multiple "use cases" for Secrets. However, many of these are mini-tasks. In this issue, I'd like to discuss each of these use cases at a high level to see which we can remove, which we can trim, and which we can move to a new or existing task page. That way, the "Use cases section could even be a bulleted list with links to relevant tasks. Use case: As container environment variables Recommendation: Delete Justification: the goal is achieved in . This also isn't a use case, it's a way to use a secret. Use case: Pod with SSH keys Recommendation: Delete content, keep use case as bullet Justification: the steps add no value beyond the existing task to . Use case: Pods with prod / test credentials Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page. Use case: dotfiles in a secret volume Recommendation: Remove steps and keep as bullet point with additional info about why it would be useful. Use case: Secret visible to one container in a Pod Recommendation: Move content to a new or existing task Justification: The content is complex enough that it can be its own task, either as part of or a new task page with actual steps to achieve more than just "secret visible to one container". Perhaps including RBAC steps. If you're interested, review each use case and leave a comment for each agreeing, disagreeing, or providing a different approach to each use case. After we've discussed and settled on an action for these use cases, we can start the actual work! /sig docs /cc
/assign
I think the "Use case: As container environment variables" can be removed as the goal is achieved in too.
Yeah agreed, although I'm separately removing that section and linking it to our existing task page as part of
Let's shift "Use case: Pods with prod/test credentials" and "Use case: secret visible to one container in a Pod" to and attach the link in the use case section as bullet notes.
/triage accepted
Imo the prod/test thing might not even need to move - it can live as an example in the concept but the task steps seem quite basic now that I think about it. Just referencing two Secrets in two different Pods...


Question: an illustrative collection of numbers of elephants. See https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. <del> {{< table caption="Example Shuffle Sharding Configurations" >}} |HandSize|     Queues|	1 elephant|		4 elephants|		16 elephants| |--------|-----------|------------|----------------|--------------------| |      12|         32|	4.428838398950118e-09|	0.11431348830099144|	0.9935089607656024| |      10|         32|	1.550093439632541e-08|	0.0626479840223545|	0.9753101519027554| |      10|         64|	6.601827268370426e-12|	0.00045571320990370776|	0.49999929150089345| |       9|         64|	3.6310049976037345e-11|	0.00045501212304112273|	0.4282314876454858| |       8|         64|	2.25929199850899e-10|	0.0004886697053040446|	0.35935114681123076| |       8|        128|	6.994461389026097e-13|	3.4055790161620863e-06|	0.02746173137155063| |       7|        128|	1.0579122850901972e-11|	6.960839379258192e-06|	0.02406157386340147| |       7|        256|	7.597695465552631e-14|	6.728547142019406e-08|	0.0006709661542533682| |       6|        256|	2.7134626662687968e-12|	2.9516464018476436e-07|	0.0008895654642000348| |       6|        512|	4.116062922897309e-14|	4.982983350480894e-09|	2.26025764343413e-05| |       6|       1024|	6.337324016514285e-16|	8.09060164312957e-11|	4.517408062903668e-07| </del> <ins> {{< table caption = "Example Shuffle Sharding Configurations" >}} HandSize | Queues | 1 elephant | 4 elephants | 16 elephants |----------|-----------|------------|----------------|--------------------| | 12 | 32 | 4.428838398950118e-09 | 0.11431348830099144 | 0.9935089607656024 | | 10 | 32 | 1.550093439632541e-08 | 0.0626479840223545 | 0.9753101519027554 | | 10 | 64 | 6.601827268370426e-12 | 0.00045571320990370776 | 0.49999929150089345 | | 9 | 64 | 3.6310049976037345e-11 | 0.00045501212304112273 | 0.4282314876454858 | | 8 | 64 | 2.25929199850899e-10 | 0.0004886697053040446 | 0.35935114681123076 | | 8 | 128 | 6.994461389026097e-13 | 3.4055790161620863e-06 | 0.02746173137155063 | | 7 | 128 | 1.0579122850901972e-11 | 6.960839379258192e-06 | 0.02406157386340147 | | 7 | 256 | 7.597695465552631e-14 | 6.728547142019406e-08 | 0.0006709661542533682 | | 6 | 256 | 2.7134626662687968e-12 | 2.9516464018476436e-07 | 0.0008895654642000348 | | 6 | 512 | 4.116062922897309e-14 | 4.982983350480894e-09 | 2.26025764343413e-05 | | 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | {{< /table >}} </ins> ### FlowSchema

HTML breaks on this page: Related to Hugo version upgrade in
After investigating, it appears that the table is breaking partly because the caption shortcode was . The originating PR was by That said, even refactoring the table for whitespace doesn't fix the error; only removing the shortcode does. I'll open a PR for others to experiment. UPDATE: Works fine.


Question: 在开始本教程之前，你应该熟悉以下 Kubernetes 的概念： <del> * [Pods](/zh/docs/user-guide/pods/single-container/) </del> <ins> * [Pods](/zh/docs/concepts/workloads/pods/) </ins> * [Cluster DNS](/zh/docs/concepts/services-networking/dns-pod-service/) * [Headless Services](/zh/docs/concepts/services-networking/service/#headless-services) * [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: ! ! Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh
/kind bug
/assign


Question: Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath <del> ### Persistent volumes {#Persistent volumes} </del> <ins> ### Persistent volumes {#Persistent-volumes} </ins> - **awsElasticBlockStore** (AWSElasticBlockStoreVolumeSource)

This is a Bug Report The issue is outlined in:
/triage accepted
/kind cleanup
Hi Thanks for opening a PR to fix this issue! /assign


Question: <ins> --- title: ドキュメントコンテンツガイド linktitle: コンテンツガイド content_type: concept weight: 10 --- <!-- overview --> このページでは、Kubernetesのドキュメント上のコンテンツのガイドラインを説明します。 許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！ Kubernetes Slackには、<https://slack.k8s.io/> から参加登録ができます。 Kubernetesドキュメントの新しいコンテンツの作成に関する情報については、[スタイルガイド](/docs/contribute/style/style-guide)に従ってください。 <!-- body --> ## 概要 ドキュメントを含むKubernetesのウェブサイトのソースは、[kubernetes/website](https://github.com/kubernetes/website)リポジトリに置かれています。 Kubernetesの主要なドキュメントは`kubernetes/website/content/<language_code>/docs`フォルダに置かれており、これらは[Kubernetesプロジェクト](https://github.com/kubernetes/kubernetes)を対象としています。 ## 許可されるコンテンツ Kubernetesのドキュメントにサードパーティーのコンテンツを掲載することが許されるのは、次の場合のみです。 - コンテンツがKubernetesプロジェクト内のソフトウェアのドキュメントとなる場合 - コンテンツがプロジェクト外のソフトウェアのドキュメントとなるが、Kubernetesを機能させるために必要である場合 - コンテンツがkubernetes.ioの正規のコンテンツであるか、他の場所の正規のコンテンツへのリンクである場合 ### サードパーティーのコンテンツ Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes](https://github.com/kubernetes)および[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizationsに存在するプロジェクト)の適用例が含まれています。 Kubernetesプロジェクト内のアクティブなコンテンツへのリンクは常に許可されます。 Kubernetesを機能させるためには、一部サードパーティーのコンテンツが必要です。たとえば、コンテナランタイム(containerd、CRI-O、Docker)、[ネットワークポリシー](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)(CNI plugin)、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)、[ロギング](/docs/concepts/cluster-administration/logging/)などです。 ドキュメント内で、Kubernetesプロジェクト外のサードパーティーのオープンソースソフトウェア(OSS)にリンクすることができるのは、Kubernetesを機能させるために必要な場合のみです。 ### 情報源が重複するコンテンツ 可能な限り、Kubernetesのドキュメントは正規の情報源にリンクするようにし、情報源が重複してしまうようなホスティングは行いません。 情報源が重複したコンテンツは、メンテナンスするために2倍の労力(あるいはそれ以上！)が必要になり、より早く情報が古くなってしまいます。 {{< note >}} あなたがKubernetesのプロジェクトのメンテナーであり、ドキュメントのホスティングに関して手助けが必要なときは、[Kubernetes Slackの#sig-docs](https://kubernetes.slack.com/messages/C1J0BPD2M/)で教えてください。 {{< /note >}} ### その他の情報 許可されるコンテンツに関して疑問がある場合は、[Kubernetes Slack](https://slack.k8s.io/)の#sig-docsチャンネルに参加して質問してください！ ## {{% heading "whatsnext" %}} * [スタイルガイド](/docs/contribute/style/style-guide)を読む </ins>

This is a Feature Request What would you like to be Translate into Japanese. Why is this needed This page has not been translated. Comments /language ja /assign
/close
Closing this issue. <detailsIn response to : /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details


Question: 特定のバージョンをダウンロードする場合、コマンドの`$(curl -LS https://dl.k8s.io/release/stable.txt)`の部分を特定のバージョンに書き換えてください。 <del> たとえば、macOSへ{{< param "fullversion" >}}のバージョンをダウンロードするには、次のコマンドを入力します: </del> <ins> たとえば、macOSへ{{< skew currentPatchVersion >}}のバージョンをダウンロードするには、次のコマンドを入力します: </ins> ```bash <del> curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl </del> <ins> curl -LO https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/darwin/amd64/kubectl </ins> ``` 2. kubectlバイナリを実行可能にしてください。

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: ... ```  contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`.   It contains two elements in the `from` array, and allows connections from Pods in the local Namespace with the label `role=client`, *or* from any Pod in any namespace with the label `user=alice`.  When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy.   __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.   **ipBlock**: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable.  Cluster ingress and egress mechanisms often require rewriting the source or destination IP of packets. In cases where this happens, it is not defined whether this happens before or

I spent one hour to do one sample exercice about network policy because of your wrong configuration !!! +++++++++++++++++++++ policyTypes: # should remove space in the 2nd & 3rd line Ingress Egress ++++++++++++++++++++++ egress: to: ipBlock: cidr: 10.0.0.0/24 ports: # "-" is missing before ports protocol: TCP port: 5978
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle Invalid manifest in Network Policies page Thanks for reporting the bug /kind bug /language en Please paste in the entire invalid manifest (surround it by <tt`</ttif you can) so we know which part of the page is wrong. We could guess, but it's easier if you're explicit about this
/triage accepted /assign


Question: spec: containers: - name: follower <del> image: gcr.io/google_samples/gb-redis-follower:v2 </del> <ins> image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2 </ins> resources: requests: cpu: 100m

cannot pull frontend container, it shows ImagePullBackOff !
Page reported in issue: /language zh
/retitle [zh] Deprecated image causes failures in "Deploying PHP Guestbook with Redis" tutorial
/kind bug
/triage accepted /assign


Question: ## 업그레이드할 버전 결정 <del> 1.  최신의 안정 버전인 1.18을 찾는다. </del> <ins> 최신의 안정 버전인 1.18을 찾는다. </ins> <del> {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </ins> apt update apt-cache madison kubeadm # 목록에서 최신 버전 1.18을 찾는다 # 1.18.x-00과 같아야 한다. 여기서 x는 최신 패치이다. <del> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </ins> yum list --showduplicates kubeadm --disableexcludes=kubernetes # 목록에서 최신 버전 1.18을 찾는다 # 1.18.x-0과 같아야 한다. 여기서 x는 최신 패치이다. <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> ## 컨트롤 플레인 노드 업그레이드 ### 첫 번째 컨트롤 플레인 노드 업그레이드 <del> 1.  첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다. </del> <ins> -  첫 번째 컨트롤 플레인 노드에서 kubeadm을 업그레이드한다. </ins> <del> {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian 또는 HypriotOS" %}} </ins> # 1.18.x-00에서 x를 최신 패치 버전으로 바꾼다. apt-mark unhold kubeadm &&  apt-get update && apt-get install -y kubeadm=1.18.x-00 &&  apt-mark hold kubeadm <ins> - </ins> # apt-get 버전 1.1부터 다음 방법을 사용할 수도 있다 apt-get update &&  apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL 또는 Fedora" %}} </ins> # 1.18.x-0에서 x를 최신 패치 버전으로 바꾼다. yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> <del> 1.  다운로드하려는 버전이 잘 받아졌는지 확인한다. </del> <ins> -  다운로드하려는 버전이 잘 받아졌는지 확인한다. </ins> ```shell kubeadm version ``` <del> 1.  컨트롤 플레인 노드를 드레인(drain)한다. </del> <ins> -  컨트롤 플레인 노드를 드레인(drain)한다. </ins> ```shell # <cp-node-name>을 컨트롤 플레인 노드 이름으로 바꾼다. kubectl drain <cp-node-name> --ignore-daemonsets ``` <del> 1.  컨트롤 플레인 노드에서 다음을 실행한다. </del> <ins> -  컨트롤 플레인 노드에서 다음을 실행한다. </ins> ```shell sudo kubeadm upgrade plan

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: Broken layout on "kubeadm " ! Proposed Solution: Check and apply upstream changes. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
/unassign This issue already has been assigned to .


Question: <!-- overview --> <del> CronJobs was promoted to general availability in Kubernetes v1.21. If you are using an older version of Kubernetes, please refer to the documentation for the version of Kubernetes that you are using, so that you see accurate information. Older Kubernetes versions do not support the `batch/v1` CronJob API. </del> You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system.

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There's some text on some of the pages about CronJob ; for example, When Kubernetes v1.25 is released, we can (and think should) remove that text, because none of the versions before 1.21 would be in support. Proposed Solution: Remove that paragraph. :informationsource: make the update on the dev-1.25 branch Page to Update: Kubernetes Version: v1.25 (upcoming)_ Additional Information: /sig apps /language en /kind cleanup /milestone 1.25
/assign
/triage accepted
/assign
/unassign
Thank you


Question: $($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) ``` <del> 1. Add the binary in to your `PATH`. </del> <ins> 1. Append or prepend the kubectl binary folder to your `PATH` environment variable. </ins> 1. Test to ensure the version of `kubectl` is the same as downloaded:

Hello, I have recently and I have noticed that there is a slight error at step 3. Namely, the line says: when it really should be: I have tested it a few times and indeed, adding to PATH does not work, while simply adding yields the correct result (i.e. being able to invoke kubectl commands from the command prompt). I know it is a minor issue but for beginners (like myself) it could make the difference between completing the installation or not. Even though I have not tried other methods of installation, I suspect that the same step should also be corrected in section , where it also says "Add the binary in to your PATH." Best regards, Paula
/triage accepted Similar issue exists in . cf. In : !
is kind of techie vernacular (it's how I'd say it in spoken English to a colleague), but in technical docs we can be more precise. /language en
Hi, I would like to work on this issue. /assign
/sig windows


Question: --- title: "Scheduling, Preemption and Eviction" <del> weight: 90 </del> <ins> weight: 95 </ins> content_type: concept description: > In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes

This is a Bug Report Problem: Some pages at the same width have the same weight in their . Originally, the pages have to be sorted based on weights even when localizing the documents. However, for some pages with the same weight at the same level, they are sorted in the order of the strings of the translated titles, which makes them out of order with the English documents. Each localization teams might change the weight according to their language and put them in the right order, but I think it would be better to change the overall weights in the English document. And more than 100 pages need to be modified. For example in Korean, the pages are sorted by first letter of "Korean-translated title", the order of pages below in Korean is different with that of English. English ! Korean ! <brProposed Solution: Re-order every page that has the same weight in the same level. Page to Update: If you guys think this is needed, I will organize all the pages that need to be modified at the comment. I have structured the pages of the whole document like below. Pairs with the same weights are marked with [ N ] at the beginning of the title. The value at the end of the title is each of their weights. <img width="663" alt="image" src="https://user-"<br/kind cleanup /assign
Given how much this is a problem for localizations, we could (should?) add a CI test to warn when two pages have an equal weight in a section - that'd be a way to stop the problem returning. I presume that pages with no weight declared are also a problem for the same reason.
Thank you for comment and add as a CI test seems good idea! But before adding, wouldn't it be better to check it once and make changes, and then add this task to a CI test? :smiley: As you commented, there were some pages that had no weights, too!
I'm OK with either order. Folks can work on the CI test first, or the manual fix first. We'll only really get value if we do both of those things (otherwise, we'll tend to find that we return to a state where page weights overlap). Another fix might be to sort localized pages with overlapping weight based on the collation order of the English equivalent page.

That does not sound easy, mind!
Neither do I think it's not easy to change the weights according to each Localizations. That's why I opened an issue for English documentation!! Would it be better to open a PR first(with personally modified wieghts) and then get a review, or would it be better to agree on the appropriate weights here first??
Thank you for bringing this up in the localization meeting yesterday! After chatting about it in the meeting, we determined, based on the research done by there aren't any sections where overlapping page weights are causing a different ordered side navigation in localized content that will disrupt users from understanding content. Meaning, there aren't any sections in the side nav where this issue is occurring and a user would need to read the pages in a specific order. Our recommended action is: this as an issue within the broader sig docs community, in slack and in the next community meeting, to make sure folks working on the English language docs understand the importance of page weights and potential problem overlapping pages weights cause in localized content. Use a "lazy" updating approach, to adjust English language page weights as a page is updated. I think if we implemented idea for adding a CI warning that would help speed up making the adjustments to each English page. may also want to add a note to our docs to highlight that we shouldn't use overlapping weights within a section. and does this sound like a good summary of our discussion? Did i miss anything? cc:
Thank you for your opinion !! I also agree that each localization teams would be nice to aware of this even if it doesn't need to be modified now! For docs, it seems great idea, and I'll open an issue for that!
/triage accepted
/area localization
Watch out for updating the weight values for pages that are autogenerated - we should teach the page generator to produce our preferred values instead.
/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
During the docs sprint we were tracking the areas that we already checked for page weights issues in this Hack MD file: Pages that have been checked off on the list were reviewed or a PR was opened to address the issue.

Anything left unchecked still needs to be be reviewed and possibly updated. Note, the reference docs are mostly autogenerated and do not need to be updated.
/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
I've reviewed the hackmd file and it looks like the only section of the docs that hasn't been reviewed is the section. There is a PR open that addresses the page weights of files for the folders in the Tasks section, But there has not been a review for any of the pages within any of the folders. This is a rather large section of the docs and will definitely need to have page weights adjusted in some areas.
Hi Do you have a script to check the current weights ? if then, I think we could check remaining tasks for this issue. :)
Yes I have, but the script is not clean at all. If you need it immediately, I can upload(or send) the script right now. If not, I'll send it to you after refactoring.
It is just for checking remaining tasks :) no need to hurry :)
I've been working on making PRs to finish this issue up. The largest section left to do is the Tasks section. I plan to have PRs to cover those updates this week. Sorry i've left off wrapping this up for so long, but hopefully we can get all the page weights updated in english soon
I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. Feel free to reopen this issue if necessary. /close
Closing this issue. <detailsIn response to : I think we've made enough effort to arrange the page weights. Even though there is a possibility a few pages are not updated correctly, I think we can assume it can be caught by additional issues. So, I am going to close this issue as completed. </details


Question: <ins> --- title: 파이널라이저 content_type: concept weight: 60 --- <!-- overview --> {{<glossary_definition term_id="finalizer" length="long">}} 파이널라이저(Finalizer)를 사용하면 리소스를 삭제하기 전 특정 정리 작업을 수행하도록 {{<glossary_tooltip term_id="controller">}}에 경고하여 리소스의 {{<glossary_tooltip term_id="garbage-collection">}}을 제어할 수 있다. 파이널라이저는 보통 실행할 코드를 지정하지 않는다. 대신 파이널라이저는 일반적으로 어노테이션과 비슷하게 특정 리소스에 대한 키들의 목록이다. 일부 파이널라이저는 쿠버네티스가 자동으로 지정하지만, 사용자가 직접 지정할 수도 있다. ## 파이널라이저의 작동 방식 매니페스트 파일을 사용해 리소스를 생성하면 `metadata.finalizers` 필드에 파이널라이저를 명시할 수 있다. 리소스를 삭제하려 할 때는 삭제 요청을 처리하는 API 서버가 `finalizers` 필드의 값을 인식하고 다음을 수행한다. * 삭제를 시작한 시각과 함께 `metadata.deletionTimestamp` 필드를 추가하도록 오브젝트를 수정한다. * 오브젝트의 `metadata.finalizers` 필드가 비워질 때까지 오브젝트가 제거되지 않도록 한다. * `202` 상태 코드를 리턴한다(HTTP "Accepted"). 이 파이널라이저를 관리하는 컨트롤러는 `metadata.deletionTimestamp`를 설정하는 오브젝트가 업데이트 되었음을 인지하여 오브젝트의 삭제가 요청되었음을 나타낸다. 그런 다음 컨트롤러는 그 리소스에 지정된 파이널라이저의 요구사항을 충족하려 시도한다. 컨트롤러는 파이널라이저 조건이 충족될 때 마다 리소스의 `finalizers` 필드에서 해당 키(key)를 제거한다. `finalizers` 필드가 비워지면 `deletionTimestamp` 필드가 설정된 오브젝트는 자동으로 삭제된다. 또한 파이널라이저를 사용하여 관리되지 않는 리소스가 삭제되지 않도록 할 수 있다. 파이널라이저의 일반적인 예로는 `퍼시스턴트 볼륨(Persistent Volume)` 오브젝트가 실수로 삭제되는 것을 방지하는 `kubernetes.io/pv-protection`가 있다. 파드가 `퍼시스턴트 볼륨` 오브젝트를 사용 중일 때 쿠버네티스는 `pv-protection` 파이널라이저를 추가한다. `퍼시스턴트 볼륨`을 삭제하려 하면 `Terminating` 상태가 되지만 파이널라이저가 존재하기 때문에 컨트롤러가 삭제할 수 없다. 파드가 `퍼시스턴트 볼륨`의 사용을 중지하면 쿠버네티스가 `pv-protection` 파이널라이저를 해제하고 컨트롤러는 볼륨을 삭제한다. ## 소유자 참조, 레이블, 파이널라이저 {#소유자-레이블-파이널라이저} {{<glossary_tooltip term_id="label">}}와 마찬가지로 쿠버네티스에서 [소유자 참조(Owner reference)](/docs/concepts/overview/working-with-objects/owners-dependents/)는 오브젝트 간의 관계를 설명하지만 다른 목적으로 사용된다. {{<glossary_tooltip term_id="controller">}}가 파드와 같은 오브젝트를 관리할 때 레이블을 사용하여 관련 오브젝트의 그룹에 대한 변경 사항을 추적한다. 예를 들어 {{<glossary_tooltip term_id="job">}}이 하나 이상의 파드를 생성하면 잡 컨트롤러는 해당 파드에 레이블을 적용하고 클러스터 내 동일한 레이블을 갖는 파드에 대한 변경 사항을 추적한다. 또한, 잡 컨트롤러는 이러한 파드에 *소유자 참조*도 추가하여 파드를 생성한 잡을 가리킨다. 이 파드가 실행될 때 잡을 삭제하면 쿠버네티스는 사용자 참조(레이블 대신)를 사용하여 클러스터 내 어떤 파드가 정리되어야 하는지 결정한다. 쿠버네티스는 또한 삭제 대상 리소스에 대한 소유자 참조를 식별할 때 파이널라이저를 처리한다. 경우에 따라 파이널라이저는 종속 오브젝트의 삭제를 차단할 수 있으며 이로 인해 대상 소유자 오브젝트가 완전히 삭제되지 않고 예상보다 오래 유지될 수 있다. 이 경우 대상 소유자 및 종속 객체에 대한 파이널라이저와 소유자 참조를 확인해 원인을 해결해야 한다. {{<note>}} 오브젝트가 삭제 상태에 있는 경우, 삭제를 계속하려면 파이널라이저를 수동으로 제거해서는 안 된다. 일반적으로 파이널라이저는 특정한 목적으로 가지고 리소스에 추가되므로, 강제로 제거하면 클러스터에 문제가 발생할 수 있다. 이는 파이널라이저의 목적을 이해하고 다른 방법(예를 들어, 일부 종속 객체를 수동으로 정리하는 것)으로 수행될 때만 수행해야 한다. {{</note>}} ## {{% heading "whatsnext" %}} * 쿠버네티스 블로그에서 [파이널라이저를 사용해 삭제 제어하기](/blog/2021/05/14/using-finalizers-to-control-deletion/)를 읽어본다. </ins>

This is a Feature Request Korean Localization for branch. What would you like to be Any localization contributions for Korean. Comments This issue is to notify the schedule of Korean localization to contributors. is the current work branch for Korean localization. Important dates A Korean localization work branch is merged to branch after we complete around 3~4 weeks job. PR Freeze: 08/29 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 09/01 (merge to main branch) 3~4 , main . PR : 08/29 ( PR , PR ) : 09/01 (main , k8s.io ) /language ko /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 : ## In English is the current work branch for Korean localization.A Korean localization work branch is merged to branch after we complete around 3~4 weeks job. PR Freeze: 08/29 (PR opened after freeze will be requested to rebase to next work branch) Branch Merge: 09/01 (merge to main branch) PR : 08/29 ( PR , PR ) : 09/01 (main , k8s.io ) /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
/milestone dev-1.24-ko.3
, branch = branch branch off PR Netlify preview . : branch off PR Netlify preview . : commit cherry-pick , : ~ merge commit: ~ commit cherry-pick , ... ? : .
/triage accepted


Question: To apply Pod Security Standards to specific namespaces, refer to [Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss). <ins> If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, check the documentation for that version. </ins> ## {{% heading "prerequisites" %}} Install the following on your workstation:

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: Apply Pod Security Standards at the Cluster Level documents Pod Security admission defaults, but for Kubernetes v1.23 rather than any more recent release. Proposed Solution: Either: Edit to automatically render with the version of Kubernetes being documented Update for Kubernetes v1.24 Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /priority backlog /lifecycle frozen /triage accepted
What would need to change here? The Kubernetes minor version in the commands or also the version in the intro paragraph? (wouldn't that remain 1.23 since that's when the feature went beta?)
The tutorial shows you how to deploy a v1.23.x cluster; it should be v1.24. Maybe if we don't specify any version explicitly, that's good enough (I haven't checked, and I'm not very familiar with ). Making that version always match the latest release is left as an exercise for the reaser.
Hi, I have a question if we automatically render the Kubernetes version being documented for the page, would it be okay to mention something along the lines of : ? Thanks.
You can use this shortcode to show the version: See for an example.
Great, now I can try to work on this issue on the lines of the example. Thanks. /assign


Question: First, the user defines a new configuration containing only the `replicas` field: <del> {{< codenew file="application/ssa/nginx-deployment-replicas-only.yaml" >}} </del> <ins> ```yaml # Save this file as 'nginx-deployment-replicas-only.yaml'. apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 ``` {{< note >}} The YAML file for SSA in this case only contains the fields you want to change. You are not supposed to provide a fully compliant Deployment manifest if you only want to modify the `spec.replicas` field using SSA. {{< /note >}} </ins> The user applies that configuration using the field manager name `handover-to-hpa`: ```shell <del> kubectl apply -f https://k8s.io/examples/application/ssa/nginx-deployment-replicas-only.yaml  </del> <ins> kubectl apply -f nginx-deployment-replicas-only.yaml  </ins> --server-side --field-manager=handover-to-hpa  --validate=false ```

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

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


Question:
Learn with the Linux Foundation

The Linux Foundation offers instructor-led and self-paced courses for all aspects of the Kubernetes application development and operations lifecycle.

  See Courses

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


Question:
The legacy Linux package repositories (`apt.kubernetes.io` and `yum.kubernetes.io` AKA `packages.cloud.google.com`)
 have been frozen starting from September 13, 2023 **and are going away in January 2024**, users *must* migrate.
 Please read our [announcement](/blog/2023/08/31/legacy-package-repository-deprecation/) for more details.  - name: KubeCon 2024 EU startTime: 2024-02-16T00:00:00  #Added in https://github.com/kubernetes/website/pull/44828 endTime: 2024-03-22T18:00:00 style: >- background: linear-gradient(90deg, rgba(67,53,105,1) 0%, rgba(89,187,234,1) 100%); color: #fffff; title: |  KubeCon + CloudNativeCon Europe 2024 message: | Join us for four days of incredible opportunities to collaborate, learn and share with the cloud native community.
  Buy your ticket now! 19 - 22 March | Paris, France

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 Set a banner to announce KubeCon 2024 EU Why is this needed We usually turn on a banner for the upcoming KubeCon about 4 weeks ahead of the event, but I've had a request that we run it a bit earlier. Is 8 weeks possible? Logos are available from: (Note: be sure to copy the logo into this repo) should help with text. Also see the config from a previous year's KubeCon. Comments This change will need approval. I would like to set the banner to start on the Jan 26, 2024 and to end on the March 22, 2024 at 1800 CET (UTC+1). If 8 weeks isn't possible, the 4 week dates are Feb 23, 2024 to March 22, 2024. /priority important-soon
/triage accepted
It's worth noting that the existing banner is scheduled to run until Feb 1. Considering this, we might want to keep the KubeCon EU 2024 banner active after that date. How about initiating the banner from Feb 16? This would give us approximately a month (5 weeks) before KubeCon kicks off on March 19, 2024.
I want to help with this. /assign
PR is created to help with this request. Please do review whenever you have the time. Thanks in advance!
I'd appreciate 5 weeks too


Question: Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundation(CNCF)によってホストされています。 cards: - name: concepts  title: "基本を理解する"   title: "Kubernetesを理解する"  description: "Kubernetesとその基本的なコンセプトを学びます。" button: "コンセプトを学ぶ" button_path: "/docs/concepts"

This is a Feature Request Update Why is this needed Many people view this page. Updating the links on this page is useful for many people. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/assign /language ja /area localization
/triage accepted