Question: This includes any Pods created using `kubectl`, or indirectly via a replication controller. It does not include Pods created as a result of the kubelet `--manifest-url` flag, its `--config` flag, or its REST API (these are <del> not common ways to create Pods.) </del> <ins> not common ways to create Pods). The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a Secret or any other API objects. </ins> Secrets must be created before they are consumed in Pods as environment variables unless they are marked as optional. References to secrets that do

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I saw an out-of-tree product mention that static pods "can not use" ConfigMaps and Secrets. I was unaware of such a prohibition. I went looking in the k8s website. I spent a lot of time not finding any mention of such a restriction. For example: mentions static pods but not the restriction; describes ConfigMap and Secret type volumes but does not mention the restriction; the Go sources for the relevant API types do not mention the restriction (). I eventually found the restriction wrt ConfigMap mentioned in , but I think it should not appear only there. Proposed Solution: Update either or both of the first two pages I cited that currently lack the restriction. Update the API types to mention the restriction. Page to Update: Listed above. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/triage accepted
I can work on this one. Thanks. /assign
I just realized there is an additional --- and more severe --- restriction on static pods. They can not have a ! As a corollary, they are not given a by default. For example, using a static pod: ... note that there is no ! is one place where this would be relevant.
The prohibition is even broader and simpler: the definition of a static pod can not refer to any other API object. For example, PersistentVolumeClaim is another thing that a static pod's definition can not reference.


