Question:
This is a Bug Report Problem: The konnectivity docs: Include the following instruction: Setting to doesn't seem right: This will break authentication for all tokens that use the default audience value (taken from the value), which is most tokens. This will allow tokens with in them to authenticate directly to kube-apiserver. I don't think we want that. Instead, we should just depend on konnectivity-server specifying the right audience in . Also: is unlikely to be a valid value for . In practice is typically an URL. Proposed Solution: Instead of including incorrect flag values inline, just link out to the correct documentation at Page to Update:
/triage accepted
/assign cheftako
GitHub didn't allow me to assign the following users: jkh. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign jkh Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign jkh52
/cc
Hi thanks for pointing this out. I just wanted to link this issue with the unfinished discussion in BTW, wouldn't it be more correct to specify both audiences: - where is value for the cluster Please correct me if I'm wrong but do you suggest to specify already existing audience for konnectifity-server, eg. this one which is used in kubeadm clusters by default: - where is value for the cluster Agree on that. I have the following setup in my project right now: I'd like to change it to be more correct. Based on said above. I suppose we have few more options: All three configurations are working, now we need to choose the most correct one. Of course we can link to the documentation page, but as for now it has no any usable examples to allow user simple start using this. I'm not big fan of leaving user without proper examples because they will just start using random configuration which works. Let's define correct defaults instead. Other services (eg. istio, vault) can rely on this configuration snippets as well. From my point of view option C is the most correct, what do you think?
The audience is meant for the konnectivity server, not kube-apiserver directly, correct? In other words, seems like those tokens should require proxying through the konnectivity server, kube-apiserver shouldn't accept them directly? ( this was the impression I got in our offline conversation - did I get that right?) I'm suggesting we can probably just leave unset and let it inherit from .
This is what I'm proposing:
Okay this is option B, but this way we would need to configure konnectivity-server with the flag: And konnectivity-agent with the volume: would it be correct configuration, or maybe better to use separate audience (option C)?
My current understanding is that we can use , since the konnectivity-server can tell kube-apiserver which audiences to validate against when it makes the request, and those apparently don't have to match kube-apiserver's :
I agree that we should link to the canonical documentation for setting up service account token issuer vs copying it here. These are now required flags so widespread adoption is imminent. We should leave Konnectivity server configured with . This means that Konnectivity server identifies as and will only accept tokens that are meant for audience . We shouldn't add to kube-apiserver, because we don't want kube-apiserver to accept tokens meant for connectivity server. Looking at the other docs, we likely don't have enough documentation on how to pick a value for . isn't great. is slightly better. Ideally, this is a globally unique URL (i.e. no private DNS or IPs) that supports OIDC discovery. In GKE, this is something like for in project in location . EKS is something similar.
Oh, got it! I don't remember exact reason why I started using this flag, but I just checked and confirm that it is working fine without it. Suppose it was just a configuration mistake. I'll prepare PR to fix this.
/assign
Hi, I was copied in. How can I help?
you're member of , we need an approval for to get it merged.
Best thing usually is to contact the if a review is urgent / not happening. Although, this week I'm sharing cover for that. So, consider me informed. I'll take a look.

and direct the network traffic to the cluster nodes: 1. Make sure that <del> the `ServiceAccountTokenVolumeProjection` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. You can enable [service account token volume protection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) by providing the following flags to the kube-apiserver: ``` --service-account-issuer=api --service-account-signing-key-file=/etc/kubernetes/pki/sa.key --api-audiences=system:konnectivity-server ``` </del> <ins> [Service Account Token Volume Projection](/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) feature enabled in your cluster. It is enabled by default since Kubernetes v1.20. </ins> 1. Create an egress configuration file such as `admin/konnectivity/egress-selector-configuration.yaml`. 1. Set the `--egress-selector-config-file` flag of the API Server to the path of your API Server egress configuration file.


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Certain pages have the document.querySelector("body div.container-") element rendering much too wide. The header/nav is the proper width. <img width="1458" alt="Screen Shot 2021-11-15 at 11 19 42 AM" src="https://user-"Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--N/A <!--Additional Information:--Microsoft Edge Version 95.0.1020.40 (Official build) (x86_64) MacOS 11.6
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

} body { <del> display: grid; grid-column-template: auto; </del> header + .td-outer { min-height: 50vh; height: auto;


Question:
links to the wrong Anchor for the CSI Provisioner. It links to #csi-provisioner but should be linking to #vsphere-provisioner-csi Also the link referering to the vsphere CSI repository in delivers a HTTP 404 Status.
/kind bug /language en /triage accepted
/assign

There are two types of provisioners for vSphere storage classes: <del> - [CSI provisioner](#csi-provisioner): `csi.vsphere.vmware.com` </del> <ins> - [CSI provisioner](#vsphere-provisioner-csi): `csi.vsphere.vmware.com` </ins> - [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume` In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#csi-migration-5). #### CSI Provisioner {#vsphere-provisioner-csi} <del> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml). </del> <ins> The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml). </ins> #### vCP Provisioner


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

Used on: Namespaces <del> When the `NamespaceDefaultLabelName` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, the Kubernetes API server sets this label on all namespaces. The label value is set to the name of the namespace. </del> <ins> The Kubernetes API server (part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}) sets this label on all namespaces. The label value is set to the name of the namespace. You can't change this label's value. </ins> This is useful if you want to target a specific namespace with a label {{< glossary_tooltip text="selector" term_id="selector" >}}.


Question:
Why not use PowerShell Get-FileHash instead of certutil for getting/checking file hashes?
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/remove-lifecycle stale
/reopen
You can't reopen an issue/PR unless you authored it or you are a collaborator. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
-- makes sense. I've raised a PR here -

- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: ```powershell <del> $($(CertUtil -hashfile .kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .kubectl.exe.sha256) </del> <ins> $(Get-FileHash -Algorithm SHA256 .kubectl.exe).Hash -eq $(Get-Content .kubectl.exe.sha256) </ins> ``` 1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable.


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

## Accessing services running on the cluster <del> The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/access-application-cluster/access-cluster/) </del> <ins> The previous section describes how to connect to the Kubernetes API server. For information about connecting to other services running on a Kubernetes cluster, see [Access Cluster Services.](/docs/tasks/administer-cluster/access-cluster-services/) </ins> ## Requesting redirects


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

[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). User defined environment variables from the Pod definition are also available to the Container, <del> as are any environment variables specified statically in the Docker image. </del> <ins> as are any environment variables specified statically in the container image. </ins> ### Cluster information A list of all services that were running when a Container was created is available to that Container as environment variables. This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services. <del> Those environment variables match the syntax of Docker links. </del> For a service named *foo* that maps to a Container named *bar*, the following variables are defined:


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

what that means, check out the blog post [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). <ins> Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does. </ins> ### Why is dockershim being deprecated? Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.


Question:
This is a Bug Report In /content/zh/includes/user-guide-content- I think it's better to translate "user guide" into “”
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
File: /language zh
/assign
/triage accepted
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind feature

are being moved to the [Tasks](/docs/tasks/), [Tutorials](/docs/tutorials/), and [Concepts](/docs/concepts) sections. The content in this topic has moved to: --> <del> Kubernetes文档中[使用手册](/zh/docs/user-guide/)部分中的主题被移动到 </del> <ins> Kubernetes文档中[用户指南](/zh/docs/user-guide/)部分中的主题被移动到 </ins> [任务](/zh/docs/tasks/)、[教程](/zh/docs/tutorials/)和[概念](/zh/docs/concepts)节。 本主题内容已移至:


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/triage accepted

<ins> --- title: Podのオーバーヘッド content_type: concept weight: 30 --- <!-- overview --> {{< feature-state for_k8s_version="v1.18" state="beta" >}} PodをNode上で実行する時に、Pod自身は大量のシステムリソースを消費します。これらのリソースは、Pod内のコンテナ(群)を実行するために必要なリソースとして追加されます。Podのオーバーヘッドは、コンテナの要求と制限に加えて、Podのインフラストラクチャで消費されるリソースを計算するための機能です。 <!-- body --> Kubernetesでは、Podの[RuntimeClass](/docs/concepts/containers/runtime-class/)に関連するオーバーヘッドに応じて、[アドミッション](/ja/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)時にPodのオーバーヘッドが設定されます。 Podのオーバーヘッドを有効にした場合、Podのスケジューリング時にコンテナのリソース要求の合計に加えて、オーバーヘッドも考慮されます。同様に、Kubeletは、Podのcgroupのサイズ決定時およびPodの退役の順位付け時に、Podのオーバーヘッドを含めます。 ## Podのオーバーヘッドの有効化　{#set-up} クラスター全体で`PodOverhead`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)が有効になっていること（1.18時点ではデフォルトでオンになっています）と、`overhead`フィールドを定義する`RuntimeClass`が利用されていることを確認する必要があります。 ## 使用例 Podのオーバーヘッド機能を使用するためには、`overhead`フィールドが定義されたRuntimeClassが必要です。例として、仮想マシンとゲストOSにPodあたり約120MiBを使用する仮想化コンテナランタイムで、次のようなRuntimeClassを定義できます。 ```yaml --- kind: RuntimeClass apiVersion: node.k8s.io/v1 metadata: name: kata-fc handler: kata-fc overhead: podFixed: memory: "120Mi" cpu: "250m" ``` `kata-fc`RuntimeClassハンドラーを指定して作成されたワークロードは、リソースクォータの計算や、Nodeのスケジューリング、およびPodのcgroupのサイズ決定にメモリーとCPUのオーバーヘッドが考慮されます。 次のtest-podのワークロードの例を実行するとします。 ```yaml apiVersion: v1 kind: Pod metadata: name: test-pod spec: runtimeClassName: kata-fc containers: - name: busybox-ctr image: busybox stdin: true tty: true resources: limits: cpu: 500m memory: 100Mi - name: nginx-ctr image: nginx resources: limits: cpu: 1500m memory: 100Mi ``` アドミッション時、RuntimeClass[アドミッションコントローラー](/docs/reference/access-authn-authz/admission-controllers/)は、RuntimeClass内に記述された`オーバーヘッド`を含むようにワークロードのPodSpecを更新します。もし既にPodSpec内にこのフィールドが定義済みの場合、そのPodは拒否されます。この例では、RuntimeClassの名前しか指定されていないため、アドミッションコントローラーは`オーバーヘッド`を含むようにPodを変更します。 RuntimeClassのアドミッションコントローラーの後、更新されたPodSpecを確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.overhead}' ``` 出力は次の通りです: ``` map[cpu:250m memory:120Mi] ``` ResourceQuotaが定義されている場合、コンテナ要求の合計と`オーバーヘッド`フィールドがカウントされます。 kube-schedulerが新しいPodを実行すべきNodeを決定する際、スケジューラーはそのPodの`オーバーヘッド`と、そのPodに対するコンテナ要求の合計を考慮します。この例だと、スケジューラーは、要求とオーバーヘッドを追加し、2.25CPUと320MiBのメモリを持つNodeを探します。 PodがNodeにスケジュールされると、そのNodeのkubeletはPodのために新しい{{< glossary_tooltip text="cgroup" term_id="cgroup" >}}を生成します。基盤となるコンテナランタイムがコンテナを作成するのは、このPod内です。 リソースにコンテナごとの制限が定義されている場合(制限が定義されているGuaranteed QoSまたはBustrable QoS)、kubeletはそのリソース(CPUはcpu.cfs_quota_us、メモリはmemory.limit_in_bytes)に関連するPodのcgroupの上限を設定します。この上限は、コンテナの制限とPodSpecで定義された`オーバーヘッド`の合計に基づきます。 CPUについては、PodがGuaranteedまたはBurstable QoSの場合、kubeletはコンテナの要求の合計とPodSpecに定義された`オーバーヘッド`に基づいて`cpu.share`を設定します。 次の例より、ワークロードに対するコンテナの要求を確認できます。 ```bash kubectl get pod test-pod -o jsonpath='{.spec.containers[*].resources.limits}' ``` コンテナの要求の合計は、CPUは2000m、メモリーは200MiBです。 ``` map[cpu: 500m memory:100Mi] map[cpu:1500m memory:100Mi] ``` Nodeで観測される値と比較してみましょう。 ```bash kubectl describe node | grep test-pod -B2 ``` 出力では、2250mのCPUと320MiBのメモリーが要求されており、Podのオーバーヘッドが含まれていることが分かります。 ``` Namespace                   Name                CPU Requests  CPU Limits   Memory Requests  Memory Limits  AGE ---------                   ----                ------------  ----------   ---------------  -------------  --- default                     test-pod            2250m (56%)   2250m (56%)  320Mi (1%)       320Mi (1%)     36m ``` ## Podのcgroupの制限を確認 ワークロードで実行中のNode上にある、Podのメモリーのcgroupを確認します。次に示す例では、CRI互換のコンテナランタイムのCLIを提供するNodeで[`crictl`](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)を使用しています。これはPodのオーバーヘッドの動作を示すための高度な例であり、ユーザーがNode上で直接cgroupsを確認する必要はありません。 まず、特定のNodeで、Podの識別子を決定します。 ```bash # PodがスケジュールされているNodeで実行 POD_ID="$(sudo crictl pods --name test-pod -q)" ``` ここから、Podのcgroupのパスが決定します。 ```bash # PodがスケジュールされているNodeで実行 sudo crictl inspectp -o=json $POD_ID | grep cgroupsPath ``` 結果のcgroupパスにはPodの`ポーズ中`コンテナも含まれます。Podレベルのcgroupは１つ上のディレクトリです。 ``` "cgroupsPath": "/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/7ccf55aee35dd16aca4189c952d83487297f3cd760f1bbf09620e206e7d0c27a" ``` 今回のケースでは、Podのcgroupパスは、`kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2`となります。メモリーのPodレベルのcgroupの設定を確認しましょう。 ```bash # PodがスケジュールされているNodeで実行 # また、Podに割り当てられたcgroupと同じ名前に変更 cat /sys/fs/cgroup/memory/kubepods/podd7f4b509-cf94-4951-9417-d1087c92a5b2/memory.limit_in_bytes ``` 予想通り320MiBです。 ``` 335544320 ``` ### Observability Podのオーバヘッドが利用されているタイミングを特定し、定義されたオーバーヘッドで実行されているワークロードの安定性を観察するため、[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics)には`kube_pod_overhead`というメトリクスが用意されています。この機能はv1.9のkube-state-metricsでは利用できませんが、次のリリースで期待されています。それまでは、kube-state-metricsをソースからビルドする必要があります。 ## {{% heading "whatsnext" %}} * [RuntimeClass](/ja/docs/concepts/containers/runtime-class/) * [Podのオーバーヘッドの設計](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) </ins>


Question:
There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign

`Guaranteed` pods are guaranteed only when requests and limits are specified for all the containers and they are equal. These pods will never be evicted because of another pod's resource consumption. If a system daemon (such as `kubelet`, <del> `docker`, and `journald`) is consuming more resources than were reserved via </del> <ins> and `journald`) is consuming more resources than were reserved via </ins> `system-reserved` or `kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` pods using less resources than requests left on it, then the kubelet must choose to evict one of these pods to preserve node stability


Question:
There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign

--> 仅当 `Guaranteed` Pod 中所有容器都被指定了请求和限制并且二者相等时，才保证 Pod 不被驱逐。 这些 Pod 永远不会因为另一个 Pod 的资源消耗而被驱逐。 <del> 如果系统守护进程（例如 `kubelet`、`docker` 和 `journald`） </del> <ins> 如果系统守护进程（例如 `kubelet` 和 `journald`） </ins> 消耗的资源比通过 `system-reserved` 或 `kube-reserved` 分配保留的资源多， 并且该节点只有 `Guaranteed` 或 `Burstable` Pod 使用的资源少于其上剩余的请求， 那么 kubelet 必须选择驱逐这些 Pod 中的一个以保持节点稳定性并减少资源匮乏对其他 Pod 的影响。


Question:
There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign

title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 <del> full_link: /zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。


Question:
There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign

title: Pod Priority id: pod-priority date: 2019-01-31 <del> full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority </del> <ins> full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority </ins> short_description: > Pod Priority indicates the importance of a Pod relative to other Pods.


Question:
There is a bug: ,%E8%AE%BE%E4%B8%BA%20%2D997%E3%80%82 ""'s hyperlink status is 404, it should be changed to ""
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language zh /kind bug
/assign

<!--more--> <!-- <del> [Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. </del> <ins> [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. </ins> --> <del> [Pod 优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority) </del> <ins> [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) </ins> 允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 工作负载而言是一个重要的特性。


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

The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them.  PR wranglers should close issues after 14-30 days of inactivity. {{< /note >}} <ins> ## PR Wrangler shadow program In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program was introduced to help new contributors understand the PR wrangling process. ### Become a shadow - If you are interested in shadowing as a PR wrangler, please visit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) to see the PR wrangling schedule for this year and sign up. - Kubernetes org members can edit the [PR Wranglers Wiki page](https://github.com/kubernetes/website/wiki/PR-Wranglers) and sign up to shadow an existing PR Wrangler for a week. - Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership). - Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io). </ins>  No newline at end of file


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

{{< warning >}} <del> Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. </del> <ins> Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. </ins> If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script. {{< /warning>}}


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

Create a directory named `config-exercise`. In your `config-exercise` directory, create a file named `config-demo` with this content: <del> ```shell </del> <ins> ```yaml </ins> apiVersion: v1 kind: Config preferences: {}


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

### Linux ```shell <del> export KUBECONFIG_SAVED=$KUBECONFIG </del> <ins> export KUBECONFIG_SAVED="$KUBECONFIG" </ins> ``` ### Windows PowerShell


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 </del> <ins> export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" </ins> ``` ### Windows PowerShell


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config </del> <ins> export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config" </ins> ``` ### Windows Powershell


Question:
Setting KUBECONFIG variable doesn't work very well on macOS (Monterey 12.2.1). In the line: The first colon (:) will make the following character (c) dissappear: What I get is the mangled text: What works for me better is explicitly using full paths:
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Thanks for reporting, I can open a PR to fix this! /remove-lifecycle stale /assign

### Linux ```shell <del> export KUBECONFIG=$KUBECONFIG_SAVED </del> <ins> export KUBECONFIG="$KUBECONFIG_SAVED" </ins> ``` ### Windows PowerShell


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
/retitle [ja] Translate /docs/reference/scheduling/policies/ into Japanese
Re-titling can only be requested by trusted users, like repository collaborators. <detailsIn response to : /retitle [ja] Translate /docs/reference/scheduling/policies/ into Japanese Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/retitle [ja] Translate /docs/reference/scheduling/policies/ into Japanese
/triage accepted

<ins> --- title: スケジューリングポリシー content_type: concept sitemap: priority: 0.2 # スケジューリングポリシーは廃止されました。 --- <!-- overview --> バージョンv1.23より前のKubernetesでは、スケジューリングポリシーを使用して、*predicates*と*priorities*の処理を指定することができました。例えば、`kube-scheduler --policy-config-file <filename>`または`kube-scheduler --policy-configmap <ConfigMap>`を実行すると、スケジューリングポリシーを設定することが可能です。 このスケジューリングポリシーは、バージョンv1.23以降のKubernetesではサポートされていません。関連するフラグである、`policy-config-file`、`policy-configmap`、`policy-configmap-namespace`、`use-legacy-policy-config`も同様にサポートされていません。 代わりに、[スケジューラー設定](/ja/docs/reference/scheduling/config/)を使用してください。 ## {{% heading "whatsnext" %}} * [スケジューリング](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * [kube-scheduler設定](/ja/docs/reference/scheduling/config/)について学ぶ * [kube-scheduler設定リファレンス(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)について読む </ins>


Question:
In the v1beta1 admission config example, I had to use rather than See
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Page:
/sig auth /language en /assign

# Array of authenticated usernames to exempt. usernames: [] # Array of runtime class names to exempt. <del> runtimeClassNames: [] </del> <ins> runtimeClasses: [] </ins> # Array of namespaces to exempt. namespaces: [] ```


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

the YAML: `192.0.2.42:9376` (TCP). {{< note >}} <del> The Kubernetes API server does not allow proxying to endpoints that are not mapped to pods. Actions such as `kubectl proxy <service-name>` where the service has no selector will fail due to this constraint. This prevents the Kubernetes API server from being used as a proxy to endpoints the caller may not be authorized to access. </del> <ins> The Kubernetes API server does not allow proxying to endpoints that are not mapped to pods. Actions such as `kubectl proxy <service-name>` where the service has no selector will fail due to this constraint. This prevents the Kubernetes API server from being used as a proxy to endpoints the caller may not be authorized to access. </ins> {{< /note >}} An ExternalName Service is a special case of Service that does not have


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

Later in this page you can read about various kube-proxy implementations work. Overall, you should note that, when running `kube-proxy`, kernel level rules may be <del> modified (for example, iptables rules might get created), which won't get cleaned up, </del> <ins> modified (for example, iptables rules might get created), which won't get cleaned up, </ins> in some cases until you reboot.  Thus, running kube-proxy is something that should only be done by an administrator which understands the consequences of having a low level, privileged network proxying service on a computer.  Although the `kube-proxy`


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup.  For example, if your operating system doesn't allow you to run iptables commands, the standard kernel kube-proxy implementation will not work.  Likewise, if you have an operating system which doesn't support `netsh`, it will not run in Windows userspace mode. ### User space proxy mode {#proxy-mode-userspace} <ins> {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} </ins> In this (legacy) mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

other versions of Kubernetes, check the documentation for that release. By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses the cloud provider's default load balancer implementation if the cluster is configured with <del> a cloud provider using the `--cloud-provider` component flag. </del> <ins> a cloud provider using the `--cloud-provider` component flag. </ins> If `spec.loadBalancerClass` is specified, it is assumed that a load balancer implementation that matches the specified class is watching for Services. Any default load balancer implementation (for example, the one provided by the cloud provider) will ignore Services that have this field set. `spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. <del> Once set, it cannot be changed. </del> <ins> Once set, it cannot be changed. </ins> The value of `spec.loadBalancerClass` must be a label-style identifier, with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". Unprefixed names are reserved for end-users.


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" # A list of existing security groups to be configured on the ELB created. Unlike the annotation <del> # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation </del> <ins> # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation </ins> # of a uniquely generated security group for this ELB. # The first security group ID on this list is used as a source to permit incoming traffic to target worker nodes (service traffic and health checks). # If multiple ELBs are configured with the same security group ID, only a single permit line will be added to the worker node security groups, that means if you delete any


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: marks the userspace kube-proxy as deprecated. This was missed from the v1.23 docs updates and . Proposed Solution: Mark the kube-proxy in userspace mode as deprecated. Page to Update: <!--Additional Information:--/sig network /language en /priority important-longterm
/lifecycle frozen /triage accepted
/assign

service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" #  A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). <del> # Security groups defined here can be shared between services. </del> <ins> # Security groups defined here can be shared between services. </ins> service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used


Question:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Translate into Japanese. Why is this needed This page has not been translated. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja /assign
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details

<ins> --- title: Podのセキュリティアドミッション content_type: concept weight: 20 min-kubernetes-server-version: v1.22 --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="beta" >}} Kubernetesの[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/)はPodに対して異なる分離レベルを定義します。 これらの標準によって、Podの動作をどのように制限したいかを、明確かつ一貫した方法で定義することができます。 ベータ版機能として、Kubernetesは[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)の後継である組み込みの _Pod Security_ {{< glossary_tooltip text="アドミッションコントローラー" term_id="admission-controller" >}}を提供しています。 Podセキュリティの制限は、Pod作成時に{{< glossary_tooltip text="名前空間" term_id="namespace" >}}レベルで適用されます。 {{< note >}} PodSecurityPolicy APIは非推奨であり、v1.25でKubernetesから[削除](/docs/reference/using-api/deprecation-guide/#v1-25)される予定です。 {{< /note >}} <!-- body --> ## `PodSecurity`アドミッションプラグインの有効化 {#enabling-the-podsecurity-admission-plugin} v1.23において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はベータ版の機能で、デフォルトで有効化されています。 v1.22において、`PodSecurity`の[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)はアルファ版の機能で、組み込みのアドミッションプラグインを使用するには、`kube-apiserver`で有効にする必要があります。 ```shell --feature-gates="...,PodSecurity=true" ``` ## 代替案:`PodSecurity`アドミッションwebhookのインストール {#webhook} クラスターがv1.22より古い、あるいは`PodSecurity`機能を有効にできないなどの理由で、ビルトインの`PodSecurity`アドミッションプラグインが使えない環境では、`PodSecurity`はアドミッションロジックはベータ版の[validating admission webhook](https://git.k8s.io/pod-security-admission/webhook)としても提供されています。 ビルド前のコンテナイメージ、証明書生成スクリプト、マニフェストの例は、[https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook)で入手可能です。 インストール方法: ```shell git clone git@github.com:kubernetes/pod-security-admission.git cd pod-security-admission/webhook make certs kubectl apply -k . ``` {{< note >}} 生成された証明書の有効期限は2年間です。有効期限が切れる前に、証明書を再生成するか、内蔵のアドミッションプラグインを使用してWebhookを削除してください。 {{< /note >}} ## Podのセキュリティレベル {#pod-security-levels} Podのセキュリティアドミッションは、Podの[Security Context](/docs/tasks/configure-pod-container/security-context/)とその他の関連フィールドに、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)で定義された3つのレベル、`privileged`、`baseline`、`restricted`に従って要件を設定するものです。 これらの要件の詳細については、[Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards)のページを参照してください。 ## Podの名前空間に対するセキュリティアドミッションラベル {#pod-security-admission-labels-for-namespaces} この機能を有効にするか、Webhookをインストールすると、名前空間を設定して、各名前空間でPodセキュリティに使用したいadmission controlモードを定義できます。 Kubernetesは、名前空間に使用したい定義済みのPodセキュリティの標準レベルのいずれかを適用するために設定できる{{< glossary_tooltip term_id="label" text="ラベル" >}}のセットを用意しています。 選択したラベルは、以下のように違反の可能性が検出された場合に{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}が取るアクションを定義します。 {{< table caption="Podのセキュリティアドミッションのモード" >}} モード | 説明 :---------|:------------ **enforce** | ポリシーに違反した場合、Podは拒否されます。 **audit** | ポリシー違反は、[監査ログ](/ja/docs/tasks/debug-application-cluster/audit/)に記録されるイベントに監査アノテーションを追加するトリガーとなりますが、それ以外は許可されます。 **warn** | ポリシーに違反した場合は、ユーザーへの警告がトリガーされますが、それ以外は許可されます。 {{< /table >}} 名前空間は、任意のまたはすべてのモードを設定することができ、異なるモードに対して異なるレベルを設定することもできます。 各モードには、使用するポリシーを決定する2つのラベルがあります。 ```yaml # モードごとのレベルラベルは、そのモードに適用するポリシーレベルを示す。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # LEVELは`privileged`、`baseline`、`restricted`のいずれかでなければならない。 pod-security.kubernetes.io/<MODE>: <LEVEL> # オプション: モードごとのバージョンラベルは、Kubernetesのマイナーバージョンに同梱される # バージョンにポリシーを固定するために使用できる（例えばv{{< skew latestVersion >}}など）。 # # MODEは`enforce`、`audit`、`warn`のいずれかでなければならない。 # VERSIONは有効なKubernetesのマイナーバージョンか`latest`でなければならない。 pod-security.kubernetes.io/<MODE>-version: <VERSION> ``` [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)で使用例を確認できます。 ## WorkloadのリソースとPodテンプレート {#workload-resources-and-pod-templates} Podは、{{< glossary_tooltip term_id="deployment" >}}や{{< glossary_tooltip term_id="job">}}のような[ワークロードオブジェクト](/ja/docs/concepts/workloads/controllers/)を作成することによって、しばしば間接的に生成されます。 ワークロードオブジェクトは_Pod template_を定義し、ワークロードリソースの{{< glossary_tooltip term_id="controller" text="コントローラー" >}}はそのテンプレートに基づきPodを作成します。 違反の早期発見を支援するために、auditモードとwarningモードは、ワークロードリソースに適用されます。 ただし、enforceモードはワークロードリソースには**適用されず**、結果としてのPodオブジェクトにのみ適用されます。 ## 適用除外(Exemption) {#exemptions} Podセキュリティの施行から _exemptions_ を定義することで、特定の名前空間に関連するポリシーのために禁止されていたPodの作成を許可することができます。 Exemptionは[アドミッションコントローラーの設定](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller)で静的に設定することができます。 Exemptionは明示的に列挙する必要があります。 Exemptionを満たしたリクエストは、アドミッションコントローラーによって _無視_ されます(`enforce`、`audit`、`warn`のすべての動作がスキップされます)。Exemptionの次元は以下の通りです。 - **Usernames:** 認証されていない(あるいは偽装された)ユーザー名を持つユーザーからの要求は無視されます。 - **RuntimeClassNames:** Podと[ワークロードリソース](#workload-resources-and-pod-templates)で指定された除外ランタイムクラス名は、無視されます。 - **Namespaces:** 除外された名前空間のPodと[ワークロードリソース](#workload-resources-and-pod-templates)は、無視されます。 {{< caution >}} ほとんどのPodは、[ワークロードリソース](#workload-resources-and-pod-templates)に対応してコントローラーが作成します。つまり、エンドユーザーを適用除外にするのはPodを直接作成する場合のみで、ワークロードリソースを作成する場合は適用除外になりません。 コントローラーサービスアカウント(`system:serviceaccount:kube-system:replicaset-controller`など)は通常、除外してはいけません。そうした場合、対応するワークロードリソースを作成できるすべてのユーザーを暗黙的に除外してしまうためです。 {{< /caution >}} 以下のPodフィールドに対する更新は、ポリシーチェックの対象外となります。つまり、Podの更新要求がこれらのフィールドを変更するだけであれば、Podが現在のポリシーレベルに違反していても拒否されることはありません。 - すべてのメタデータの更新(seccompまたはAppArmorアノテーションへの変更を**除く**) - `seccomp.security.alpha.kubernetes.io/pod`(非推奨) - `container.seccomp.security.alpha.kubernetes.io/*`(非推奨) - `container.apparmor.security.beta.kubernetes.io/*` - `.spec.activeDeadlineSeconds`に対する有効な更新 - `.spec.tolerations`に対する有効な更新 ## {{% heading "whatsnext" %}} - [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards) - [Podセキュリティの標準の適用](/docs/setup/best-practices/enforcing-pod-security-standards) - [ビルトインのアドミッションコントローラーの設定によるPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-admission-controller) - [名前空間ラベルでのPodセキュリティの標準の適用](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) - [PodSecurityPolicyからビルトインのPodSecurityアドミッションコントローラーへの移行](/docs/tasks/configure-pod-container/migrate-from-psp) </ins>


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

[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). <del> It is enabled by default. </del> When enabled, the control plane tracks new Jobs using the behavior described below. Jobs created before the feature was enabled are unaffected. As a user,


Question:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The link at the top of the homepage () seems to currently redirect to I assume this is the same issue as Proposed Solution: Remove the /dockershim alias from the ZH blog page. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Same symptoms, different PR. /triage accepted Thanks. /priority important-soon
/assign

title: "弃用 Dockershim 的常见问题" date: 2020-12-02 slug: dockershim-faq <del> aliases: [ '/dockershim' ] </del> <ins> aliases: [ '/zh/dockershim' ] </ins> --- <!-- layout: blog


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

criSocket: "/var/run/dockershim.sock"   taints:     - key: "kubeadmNode"        value: "master"         value: "someValue"        effect: "NoSchedule"   kubeletExtraArgs:     v: 4


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

tlsBootstrapToken is a token used for TLS bootstrapping.  If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, but can be overridden. If file is set, this field must be set in case the KubeConfigFile does not   If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, but can be overridden. If file is set, this field must be set in case the KubeConfigFile does not  contain any other authentication information.


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

string
criSocket is used to retrieve container runtime information. This information will
criSocket is used to retrieve container runtime information. This information will  be annotated to the Node API object, for later re-use.


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

taints specifies the taints the Node API object should be registered with.  If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to 'node-role.kubernetes.io/master=""'. If you don't want to taint your control-plane node, set this field to an empty list, i.e. taints: [] in the YAML file. This field is   If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list, i.e. taints: [], in the YAML file. This field is  solely used for Node registration.


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

criSocket: "/var/run/dockershim.sock"   taints:   - key: "kubeadmNode"      value: "master"       value: "someValue"      effect: "NoSchedule"   kubeletExtraArgs:     v: 4


Question:
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: while cleaning up mentions of the legacy "master" taint in kubeadm docs: saw the following: it seems the generated reference API docs for kubeadm still include the "master" taint. Proposed Solution: cleanup mentions of the old taint from kubeadm's API reference docs at perhaps these need to be synced with: for dev-1.25 and main at k/website we removed the old taint from there before 1.24 was released. 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
/sig cluster-lifecycle /priority important-soon /kind cleanup
cc

tains specifies the taints the Node API object should be registered with.  If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to taints: ["node-role.kubernetes.io/master:""]. If you don't want to taint your control-plane node, set this field to an empty slice,   If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with a control-plane taint for control-plane nodes. If you don't want to taint your control-plane node, set this field to an empty list,  i.e. taints: [] in the YAML file. This field is solely used for Node registration.


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

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:


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

1. Create a cluster with no Pod Security Standards applied: ```shell <del> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 </del> <ins> kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0 </ins> ``` The output is similar to this: ``` Creating cluster "psa-wo-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹


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

these Pod Security Standards: ```shell <del> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml </del> <ins> kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml </ins> ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... <del> ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 </del> <ins> ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 </ins> ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹


Question:
Simple documentation issue: Section for "CertificateSubjectRestriction" admission controller is "CertificateSubjectRestrictions". The appended 's' is not valid and will prevent apiserver startup if used in --disable-admission-plugins. Note: plugin is listed correctly in the 'defaults' list.
Fixed by /close
Closing this issue. <detailsIn response to : Fixed by /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
/triage accepted /language en

See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more information on the permissions required to perform different actions on CertificateSigningRequest resources. <del> ### CertificateSubjectRestrictions {#certificatesubjectrestrictions} </del> <ins> ### CertificateSubjectRestriction {#certificatesubjectrestriction} </ins> This admission controller observes creation of CertificateSigningRequest resources that have a `spec.signerName` of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute')


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

* [Removing Dockershim from kubelet](https://github.com/kubernetes/enhancements/issues/2221): the Container Runtime Interface (CRI) for Docker (i.e. Dockershim) is currently a built-in container runtime in the kubelet code base. It was deprecated in v1.20. As of v1.24, the kubelet will no longer have dockershim. Check out this blog on [what you need to do be ready for v1.24](/blog/2022/03/31/ready-for-dockershim-removal/). * [Storage capacity tracking for pod scheduling](https://github.com/kubernetes/enhancements/issues/1472): The CSIStorageCapacity API supports exposing currently available storage capacity via CSIStorageCapacity objects and enhances scheduling of pods that use CSI volumes with late binding. In v1.24, the CSIStorageCapacity API will be stable. The API graduating to stable initates the deprecation of the v1beta1 CSIStorageCapacity API. Refer to the [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1472-storage-capacity-tracking) for more information. * [The `master` label is no longer present on kubeadm control plane nodes](https://github.com/kubernetes/kubernetes/pull/107533). For new clusters, the label 'node-role.kubernetes.io/master' will no longer be added to control plane nodes, only the label 'node-role.kubernetes.io/control-plane' will be added. For more information, refer to [KEP-2067: Rename the kubeadm "master" label and taint](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint). <del> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, entered beta in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.21 and is now unsupported. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and [kubernetes-csi/external-snapshotter](https://github.com/kubernetes-csi/external-snapshotter/releases/tag/v4.1.0) for more information. </del> <ins> * [VolumeSnapshot v1beta1 CRD will be removed](https://github.com/kubernetes/enhancements/issues/177). Volume snapshot and restore functionality for Kubernetes and the [Container Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI), which provides standardized APIs design (CRDs) and adds PV snapshot/restore support for CSI volume drivers, moved to GA in v1.20. VolumeSnapshot v1beta1 was deprecated in v1.20 and will become unsupported with the v1.24 release. Refer to [KEP-177: CSI Snapshot](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/177-volume-snapshot#kep-177-csi-snapshot) and the [Volume Snapshot GA blog](/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga/) blog article for more information. </ins> ## What to do


Question:
Just above this anchor #node-affinity-per-scheduling-profile, the note block is referring to the Pod spec pod-with-node- 2 above, but it's placement appears to refer to the one immediately above. It takes a little bouncing around the page to sort it out :)
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

requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: topology.kubernetes.io/zone </del> <ins> - key: kubernetes.io/os </ins> operator: In values: <del> - antarctica-east1 - antarctica-west1 </del> <ins> - linux </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:


Question:
Just above this anchor #node-affinity-per-scheduling-profile, the note block is referring to the Pod spec pod-with-node- 2 above, but it's placement appears to refer to the one immediately above. It takes a little bouncing around the page to sort it out :)
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

requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: <del> - key: kubernetes.io/os </del> <ins> - key: topology.kubernetes.io/zone </ins> operator: In values: <del> - linux </del> <ins> - antarctica-east1 - antarctica-west1 </ins> preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference:


Question:
Description of Node Affinity example pod spec "pods/pod-with-node-" contains an error: does not apply. The spec shows instead that key "" should be "". Under the Node Affinity Weight section, the following note is also out-of-place: It needs to be moved to the previous section.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is a duplicate of . /triage duplicate


Question:
Description of Node Affinity example pod spec "pods/pod-with-node-" contains an error: does not apply. The spec shows instead that key "" should be "". Under the Node Affinity Weight section, the following note is also out-of-place: It needs to be moved to the previous section.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This issue is a duplicate of . /triage duplicate