Question: {{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}

This is a Bug Report Problem: The following pages under are currently manually maintained. It is expected that each generated page under has at least one link to it from these files, otherwise it becomes orphaned. The following pages are orphaned: Proposed Solution: Add links to these generated pages.
Thanks /sig cluster-lifecycle /triage accepted /kind cleanup /language en /priority backlog
We could instead use Docsy's automatic list generation, and add descriptions to each page (eg, to the front matter of ).
is marked as deprecated in 1.20, so i assume the generation for it will be skipped (the command will be hidden). the command is graduated as . the graduation and missing is covered here: the rest are indeed missing. is there a way to catch this during CI of website PRs? i don't know how Docsy works, but would appreciate ideas around this as manually maintaining the subcommands is not ideal.
Hmm, looking at this a bit more just setting a might not be enough. The current pages are a mix of generated and manually written ones. There are a few different ways to combine these. It sounds like extending the generator could help there - that could be a separate feature request against the generator code, eg to warn if a subcommand isn't documented as expected.
i think we could do the following: on the main pages that are currently manually maintained for etc, "include" the parent generated page () the generated page could have relative hyperlinks to the generated pages of sub-sub-commands (e.g. having links to , and this can reveal the whole tree relation between sub-commands and sub-sub-commands (and deeper). this means that ideally the generated pages should have a title on top too: and a section for the sub-commands. EDIT: and if the kubeadm commands lack sufficient information it should be in the source code of kubeadm. would navigating around /generated pages sound like a good idea? e.g.
that sounds like a plan. BTW, if the generator has the smarts to add metadata into generated Markdown (eg: a YAML list of subcommands, in front matter) then we can implement a Hugo layout that automatically processes that metadata into HTML. I can probably help with this approach, if selected.


Question: {{< tabs name="tab-phase" >}} {{< tab name="phase" include="generated/kubeadm_upgrade_node_phase.md" />}} <ins> {{< tab name="preflight" include="generated/kubeadm_upgrade_node_phase_preflight.md" />}} </ins> {{< tab name="control-plane" include="generated/kubeadm_upgrade_node_phase_control-plane.md" />}} {{< tab name="kubelet-config" include="generated/kubeadm_upgrade_node_phase_kubelet-config.md" />}} {{< /tabs >}}

So you have options: more code in the docs generator, or less docs generator code but then more work for the Go templating.
given the subcommand relation is already described by the filenames: can Hugo just process that instead of requiring the metadata to be part of the markdown? i think i'm leaning towards the first option, but that is because i don't know much about Hugo. if the docs team and prefer the second option, we should go for that.
I'd rather not hard-code in a full path into the layout code, because I think that could be fragile when it doesn't need to be. If we can set some marker eg in the for each page where that applies, I think I could persuade Hugo to work out the rest of the details.
Let's fix it by following the current practices. We can file a new issue to track the improvement/automation.
LGTMed the PR, will add notes to thanks


Question: <ins> --- title: 在 macOS 系统上安装和设置 kubectl content_type: task weight: 10 card: name: tasks weight: 20 title: 在 macOS 系统上安装 kubectl --- <!-- --- reviewers: - mikedanese title: Install and Set Up kubectl on macOS content_type: task weight: 10 card: name: tasks weight: 20 title: Install kubectl on macOS --- --> ## {{% heading "prerequisites" %}} <!-- You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues. --> kubectl 版本和集群之间的差异必须在一个小版本号之内。 例如：v1.2 版本的客户端只能与 v1.1、v1.2 和 v1.3 版本的集群一起工作。 用最新版本的 kubectl 有助于避免不可预见的问题。 <!-- ## Install kubectl on macOS --> ## 在 macOS 系统上安装 kubectl {#install-kubectl-on-macos} <!-- The following methods exist for installing kubectl on macOS: --> 在 macOS 系统上安装 kubectl 有如下方法： - [{{% heading "prerequisites" %}}](#{{% heading "prerequisites" %}}) - [在 macOS 系统上安装 kubectl](#install-kubectl-on-macos) - [用 curl 在 macOS 系统上安装 kubectl](#install-kubectl-binary-with-curl-on-macos) - [用 Homebrew 在 macOS 系统上安装](#install-with-homebrew-on-macos) - [用 Macports 在 macOS 上安装](#install-with-macports-on-macos) - [作为谷歌云 SDK 的一部分，在 macOS 上安装](#install-on-macos-as-part-of-the-google-cloud-sdk) - [验证 kubectl 配置](#verify-kubectl-configuration) - [可选的 kubectl 配置](#optional-kubectl-configurations) - [启用 shell 自动补全功能](#enable-shell-autocompletion) - [{{% heading "whatsnext" %}}](#{{% heading "whatsnext" %}}) <!-- ### Install kubectl binary with curl on macOS {#install-kubectl-binary-with-curl-on-macos} --> ### 用 curl 在 macOS 系统上安装 kubectl {#install-kubectl-binary-with-curl-on-macos} <!-- 1. Download the latest release: --> 1. 下载最新的发行版： ```bash curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" ``` {{< note >}} <!-- To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. For example, to download version {{< param "fullversion" >}} on macOS, type: --> 如果需要下载某个指定的版本，用该指定版本号替换掉命令的这个部分：`$(curl -L -s https://dl.k8s.io/release/stable.txt)`。 例如：要在 macOS 系统中下载 {{< param "fullversion" >}} 版本，则输入： ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl ``` {{< /note >}} <!-- 1. Validate the binary (optional) Download the kubectl checksum file: --> 1. 验证可执行文件（可选操作） 下载 kubectl 的校验和文件： ```bash curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" ``` <!-- Validate the kubectl binary against the checksum file: --> 根据校验和文件，验证 kubectl： ```bash echo "$(<kubectl.sha256)  kubectl" | shasum -a 256 --check ``` <!-- If valid, the output is: --> 验证通过时，输出如下： ```console kubectl: OK ``` <!-- If the check fails, `shasum` exits with nonzero status and prints output similar to: --> 验证失败时，`shasum` 将以非零值退出，并打印如下输出： ``` kubectl: FAILED shasum: WARNING: 1 computed checksum did NOT match ``` {{< note >}} <!-- Download the same version of the binary and checksum. --> 下载的 kubectl 与校验和文件版本要相同。 {{< /note >}} <!-- 1. Make the kubectl binary executable. --> 1. 将 kubectl 置为可执行文件： ```bash chmod +x ./kubectl ``` <!-- 1. Move the kubectl binary to a file location on your system `PATH`. --> 1. 将可执行文件 kubectl 移动到系统可寻址路径 `PATH` 内的一个位置： ```bash sudo mv ./kubectl /usr/local/bin/kubectl sudo chown root: /usr/local/bin/kubectl ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install with Homebrew on macOS {#install-with-homebrew-on-macos} --> ### 用 Homebrew 在 macOS 系统上安装 {#install-with-homebrew-on-macos} <!-- If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you can install kubectl with Homebrew. --> 如果你是 macOS 系统，且用的是 [Homebrew](https://brew.sh/) 包管理工具， 则可以用 Homebrew 安装 kubectl。 <!-- 1. Run the installation command: --> 1. 运行安装命令： ```bash brew install kubectl ``` 或 ```bash brew install kubernetes-cli ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install with Macports on macOS {#install-with-macports-on-macos} --> ### 用 Macports 在 macOS 上安装 {#install-with-macports-on-macos} <!-- If you are on macOS and using [Macports](https://macports.org/) package manager, you can install kubectl with Macports. --> 如果你用的是 macOS，且用 [Macports](https://macports.org/) 包管理工具，则你可以用 Macports 安装kubectl。 <!-- 1. Run the installation command: --> 1. 运行安装命令： ```bash sudo port selfupdate sudo port install kubectl ``` <!-- 1. Test to ensure the version you installed is up-to-date: --> 1. 测试一下，确保你安装的是最新的版本： ```bash kubectl version --client ``` <!-- ### Install on macOS as part of the Google Cloud SDK {#install-on-macos-as-part-of-the-google-cloud-sdk} --> ### 作为谷歌云 SDK 的一部分，在 macOS 上安装 {#install-on-macos-as-part-of-the-google-cloud-sdk} {{< include "included/install-kubectl-gcloud.md" >}} <!-- ## Verify kubectl configuration {#verify-kubectl-configuration} --> ## 验证 kubectl 配置 {#verify-kubectl-configuration} {{< include "included/verify-kubectl.md" >}} <!-- ## Optional kubectl configurations {#optional-kubectl-configurations} ### Enable shell autocompletion {#enable-shell-autocompletion} --> ## 可选的 kubectl 配置 {#optional-kubectl-configurations} ### 启用 shell 自动补全功能 {#enable-shell-autocompletion} <!-- kubectl provides autocompletion support for Bash and Zsh, which can save you a lot of typing. Below are the procedures to set up autocompletion for Bash and Zsh. --> kubectl 为 Bash 和 Zsh 提供自动补全功能，这可以节省许多输入的麻烦。 下面是为 Bash 和 Zsh 设置自动补全功能的操作步骤。 {{< tabs name="kubectl_autocompletion" >}} {{< tab name="Bash" include="included/optional-kubectl-configs-bash-mac.md" />}} {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} </ins>  No newline at end of file

This is a Feature Request translate content/docs/tasks/tools/install-kubectl- into Chinese What would you like to be content/zh/docs/tasks/tools/install-kubectl- /assign /language zh
/triage accepted


Question: {{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.


Question: {{< tab name="certificate-key" include="generated/kubeadm_alpha_certs_certificate-key.md" />}} {{< /tabs >}} <ins> ## kubeadm alpha certs generate-csr {#cmd-certs-generate-csr} This command can be used to generate certificate signing requests (CSRs) which can be submitted to a certificate authority (CA) for signing. {{< tabs name="tab-certs-generate-csr" >}} {{< tab name="certificate-generate-csr" include="generated/kubeadm_alpha_certs_generate-csr.md" />}} {{< /tabs >}} </ins> ## kubeadm alpha certs check-expiration {#cmd-certs-check-expiration} This command checks expiration for the certificates in the local PKI managed by kubeadm.


Question: You can ignore this warning. You are only checking the version of `kubectl` that you have installed. {{< /note >}} Or use this for detailed view of version: ```cmd <del> kubectl version --client --output=yaml </del> <ins> kubectl version --client --output=yaml </ins> ``` ### Install using native package management

The page assumes one is using and as an architecture. The download commands won't work for e.g. / .
/kind bug /retitle kubectl download page for Linux assumes amd64 architecture
/language en /triage accepted /priority important-longterm Thanks for filing this
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 issue has been marked as an important bug and triaged. Such issues are automatically marked as frozen when hitting the rotten state to avoid missing important bugs. Please send feedback to sig-contributor-experience at . /lifecycle frozen
/assign


Question:
kind [Required]
  meta/v1.GroupVersionKind   meta/v1.GroupVersionKind
Kind is the fully-qualified type of object being submitted (for example, v1.Pod or autoscaling.v1.Scale)

resource [Required]
  meta/v1.GroupVersionResource   meta/v1.GroupVersionResource
Resource is the fully-qualified resource being requested (for example, v1.pods)

Several of the types used in AdmissionRequest does not seem to be documented anywhere. The links point to the general Kubernetes API docs, but the actual types does not seem to be defined there. Searching in the docs does not turn up any obvious references, and neither does web searches. Types missing documentation:
/sig docs /language en
Yes, no documentation for and But for , it should be . The doc is here:
/triage accepted /assign


Question: - [Kubernetes Python client library](https://github.com/kubernetes-client/python) - [Kubernetes Java client library](https://github.com/kubernetes-client/java) - [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) <ins> - [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) - [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell) </ins> ## CLIリファレンス * [kubectl](/ja/docs/reference/kubectl/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 <del> * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 </del> <ins> * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 </ins> * [kubeadm](/ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 ## コンポーネントリファレンス

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Update Why is this needed links are outdated. 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


Question: Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... [ ] Feature Request [X] Bug Report Problem: The link "build-tools/" doesn't work anymore and returns 404. Proposed Solution: Fix the link Page to Update:
Fixed. Thanks!


Question: Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [x] Bug Report Problem: Page url: in line 83, click PetSets guide occur 404 error. Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Fixed.


Question: Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```

This is a... [ ] Feature Request [X] Bug Report Problem: link "Minikube installation guide" points to which is 404 Proposed Solution: fix the link by making it absolute: Page to Update:
Fixed.


Question: Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```

<!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!--Required Information--This is a... <!-- choose one by changing [ ] to [x] --- [ ] Feature Request [X] Bug Report Problem: Multiple links on the page generate 404 Not Found Examples: (redirected from ) (redirected from ) Proposed Solution: fix the links Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
Here is the full list of broken links on xhyve driver kvm (driver installation) xhyve (driver installation) See DRIVERS docker-env command minikube start minikube stop minikube delete full CLI docs


Question: Hit enter for command prompt <del> / # wget -s --timeout=1 nginx </del> <ins> / # wget --spider --timeout=1 nginx </ins> Connecting to nginx (10.100.0.16:80) / # ```

I wish /docs/user-guide/horizontal-pod-autoscaling/walkthrough/ actually contained the information, or at least a link to autoscaling by custom application logic (as referred to by the first sentence in the article - . The second half of this article seems like the correct target link -
Fixed. Thanks.


Question: `zk-2` is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data </del> <ins> kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data </ins> ``` ```

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. Proposed Solution: Update to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/sig cluster-lifecycle
cc
i see the discussion / PR here: using in the kubeadm docs makes sense. /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : Flag --delete-local-data has been deprecated, This option is deprecated and will be deleted. Use --delete-emptydir-data. I don’t know if it’s a good time to update this flag . If so, I can help update it. /help </details
/assign


Question: * Learn more about [container lifecycle hooks](/docs/concepts/containers/container-lifecycle-hooks/). <ins> * Learn more about [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/). </ins> * For detailed information about Pod and container status in the API, see the API reference documentation covering [`status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.

restartPolicy under initContainers is not allowing to create Jobs specified into the below documents Error Message: Job in version "v1" cannot be handled as a Job: strict decoding error: unknown field "[0].restartPolicy" Document Link:
Hi I believe the error message you are getting is because you might have used feild under the section. But it is not allowed under the . /language en
Page related to the issue: /sig docs /sig node
Hi , Below is the Job configuration:
Could you please provide the code block with proper indentation?
updated above section
The indentation should be corrected as below
/kind bug
mentions a feature gate, but doesn't make it explicitly clear that you need to enable it. The feature gate is named . The fix I recommend: add a brand new page edit to direct readers to that new page /remove-kind bug I don't think there is anything actually incorrect. /triage accepted /retitle Unclear documentation about sidecar containers
Is anybody working to fix this issue? If no, i can take it.
/assign
Feel free to involve me, if you need any help.
Sure, Thank you.
PR raised to fix the issue .
Also see
To learn more, you can read (but not plagiarize)
Hi, I also having this problem I tried to add restartPolicy as to under containers and init containers, but I get the same error. I do not got any errors for the restartPolicy, but and are gave the error mentioned at the top. Im using Minikube, and my CC: Your suggestions highly appriciatable
Looks like you are using 1.27, but this feature was in 1.28.
Thanks I updated my k8s Even though I can not use and in both places. ( and I put this marker in the above comment). It says,


Question: } } <ins> /* Announcements */ </ins> #announcement { > * { color: inherit;

This is a Feature Request The red banner introduced with is too intrusive. Most Kubernetes users don't actually care about this deadline, and there is no way to dismiss it. What would you like to be A simple "dismiss" button that sets a cookie to hide the banner in any future visit, like other websites do. Why is this needed I'd argue that most users of the website just want to read the documentation, they aren't going to submit images to that registry, so the warning isn't useful. Comments This could be reused for future banners.
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 Add way to dismiss banners in the K8s website We would implement this for all banners, not just red ones.
/area web-development
oh boy! are you in for a ride!!
xref: also, here's how i deal with papercuts on the web -
Which all banners are you referring to? I'd be willing to take this up.
There's a banner displayed now, it looks like this: ! Imagine if you could click to acknowledge that you'd read it and didn't want to see it again for a fortnight. (separately: does feel relevant - ruled out taking action as they don't plan to push a container image there, which I think reveals a misunderstanding. I think it's worth repeating banners every couple of weeks in case it helps a message to land better).
Which ...To clarify for anyone reading: This banner applies to pulling / downloading container images from the Kubernetes project, this banner is aimed at users, not Kubernetes developers. Nobody can push directly to either of these hosts and the change isn't related to pushing / submitting images.
Thanks and for the explanation! I'll take this up and try to resolve this. /assign
are you working on this issue? I would like to help if you want. Do let me know.
Yes, I'm working on this still, mostly it's completed already, but thanks for the offer!


Question: } } <ins> /* Announcements */ </ins> #announcement { > * { color: inherit;

The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
As XDRAGON2002 seems is evaded, could you please proceed?
/remove-lifecycle stale
I'll help with this, it seems like a good feature
/sig docs


Question: This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. <ins> {{< note >}} The `spec` of a static Pod cannot refer to other API objects (e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, {{< glossary_tooltip text="Secret" term_id="secret" >}}, etc). {{< /note >}} </ins> ## Container probes A _probe_ is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet can invoke different actions:


Question: resource requests and limits for an init container are handled differently, as documented in [Resource sharing within containers](#resource-sharing-within-containers). <del> Also, init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` because they must run to completion before the Pod can be ready. </del> <ins> Regular init containers (in other words: excluding sidecar containers) do not support the `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` fields. Init containers must run to completion before the Pod can be ready; sidecar containers continue running during a Pod's lifetime, and _do_ support some probes. See [sidecar container](/docs/concepts/workloads/pods/sidecar-containers/) for further details about sidecar containers. </ins> If you specify multiple init containers for a Pod, kubelet runs each init container sequentially. Each init container must succeed before the next can run. When all of the init containers have run to completion, kubelet initializes the application containers for the Pod and runs them as usual. <ins> ### Differences from sidecar containers Init containers run and complete their tasks before the main application container starts. Unlike [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers), init containers are not continuously running alongside the main containers. Init containers run to completion sequentially, and the main container does not start until all the init containers have successfully completed. init containers do not support `lifecycle`, `livenessProbe`, `readinessProbe`, or `startupProbe` whereas sidecar containers support all these [probes](/docs/concepts/workloads/pods/pod-lifecycle/#types-of-probe) to control their lifecycle. Init containers share the same resources (CPU, memory, network) with the main application containers but do not interact directly with them. They can, however, use shared volumes for data exchange. </ins> ## Using init containers Because init containers have separate images from app containers, they


Question: design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom resources. --> <del> [operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, </del> <ins> [operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计， </ins> 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 <!--more-->

Hello, I noticed some punctuation errors on page /language zh
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: instead. {{< /note >}} <ins> {{< note >}} The `spec` of a static Pod cannot refer to other API objects (e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, {{< glossary_tooltip text="Secret" term_id="secret" >}}, etc). {{< /note >}} </ins> ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: I saw an out-of-tree product mention that static pods "can not use" ConfigMaps and Secrets. I was unaware of such a prohibition. I went looking in the k8s website. I spent a lot of time not finding any mention of such a restriction. For example: mentions static pods but not the restriction; describes ConfigMap and Secret type volumes but does not mention the restriction; the Go sources for the relevant API types do not mention the restriction (). I eventually found the restriction wrt ConfigMap mentioned in , but I think it should not appear only there. Proposed Solution: Update either or both of the first two pages I cited that currently lack the restriction. Update the API types to mention the restriction. Page to Update: Listed above. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/triage accepted
I can work on this one. Thanks. /assign
I just realized there is an additional --- and more severe --- restriction on static pods. They can not have a ! As a corollary, they are not given a by default. For example, using a static pod: ... note that there is no ! is one place where this would be relevant.
The prohibition is even broader and simpler: the definition of a static pod can not refer to any other API object. For example, PersistentVolumeClaim is another thing that a static pod's definition can not reference.


Question: ## {{% heading "whatsnext" %}} <ins> * Tutorial to _[deploy your first app on Kubernetes with kubectl](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/)_. </ins> * Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/). * Learn more about [Deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/). * Learn more about [Service objects](/docs/concepts/services-networking/service/).

<!-- 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 Link to at the end of Make this link particularly prominent. It should come before the other three links in the What's Next section of the page. Why is this needed directs readers to visit However, people who get to the end of do not see any link back to Comments This is a consequence of the Katacoda shutdown - - and our response to that shutdown. /language en /kind feature
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 Proposed fix in
/good-first-issue (retrospectively)


Question:
requestResource
  meta/v1.GroupVersionResource   meta/v1.GroupVersionResource
RequestResource is the fully-qualified resource of the original API request (for example, v1.pods).


Question: <ins> --- title: "后续内容" description: "安装 kubectl 之后，还可以做些什么？" headless: true --- <!-- --- title: "What's next?" description: "What's next after installing kubectl." headless: true --- --> <!-- * [Install Minikube](https://minikube.sigs.k8s.io/docs/start/) * See the [getting started guides](/docs/setup/) for more about creating clusters. * [Learn how to launch and expose your application.](/docs/tasks/access-application-cluster/service-access-application-cluster/) * If you need access to a cluster you didn't create, see the [Sharing Cluster Access document](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * Read the [kubectl reference docs](/docs/reference/kubectl/kubectl/) --> * [安装 Minikube](https://minikube.sigs.k8s.io/docs/start/) * 有关创建集群的更多信息，请参阅[入门指南](/zh/docs/setup/). * [学习如何启动并对外公开你的应用程序。](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) * 如果你需要访问其他人创建的集群，请参阅 [共享集群接入文档](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/). * 阅读 [kubectl 参考文档](/zh/docs/reference/kubectl/kubectl/) </ins>


Question: | | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | | `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | | `Directory` | 주어진 경로에 디렉터리가 있어야 함 | <del> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | </del> <ins> | `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 파일을 생성한다. | </ins> | `File` | 주어진 경로에 파일이 있어야 함 | | `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | | `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 |

This is a Bug Report Problem: There is incorrectly translated content in docs/concepts/storage/volumes/#hostpath . in English: in Korean: Proposed Solution: Page to Update:
/kind bug /language ko
/triage accepted


Question: <ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all spec: podSelector: {} policyTypes: - Ingress - Egress </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
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale


Question: --- <del> title: v1.19 릴리스 노트 </del> <ins> title: v1.20 릴리스 노트 </ins> weight: 10 card: name: release-notes

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: 1 file changed, 1656 insertions(+), 2119 deletions(-) for Korean is outdated. Proposed Solution: Update according to 1 file changed, 1656 insertions(+), 2119 deletions(-) <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language ko
/assign
Parent issue :
/milestone dev-1.20-ko.1
/triage accepted


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

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.


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

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.


Question: drain the node on which the `zk-0` Pod is scheduled. ```shell <del> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data </del> <ins> kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data </ins> ``` ```


Question: The output of a successful command is: <del> deployment.apps/dns-autoscaler created </del> <ins> deployment.apps/kube-dns-autoscaler created </ins> DNS horizontal autoscaling is now enabled. ## Tune DNS autoscaling parameters {#tuning-autoscaling-parameters} <del> Verify that the dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </del> <ins> Verify that the kube-dns-autoscaler {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} exists: </ins> ```shell kubectl get configmap --namespace=kube-system

dns-horizontal- kube-dns-autoscaler dns-autoscaler 2
/language zh
please describe the issue in English
page related to the issue:
/triage needs-information
Translate to English: The kube-dns-autoscaler used in dns-horizontal- and the dns-autoscaler used in subsequent commands are confused and out of sync. It seems that the English version also has this problem. /triage accepted /kind bug /retitle Inconsistent name in the DNS horizontal autoscaling example
/language en
/assign


Question: SystemdCgroup = true ``` <ins> If you apply this change make sure to restart containerd again: ```shell sudo systemctl restart containerd ``` </ins> When using kubeadm, manually configure the [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).

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 The documentation for container runtimes at: needs to have a clear warning that by adding the suggested change in , this will actually PREVENT from successfully initializing a cluster (this is my experience multiple times with K8s 1.20.4 on Ubuntu 20.04 with containerd - not Docker). Why is this needed The current wording does not indicate that the suggested change for containerd's will actually break things. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --It is not clear even why that suggestion is there given that it stops from working.
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 current text reads: How would you reword this How about: When using kubeadm, you must manually configure the cgroup driver for kubelet. /language en /priority awaiting-more-evidence /sig cluster-lifecycle
Thank you for all the work that you do, related to Kubernetes and all other open source projects you contribute to. Your efforts are really appreciated. My own experience is that the configuration snippet there is actually harmful in the scope of using kubeadm. I realize now that the page is discussing how to use containerd with the systemd cgroup driver in general... but the typical person coming to the "" documentation is there to learn how to use containerd in the context of kubernetes. That makes that configuration snippet a bit out of place since it will actually prevent the usage of kubeadm. For this reason, I believe it is better to be crystal clear and explicitly mention all of that. "To use the systemd cgroup driver... [plugins... ... SystemdCgroup = true However, when using kubeadm to initialize the cluster, the above configuration should NOT be done (it will actually prevent kubelet from bringing up static pods).


Question: SystemdCgroup = true ``` <ins> If you apply this change make sure to restart containerd again: ```shell sudo systemctl restart containerd ``` </ins> When using kubeadm, manually configure the [cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node).

Instead, manually configure the cgroup driver for kubelet."
i don't see anything invalid on the page, but ideas for clarification are welcome. When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager ... ^ the above already explains when the systemd driver is needed. it is the opposite. if you are using kubeadm, you must configure containerd with . and then pass the same driver to the kubelet as explained here: cgroup drivers have been confusing users for a long time and this is really a problem in the CRI spec. there is a plan to automatically handle them but this might take a while to complete.
this area of the docs is seeing some refactor, so you can add comments here too:
This is the source of our difference:. I have tried that setting multiple times (at least 4 times). It does NOT work for me on Ubuntu 20.04. When I do NOT specify that setting in containerd's , then and ONLY THEN does it work... for me.
i just tried following our documentation for installing containerd / installing kubeadm / creating kubeadm cluster. everything works fine for me: also a number of different CI setups are running kubeadm like so, you must be failing something in your setup. i doubt this is a containerd / OS bug of sorts, but it could be. /kind support
did you restart containerd after you : the step here should be after the driver is changed, so that's a documentation problem:
opened PR for this: (it also closes this issue)


Question: <ins> --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-egress spec: podSelector: {} egress: - {} policyTypes: - Egress </ins>


Question: The [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/) is defined by the states or phases of a Pod. There are five possible Pod phases: Pending, Running, Succeeded, Failed, and Unknown. A high-level description of the Pod state is summarized in the [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` field. --> [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod <del> 处于哪个阶段的概述。包含了下面 5 种可能的阶段: Running、Pending、Succeeded、 </del> <ins> 处于哪个阶段的概述。包含了下面 5 种可能的阶段：Running、Pending、Succeeded、 </ins> Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。


Question: 1. Download the latest release with the command: <del> ```bash </del> <ins> {{< tabs name="download_binary_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl" {{< /tab >}} {{< /tabs >}} </ins> {{< note >}} To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. <del> For example, to download version {{< param "fullversion" >}} on Linux, type: </del> <ins> For example, to download version {{< param "fullversion" >}} on Linux x86-64, type: </ins> ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl ``` <ins> And for Linux ARM64, type: ```bash curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/linux/arm64/kubectl ``` </ins> {{< /note >}} 1. Validate the binary (optional) Download the kubectl checksum file: <del> ```bash </del> <ins> {{< tabs name="download_checksum_linux" >}} {{< tab name="x86-64" codelang="bash" >}} </ins> curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256" <del> ``` </del> <ins> {{< /tab >}} {{< tab name="ARM64" codelang="bash" >}} curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/arm64/kubectl.sha256" {{< /tab >}} {{< /tabs >}} </ins> Validate the kubectl binary against the checksum file:

The page assumes one is using and as an architecture. The download commands won't work for e.g. / .
/kind bug /retitle kubectl download page for Linux assumes amd64 architecture
/language en /triage accepted /priority important-longterm Thanks for filing this
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 issue has been marked as an important bug and triaged. Such issues are automatically marked as frozen when hitting the rotten state to avoid missing important bugs. Please send feedback to sig-contributor-experience at . /lifecycle frozen
/assign


Question: [authorization plugin and policy](/docs/reference/access-authn-authz/authorization/#authorization-modules) in use. <ins> The API credentials are automatically revoked when the Pod is deleted, even if finalizers are in place. In particular, the API credentials are revoked 60 seconds beyond the `.metadata.deletionTimestamp` set on the Pod (the deletion timestamp is typically the time that the **delete** request was accepted plus the Pod's termination grace period). </ins> ### Opt out of API credential automounting If you don't want the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}

This is a Bug Report The doc about finalizers doesn't give any information about the fact that the API server considers a deleted service account or a deleted pod's token invalid after 1 minute the DeletionTimestamp. ref: <!--Required Information--Problem: Proposed Solution: Document with a note. 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 en
/sig apps


Question: <ins> --- title: Cluster id: cluster date: 2020-08-03 full_link: short_description: > Um conjunto de servidores de processamento, também chamados de nós, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (worker node). aka: tags: - fundamental - operation --- Um conjunto de servidores de processamento, chamados {{< glossary_tooltip text="nós" term_id="node" >}}, que executam aplicações containerizadas. Todo cluster possui ao menos um servidor de processamento (_worker node_). <!--more--> O servidor de processamento hospeda os {{< glossary_tooltip text="Pods" term_id="pod" >}} que são componentes de uma aplicação. O {{< glossary_tooltip text="ambiente de gerenciamento" term_id="control-plane" >}} gerencia os nós de processamento e os Pods no cluster. Em ambientes de produção, o ambiente de gerenciamento geralmente executa em múltiplos computadores e um cluster geralmente executa em múltiplos nós (_nodes_) , provendo tolerância a falhas e alta disponibilidade. </ins>

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: is giving 404 Proposed Solution: if doesn't have the pt version Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/assign


Question: * Cloning support is only available for dynamic provisioners. * CSI drivers may or may not have implemented the volume cloning functionality. * You can only clone a PVC when it exists in the same namespace as the destination PVC (source and destination must be in the same namespace). <del> * Cloning is only supported within the same Storage Class. - Destination volume must be the same storage class as the source - Default storage class can be used and storageClassName omitted in the spec </del> <ins> * Cloning is supported with a different Storage Class. - Destination volume can be the same or a different storage class as the source. - Default storage class can be used and storageClassName omitted in the spec. </ins> * Cloning can only be performed between two volumes that use the same VolumeMode setting (if you request a block mode volume, the source MUST also be block mode)

Cloning is only supported within the same Storage Class. Cloning has supported different storage class
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
Hello It sounds like you might want to report that a web page is wrong. If that's right, what's the URL of the webpage? Also, could you quote or point out the text in that page that isn't right? /language en /triage needs-information
/sig storage
Hi i would like to explain this issue if i am not wrong wants to update this . As is merged so now users will be able to clone a volume with a different Storage Class. The destination volume no longer has to be the same storage class as the source. But in current documentation we have the behaviour as. Cloning is only supported within the same Storage Class. Destination volume must be the same storage class as the source
I would like to work on this. /assign
Sorry my bad.. Thanks for pointing it.
/remove-triage needs-information


Question:
requestKind
  meta/v1.GroupVersionKind   meta/v1.GroupVersionKind
RequestKind is the fully-qualified type of the original API request (for example, v1.Pod or autoscaling.v1.Scale).

Several of the types used in AdmissionRequest does not seem to be documented anywhere. The links point to the general Kubernetes API docs, but the actual types does not seem to be defined there. Searching in the docs does not turn up any obvious references, and neither does web searches. Types missing documentation:
/sig docs /language en
Yes, no documentation for and But for , it should be . The doc is here:
/triage accepted /assign


Question: Finally if everything goes well, remove Docker. <del> {{< tabs name="tab-remove-docker-enigine" >}} </del> <ins> {{< tabs name="tab-remove-docker-engine" >}} </ins> {{% tab name="CentOS" %}} ```shell

As part of "Remove Docker Engine", this page should probably also tell the user that may want to clean up space was consumed by docker, e.g. . Otherwise, potentially much space is left used but unmanaged on the node.
Sounds good. We could link to and similar page fragments; if we do, we should caution people that Docker's advice has a risk of trampling on containerd. Ideally, we provide just links to third party docs here. However, neither Docker Engine nor containerd has docs for migrating from one thing to the other (let alone any Kubernetes-specific considerations). I'm happy to treat that as a valid exception from the usual .
/sig node /triage accepted /language en /priority backlog
/assign


Question: metadata: name: myapp-pod labels: <del> app: myapp </del> <ins> app.kubernetes.io/name: MyApp </ins> spec: containers: - name: myapp-container

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. --Updated Japanese translation for the file. Why is this needed There are several updates in and therefore this page is outdated. 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


Question: - [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する - Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する <ins> KubernetesのコントロールプレーンでもSecretsは使われています。例えば、[bootstrap token Secrets](#bootstrap-token-secrets)は、ノード登録を自動化するための仕組みです。 </ins> Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。

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. --About Some corrections need to be made. Why is this needed JSON in .dockerconfigjson dump is strange. Lack of options for kubectl command. And some more correction is needed. Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --/language ja
/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]:
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 because the related PR is under reviewing /triage accepted


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

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


Question: (backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References

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


Question: (backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References


Question: (backward-compatible) changes to the way the Kubernetes cluster DNS server processes DNS queries, to facilitate the lookup of federated services (which span multiple Kubernetes clusters). <del> See the [Cluster Federation Administrators' Guide](/docs/admin/federation/index.md) for more </del> <ins> See the [Cluster Federation Administrators' Guide](/docs/admin/federation) for more </ins> details on Cluster Federation and multi-site support. ## References

I wish /docs/admin/dns/ linked correctly to the federation guide, at


Question: <ins> --- title: スケジューラーの設定 content_type: concept weight: 20 --- {{< feature-state for_k8s_version="v1.19" state="beta" >}} 設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。 <!-- overview --> <!-- body --> スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config <filename>`を実行することで、スケジューリングプロファイルを指定することができます。 最小限の設定は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` ## プロファイル スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは[拡張点](#extension-points)に公開されています。 [プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 単一の`kube-scheduler`インスタンスで[複数のプロファイル](#multiple-profiles)を実行するように設定することも可能です。 ### 拡張点 {#extension-points} スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。 1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodを ソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。 1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや 前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。 1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、 Podの実行不可能なNodeをフィルターするために使用されます。 もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。 1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、 設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__ とマークした場合、残りの`postFilter`プラグインは呼び出されません。 1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。 1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対して スコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。 1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、 情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に 呼び出される`Unreserve`も実装しています。 1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。 1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。 1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、 1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは 少なくとも1つは必要です。 1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。 1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して 同時に有効化または無効化することができます。 次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - plugins: score: disabled: - name: PodTopologySpread enabled: - name: MyCustomPluginA weight: 2 - name: MyCustomPluginB weight: 1 ``` `disabled`配列の`name`フィールドに`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。 ### Scheduling plugins {#scheduling-plugins} 以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。 - `ImageLocality`:Podが実行するコンテナイメージを既に持っているNodeを優先します。 拡張点:`score` - `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。 実装する拡張点:`filter`、`preScore`、`score` - `NodeName`: PodのSpecのNode名が、現在のNodeと一致するかをチェックします。 拡張点:`filter` - `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。 拡張点:`preFilter`、`filter` - `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) を実行します。 拡張点:`filter`、`score` - `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。 拡張点:`filter`. - `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。 スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio` 拡張点:`preFilter`、`filter`、`score` - `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れた リソース使用量となるNodeを優先します。 拡張点:`score` - `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}} を持っている、もしくはバインドしているかチェックします。 拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score` {{< note >}} `score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。 要求されたボリュームに適合する最小のPVを優先的に使用します。 {{< /note >}} - `VolumeRestrictions`:Nodeにマウントされたボリュームが、ボリュームプロバイダ固有の制限を満たしているかを確認します。 拡張点:`filter` - `VolumeZone`:要求されたボリュームがゾーン要件を満たしているかどうかを確認します。 拡張点:`filter` - `NodeVolumeLimits`:NodeのCSIボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `EBSLimits`:NodeのAWSのEBSボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `GCEPDLimits`:NodeのGCP-PDボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。 拡張点:`queueSort`. - `DefaultBinder`:デフォルトのバインディングメカニズムを提供します。 拡張点:`bind` - `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供します。 拡張点:`postFilter` また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。 デフォルトでは有効になっていません。 - `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と {{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、 {{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、 に属するPodのNode間の拡散を優先します。 拡張点:`preScore`、`score` - `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/) ボリューム制限を満たせるかチェックします。 拡張点:`filter` ### 複数のプロファイル {#multiple-profiles} `kube-scheduler`は複数のプロファイルを実行するように設定することができます。 各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを 設定することが可能です。 以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、 もう1つはすべてのスコアリングプラグインを無効にしたものです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler - schedulerName: no-scoring-scheduler plugins: preScore: disabled: - name: '*' score: disabled: - name: '*' ``` 特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。 デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。 このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、 それぞれユニークなスケジューラー名にする必要があります。 もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。 従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。 {{< note >}} Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。 リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。 {{< /note >}} {{< note >}} すべてのプロファイルは、`queueSort`拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります (該当する場合)。これは、pending状態のPodキューがスケジューラーに1つしかないためです。 {{< /note >}} ### 複数の拡張点に適用されるプラグイン {#multipoint} `kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。 `multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。 `MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。 すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: MyPlugin ``` これは以下のように、`MyPlugin`を手動ですべての拡張ポイントに対して有効にすることと同じです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: preScore: enabled: - name: MyPlugin score: enabled: - name: MyPlugin preFilter: enabled: - name: MyPlugin filter: enabled: - name: MyPlugin ``` `multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、 `multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。 特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。 これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、 ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。 この例として、`Score`と`PreScore`を無効にするためには、次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: multiPoint: enabled: - name: 'MyPlugin' preScore: disabled: - name: '*' score: disabled: - name: '*' ``` `v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。 しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。 例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。 その場合、次のように重さを変更し、並べ替えることができます ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: score: enabled: - name: 'DefaultScore2' weight: 5 ``` この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。 そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。 これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。 `MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。 1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される 2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容 3. デフォルトプラグインとそのデフォルト設定 上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。 |プラグイン|拡張点| |---|---| |`DefaultQueueSort`|`QueueSort`| |`CustomQueueSort`|`QueueSort`| |`DefaultPlugin1`|`Score`, `Filter`| |`DefaultPlugin2`|`Score`| |`CustomPlugin1`|`Score`, `Filter`| |`CustomPlugin2`|`Score`, `Filter`| これらのプラグインの有効な設定例は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: 'CustomQueueSort' - name: 'CustomPlugin1' weight: 3 - name: 'CustomPlugin2' disabled: - name: 'DefaultQueueSort' filter: disabled: - name: 'DefaultPlugin1' score: enabled: - name: 'DefaultPlugin2' ``` なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。 特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。 このサンプルは、ほとんどのコンフィグを一箇所にまとめるだけでなく、いくつかの工夫をしています。 * カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。 * `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。 * `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。 * `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に) `v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: # デフォルトQueueSortプラグインを無効化 queueSort: enabled: - name: 'CustomQueueSort' disabled: - name: 'DefaultQueueSort' # カスタムFilterプラグインを有効化 filter: enabled: - name: 'CustomPlugin1' - name: 'CustomPlugin2' - name: 'DefaultPlugin2' disabled: - name: 'DefaultPlugin1' # カスタムScoreプラグインを有効化し、実行順を並べ替える score: enabled: - name: 'DefaultPlugin2' weight: 1 - name: 'DefaultPlugin1' weight: 3 ``` これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。 ## スケジューラー設定の移行 {{< tabs name="tab_with_md" >}} {{% tab name="v1beta1 → v1beta2" %}} * v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。 この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグイン を使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - pluginConfig: - args: scoringStrategy: resources: - name: cpu weight: 1 type: MostAllocated name: NodeResourcesFit ``` * スケジューラープラグインの`NodeLabel`は廃止されました。代わりに[`NodeAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`ServiceAffinity`は廃止されました。代わりに[`InterPodAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`NodePreferAvoidPods`は廃止されました。代わりに[Node taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用することで同様の振る舞いを実現できます。 * v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。 * スケジューラーのヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。 {{% /tab %}} {{% tab name="v1beta2 → v1beta3" %}} * デフォルトで3つのプラグインの重みが増加しました。 * `InterPodAffinity`:1から2 * `NodeAffinity`:1から2 * `TaintToleration`:1から3 {{% /tab %}} {{< /tabs >}} ## {{% heading "whatsnext" %}} * [kube-schedulerリファレンス](/docs/reference/command-line-tools-reference/kube-scheduler/)を読む * [scheduling](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * [kube-scheduler設定(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)のリファレンスを読む * [kube-scheduler設定(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)のリファレンスを読む </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. It is needed for PR Comments /language ja /assign
/triage accepted


Question: <ins> --- title: スケジューラーの設定 content_type: concept weight: 20 --- {{< feature-state for_k8s_version="v1.19" state="beta" >}} 設定ファイルを作成し、そのパスをコマンドライン引数として渡すことで`kube-scheduler`の振る舞いをカスタマイズすることができます。 <!-- overview --> <!-- body --> スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは、拡張点に公開されています。プラグインをそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 KubeSchedulerConfiguration([`v1beta2`](/docs/reference/config-api/kube-scheduler-config.v1beta2/)か[`v1beta3`](/docs/reference/config-api/kube-scheduler-config.v1beta3/))構造体を使用して、`kube-scheduler --config <filename>`を実行することで、スケジューリングプロファイルを指定することができます。 最小限の設定は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig ``` ## プロファイル スケジューリングプロファイルは、{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}でスケジューリングの 異なるステージを設定することができます。 各ステージは[拡張点](#extension-points)に公開されています。 [プラグイン](#scheduling-plugins)をそれらの拡張点に1つ以上実装することで、スケジューリングの振る舞いを変更できます。 単一の`kube-scheduler`インスタンスで[複数のプロファイル](#multiple-profiles)を実行するように設定することも可能です。 ### 拡張点 {#extension-points} スケジューリングは一連のステージで行われ、以下の拡張点に公開されています。 1. `queueSort`: これらのプラグインは、スケジューリングキューにある`pending`状態のPodを ソートするための順序付け関数を提供します。同時に有効化できるプラグインは1つだけです。 1. `preFilter`: これらのプラグインは、フィルタリングをする前にPodやクラスターの情報のチェックや 前処理のために使用されます。これらのプラグインは、設定された順序で呼び出されます。 1. `filter`: これらのプラグインは、スケジューリングポリシーにおけるPredicatesに相当するもので、 Podの実行不可能なNodeをフィルターするために使用されます。 もし全てのNodeがフィルターされてしまった場合、Podはunschedulableとしてマークされます。 1. `postFilter`:これらのプラグインは、Podの実行可能なNodeが見つからなかった場合、 設定された順序で呼び出されます。もし`postFilter`プラグインのいずれかが、Podを __スケジュール可能__ とマークした場合、残りの`postFilter`プラグインは呼び出されません。 1. `preScore`: これは、スコアリング前の作業を行う際に使用できる情報提供のための拡張点です。 1. `score`: これらのプラグインはフィルタリングフェーズを通過してきたそれぞれのNodeに対して スコア付けを行います。その後スケジューラーは、最も高い重み付きスコアの合計を持つノードを選択します。 1. `reserve`: これは、指定されたPodのためにリソースが予約された際に、プラグインに通知する、 情報提供のための拡張点です。また、プラグインは`Reserve`中に失敗した際、または`Reserve`の後に 呼び出される`Unreserve`も実装しています。 1. `permit`: これらのプラグインではPodのバインディングを拒む、または遅延させることができます。 1. `preBind`: これらのプラグインは、Podがバインドされる前に必要な処理を実行できます。 1. `bind`: これらのプラグインはPodをNodeにバインドします。`bind`プラグインは順番に呼び出され、 1つのプラグインがバインドを完了すると、残りのプラグインはスキップされます。`bind`プラグインは 少なくとも1つは必要です。 1. `postBind`: これは、Podがバインドされた後に呼び出される情報提供のための拡張点です。 1. `multiPoint`: このフィールドは設定のみ可能で、プラグインが適用されるすべての拡張点に対して 同時に有効化または無効化することができます。 次の例のように、それぞれの拡張点に対して、特定の[デフォルトプラグイン](#scheduling-plugins)を無効化、または自作のプラグインを有効化することができます。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - plugins: score: disabled: - name: PodTopologySpread enabled: - name: MyCustomPluginA weight: 2 - name: MyCustomPluginB weight: 1 ``` `disabled`配列の`name`フィールドに`*`を使用することで、その拡張点の全てのデフォルトプラグインを無効化できます。また、必要に応じてプラグインの順序を入れ替える場合にも使用されます。 ### Scheduling plugins {#scheduling-plugins} 以下のプラグインはデフォルトで有効化されており、1つ以上の拡張点に実装されています。 - `ImageLocality`:Podが実行するコンテナイメージを既に持っているNodeを優先します。 拡張点:`score` - `TaintToleration`:[TaintsとTolerations](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を実行します。 実装する拡張点:`filter`、`preScore`、`score` - `NodeName`: PodのSpecのNode名が、現在のNodeと一致するかをチェックします。 拡張点:`filter` - `NodePorts`:要求されたPodのポートに対して、Nodeが空きポートを持っているかチェックします。 拡張点:`preFilter`、`filter` - `NodeAffinity`:[nodeselectors](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) と[Nodeアフィニティ](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) を実行します。 拡張点:`filter`、`score` - `PodTopologySpread`:[Podトポロジーの分散制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `NodeUnschedulable`:`.spec.unschedulable`がtrueに設定されているNodeをフィルタリングします。 拡張点:`filter`. - `NodeResourcesFit`:Podが要求しているすべてのリソースがNodeにあるかをチェックします。 スコアは3つのストラテジのうちの1つを使用します:`LeastAllocated`(デフォルト)、`MostAllocated`、 と`RequestedToCapacityRatio` 拡張点:`preFilter`、`filter`、`score` - `NodeResourcesBalancedAllocation`:Podがスケジュールされた場合に、よりバランスの取れた リソース使用量となるNodeを優先します。 拡張点:`score` - `VolumeBinding`:Nodeが、要求された{{< glossary_tooltip text="ボリューム" term_id="volume" >}} を持っている、もしくはバインドしているかチェックします。 拡張点:`preFilter`、`filter`、`reserve`、`preBind`、`score` {{< note >}} `score`拡張点は、`VolumeCapacityPriority`機能が有効になっている時に有効化されます。 要求されたボリュームに適合する最小のPVを優先的に使用します。 {{< /note >}} - `VolumeRestrictions`:Nodeにマウントされたボリュームが、ボリュームプロバイダ固有の制限を満たしているかを確認します。 拡張点:`filter` - `VolumeZone`:要求されたボリュームがゾーン要件を満たしているかどうかを確認します。 拡張点:`filter` - `NodeVolumeLimits`:NodeのCSIボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `EBSLimits`:NodeのAWSのEBSボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `GCEPDLimits`:NodeのGCP-PDボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `AzureDiskLimits`:NodeのAzureディスクボリューム制限を満たすかどうかをチェックします。 拡張点:`filter` - `InterPodAffinity`:[Pod間のaffinityとanti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) を実行します。 拡張点:`preFilter`、`filter`、`preScore`、`score` - `PrioritySort`:デフォルトの優先順位に基づくソートを提供します。 拡張点:`queueSort`. - `DefaultBinder`:デフォルトのバインディングメカニズムを提供します。 拡張点:`bind` - `DefaultPreemption`:デフォルトのプリエンプションメカニズムを提供します。 拡張点:`postFilter` また、コンポーネント設定のAPIにより、以下のプラグインを有効にすることができます。 デフォルトでは有効になっていません。 - `SelectorSpread`:{{< glossary_tooltip text="サービス" term_id="service" >}}と {{< glossary_tooltip text="レプリカセット" term_id="replica-set" >}}、 {{< glossary_tooltip text="ステートフルセット" term_id="statefulset" >}}、 に属するPodのNode間の拡散を優先します。 拡張点:`preScore`、`score` - `CinderLimits`:Nodeが[`OpenStack Cinder`](https://docs.openstack.org/cinder/) ボリューム制限を満たせるかチェックします。 拡張点:`filter` ### 複数のプロファイル {#multiple-profiles} `kube-scheduler`は複数のプロファイルを実行するように設定することができます。 各プロファイルは関連するスケジューラー名を持ち、その[拡張点](#extension-points)に異なるプラグインを 設定することが可能です。 以下のサンプル設定では、スケジューラーは2つのプロファイルで実行されます。1つはデフォルトプラグインで、 もう1つはすべてのスコアリングプラグインを無効にしたものです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler - schedulerName: no-scoring-scheduler plugins: preScore: disabled: - name: '*' score: disabled: - name: '*' ``` 特定のプロファイルに従ってスケジュールさせたいPodは、その`.spec.schedulerName`に、対応するスケジューラー名を含めることができます。 デフォルトでは、スケジューラー名`default-scheduler`としてプロファイルが生成されます。 このプロファイルは、上記のデフォルトプラグインを含みます。複数のプロファイルを宣言する場合は、 それぞれユニークなスケジューラー名にする必要があります。 もしPodがスケジューラー名を指定しない場合、kube-apiserverは`default-scheduler`を設定します。 従って、これらのPodをスケジュールするために、このスケジューラー名を持つプロファイルが存在する必要があります。 {{< note >}} Podのスケジューリングイベントには、ReportingControllerとして`.spec.schedulerName`が設定されています。 リーダー選出のイベントには、リスト先頭のプロファイルのスケジューラー名が使用されます。 {{< /note >}} {{< note >}} すべてのプロファイルは、`queueSort`拡張点で同じプラグインを使用し、同じ設定パラメーターを持つ必要があります (該当する場合)。これは、pending状態のPodキューがスケジューラーに1つしかないためです。 {{< /note >}} ### 複数の拡張点に適用されるプラグイン {#multipoint} `kubescheduler.config.k8s.io/v1beta3`からは、プロファイル設定に`multiPoint`というフィールドが追加され、複数の拡張点でプラグインを簡単に有効・無効化できるようになりました。 `multiPoint`設定の目的は、カスタムプロファイルを使用する際に、ユーザーや管理者が必要とする設定を簡素化することです。 `MyPlugin`というプラグインがあり、`preScore`、`score`、`preFilter`、`filter`拡張点を実装しているとします。 すべての利用可能な拡張点で`MyPlugin`を有効化するためには、プロファイル設定は次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: MyPlugin ``` これは以下のように、`MyPlugin`を手動ですべての拡張ポイントに対して有効にすることと同じです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: preScore: enabled: - name: MyPlugin score: enabled: - name: MyPlugin preFilter: enabled: - name: MyPlugin filter: enabled: - name: MyPlugin ``` `multiPoint`を使用する利点の一つは、将来的に`MyPlugin`が別の拡張点を実装した場合に、 `multiPoint`設定が自動的に新しい拡張点に対しても有効化されることです。 特定の拡張点は、その拡張点の`disabled`フィールドを使用して、`MultiPoint`の展開から除外することができます。 これは、デフォルトのプラグインを無効にしたり、デフォルト以外のプラグインを無効にしたり、 ワイルドカード(`'*'`)を使ってすべてのプラグインを無効にしたりする場合に有効です。 この例として、`Score`と`PreScore`を無効にするためには、次のようにします。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: non-multipoint-scheduler plugins: multiPoint: enabled: - name: 'MyPlugin' preScore: disabled: - name: '*' score: disabled: - name: '*' ``` `v1beta3`では、`MultiPoint`を通じて、内部的に全ての[デフォルトプラグイン](#scheduling-plugins)が有効化されています。 しかしながら、デフォルト値(並び順やスコアの重みなど)を柔軟に設定し直せるように、個別の拡張点は用意されています。 例えば、2つのスコアプラグイン`DefaultScore1`と`DefaultScore2`に、重み1が設定されているとします。 その場合、次のように重さを変更し、並べ替えることができます ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: score: enabled: - name: 'DefaultScore2' weight: 5 ``` この例では、`MultiPoint`はデフォルトプラグインであるため、明示的にプラグイン名を指定する必要はありません。 そして、`Score`に指定されているプラグインは`DefaultScore2`のみです。 これは、特定の拡張点を通じて設定されたプラグインは、常に`MultiPoint`プラグインよりも優先されるためです。つまり、この設定例では、結果的に2つのプラグインを両方指定することなく、並び替えが行えます。 `MultiPoint`プラグインを設定する際の一般的な優先順位は、以下の通りです。 1. 特定の拡張点が最初に実行され、その設定は他の場所で設定されたものよりも優先される 2. `MultiPoint`を使用して、手動で設定したプラグインとその設定内容 3. デフォルトプラグインとそのデフォルト設定 上記の優先順位を示すために、次の例はこれらのプラグインをベースにします。 |プラグイン|拡張点| |---|---| |`DefaultQueueSort`|`QueueSort`| |`CustomQueueSort`|`QueueSort`| |`DefaultPlugin1`|`Score`, `Filter`| |`DefaultPlugin2`|`Score`| |`CustomPlugin1`|`Score`, `Filter`| |`CustomPlugin2`|`Score`, `Filter`| これらのプラグインの有効な設定例は次の通りです。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: multiPoint: enabled: - name: 'CustomQueueSort' - name: 'CustomPlugin1' weight: 3 - name: 'CustomPlugin2' disabled: - name: 'DefaultQueueSort' filter: disabled: - name: 'DefaultPlugin1' score: enabled: - name: 'DefaultPlugin2' ``` なお、特定の拡張点に`MultiPoint`プラグインを再宣言しても、エラーにはなりません。 特定の拡張点が優先されるため、再宣言は無視されます(ログは記録されます)。 このサンプルは、ほとんどのコンフィグを一箇所にまとめるだけでなく、いくつかの工夫をしています。 * カスタムの`queueSort`プラグインを有効にし、デフォルトのプラグインを無効にする。 * `CustomPlugin1`と`CustomPlugin2`を有効にし、この拡張点のプラグイン内で、最初に実行されるようにする。 * `filter`拡張点でのみ、`DefaultPlugin1`を無効にする。 * `score`拡張点で`DefaultPlugin2`が最初に実行されるように並べ替える(カスタムプラグインより先に) `v1beta3`以前のバージョンで、`multiPoint`がない場合、上記の設定例は、次のものと同等になります。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: multipoint-scheduler plugins: # デフォルトQueueSortプラグインを無効化 queueSort: enabled: - name: 'CustomQueueSort' disabled: - name: 'DefaultQueueSort' # カスタムFilterプラグインを有効化 filter: enabled: - name: 'CustomPlugin1' - name: 'CustomPlugin2' - name: 'DefaultPlugin2' disabled: - name: 'DefaultPlugin1' # カスタムScoreプラグインを有効化し、実行順を並べ替える score: enabled: - name: 'DefaultPlugin2' weight: 1 - name: 'DefaultPlugin1' weight: 3 ``` これは複雑な例ですが、`MultiPoint`設定の柔軟性と、拡張点を設定する既存の方法とのシームレスな統合を実証しています。 ## スケジューラー設定の移行 {{< tabs name="tab_with_md" >}} {{% tab name="v1beta1 → v1beta2" %}} * v1beta2`のバージョン`の設定では、新しい`NodeResourcesFit`プラグインをスコア拡張点で使用できます。 この新しい拡張機能は、`NodeResourcesLeastAllocated`、`NodeResourcesMostAllocated`、 `RequestedToCapacityRatio`プラグインの機能を組み合わせたものです。 例えば、以前は`NodeResourcesMostAllocated`プラグインを使っていたなら、代わりに`NodeResourcesFitプラグイン を使用し(デフォルトで有効)、`pluginConfig`に次のような`scoreStrategy`を追加することになるでしょう。 ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - pluginConfig: - args: scoringStrategy: resources: - name: cpu weight: 1 type: MostAllocated name: NodeResourcesFit ``` * スケジューラープラグインの`NodeLabel`は廃止されました。代わりに[`NodeAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`ServiceAffinity`は廃止されました。代わりに[`InterPodAffinity`](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)プラグイン(デフォルトで有効)を使用することで同様の振る舞いを実現できます。 * スケジューラープラグインの`NodePreferAvoidPods`は廃止されました。代わりに[Node taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用することで同様の振る舞いを実現できます。 * v1beta2で有効化されたプラグインは、そのプラグインのデフォルトの設定より優先されます。 * スケジューラーのヘルスとメトリクスのバインドアドレスに設定されている`host`や`port`が無効な場合、バリデーションに失敗します。 {{% /tab %}} {{% tab name="v1beta2 → v1beta3" %}} * デフォルトで3つのプラグインの重みが増加しました。 * `InterPodAffinity`:1から2 * `NodeAffinity`:1から2 * `TaintToleration`:1から3 {{% /tab %}} {{< /tabs >}} ## {{% heading "whatsnext" %}} * [kube-schedulerリファレンス](/docs/reference/command-line-tools-reference/kube-scheduler/)を読む * [scheduling](/ja/docs/concepts/scheduling-eviction/kube-scheduler/)について学ぶ * [kube-scheduler設定(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)のリファレンスを読む * [kube-scheduler設定(v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/)のリファレンスを読む </ins>

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


Question:
 {{ end }}

 {{ end }}  No newline at end of file

~This is Support~ In the , i am able to see under Kubernetes Documentation. Respective tiled content buttons are aligned respective the content length or size. As a user , i would like to see them aligned as a bordered tile content with buttons are aligned look like a row irrespective of tile content length. This improves the user experience Please let me know if drawings are needed to understand.So that i can take a capture of it and attach.
/area web-development /kind cleanup a mockup would be useful
/priority awaiting-more-evidence (adjust this once the discussion has made it clear)
- PFA.It is screenshot of button aligned.I have the tile border which is not the primary objective though(Just to border line the content) ! Hope this mockup helps.
/remove-priority awaiting-more-evidence /priority backlog
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh 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 /lifecycle frozen /retitle Poor alignment between tiles and buttons on home page for docs
Reopened this issue. <detailsIn response to : /reopen /lifecycle frozen /retitle Poor alignment between tiles and buttons on home page for docs 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-kind cleanup /triage accepted