Question: <ins> --- content_type: concept reviewers: - ptux title: 監査 --- <!-- overview --> Kubernetesの監査はクラスター内の一連の行動を記録するセキュリティに関連した時系列の記録を提供します。 クラスターはユーザー、Kubernetes APIを使用するアプリケーション、 およびコントロールプレーン自体によって生成されたアクティビティなどを監査します。 監査により、クラスター管理者は以下の質問に答えることができます: - 何が起きたのか？ - いつ起こったのか？ - 誰がそれを始めたのか？ - 何のために起こったのか？ - それはどこで観察されましたか？ - それはどこから始まったのか？ - それはどこへ向かっていたのか？ <!-- body --> 監査記録のライフサイクルは[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)コンポーネントの中で始まります。 各リクエストは、その実行の各段階でその実行の各段階で、監査イベントが生成されます。 ポリシーに従って前処理され、バックエンドに書き込まれます。 ポリシーが何を記録するかを決定しを決定し、 バックエンドがその記録を永続化します。現在のバックエンドの実装はログファイルやWebhookなどがあります。 各リクエストは関連する _stage_ で記録されます。 定義されたステージは以下の通りです: - `RequestReceived` - 監査ハンドラーがリクエストを受信すると同時に生成されるイベントのステージ。 つまり、ハンドラーチェーンに委譲される前に生成されるイベントのステージです。 - `ResponseStarted` - レスポンスヘッダーが送信された後、レスポンスボディが送信される前のステージです。 このステージは長時間実行されるリクエスト（watchなど）でのみ発生します。 - `ResponseComplete` - レスポンスボディの送信が完了して、それ以上のバイトは送信されません。 - `Panic` - パニックが起きたときに発生するイベント。 {{< note >}} [Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)の設定は[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)APIオブジェクトとは異なります。 {{< /note >}} 監査ログ機能は、リクエストごとに監査に必要なコンテキストが保存されるため、APIサーバーのメモリ消費量が増加します。 メモリの消費量は、監査ログ機能の設定によって異なります。 ## Audit policy 監査ポリシーはどのようなイベントを記録し、どのようなデータを含むべきかについてのルールを定義します。 監査ポリシーのオブジェクト構造は、[audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)で定義されています。 イベントが処理されると、そのイベントは順番にルールのリストと比較されます。 最初のマッチングルールは、イベントの監査レベルを設定します。 定義されている監査レベルは: - `None` - ルールに一致するイベントを記録しません。 - `Metadata` - lリクエストのメタデータ（リクエストしたユーザー、タイムスタンプ、リソース、動作など）を記録しますが、リクエストやレスポンスのボディは記録しません。 - `Request` - ログイベントのメタデータとリクエストボディは表示されますが、レスポンスボディは表示されません。 これは非リソースリクエストには適用されません。 - `RequestResponse` - イベントのメタデータ、リクエストとレスポンスのボディを記録しますが、 非リソースリクエストには適用されません。 You can pass a file with the policy to `kube-apiserver` using the `--audit-policy-file` flag. If the flag is omitted, no events are logged. Note that the `rules` field __must__ be provided in the audit policy file. A policy with no (0) rules is treated as illegal. `audit-policy-file`フラグを使って、ポリシーを記述したファイルを `kube-apiserver`に渡すことができます。 このフラグが省略された場合イベントは記録されません。 監査ポリシーファイルでは、`rules`フィールドが必ず指定されることに注意してください。 ルールがない(0)ポリシーは不当なものとして扱われます。 以下は監査ポリシーファイルの例: {{< codenew file="audit/audit-policy.yaml" >}} 最小限の監査ポリシーファイルを使用して、すべてのリクエストを `Metadata`レベルで記録することができます。 ```yaml # Log all requests at the Metadata level. apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: Metadata ``` 独自の監査プロファイルを作成する場合は、Google Container-Optimized OSの監査プロファイルを出発点として使用できます。 監査ポリシーファイルを生成する[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)スクリプトを確認することができます。 スクリプトを直視することで、監査ポリシーファイルのほとんどを見ることができます。 また、定義されているフィールドの詳細については、[Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)を参照できます。 ## 監査バックエンド 監査バックエンドは監査イベントを外部ストレージに永続化します。 kube-apiserverには2つのバックエンドが用意されています。 - イベントをファイルシステムに書き込むログバックエンド - 外部のHTTP APIにイベントを送信するWebhookバックエンド いずれの場合も、監査イベントはKubernetes API[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)で定義されている構造に従います。 {{< note >}} パッチの場合、リクエストボディはパッチ操作を含むJSON配列であり、適切なKubernetes APIオブジェクトを含むJSONオブジェクトではありません。 例えば、以下のリクエストボディは`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`に対する有効なパッチリクエストです。 ```json [ { "op": "replace", "path": "/spec/parallelism", "value": 0 }, { "op": "remove", "path": "/spec/template/spec/containers/0/terminationMessagePolicy" } ] ``` {{< /note >}} ### ログバックエンド ログバックエンドは監査イベントを[JSONlines](https://jsonlines.org/)形式のファイルに書き込みます。 以下の `kube-apiserver` フラグを使ってログ監査バックエンドを設定できます。 - `--audit-log-path` は、ログバックエンドが監査イベントを書き込む際に使用するログファイルのパスを指定します。 このフラグを指定しないと、ログバックエンドは無効になります。`-` は標準出力を意味します。 - `--audit-log-maxage` は、古い監査ログファイルを保持する最大日数を定義します。 - `audit-log-maxbackup`は、保持する監査ログファイルの最大数を定義します。 - `--audit-log-maxsize` は、監査ログファイルがローテーションされるまでの最大サイズをメガバイト単位で定義します。 クラスターのコントロールプレーンでkube-apiserverをPodとして動作させている場合は、監査記録が永久化されるように、ポリシーファイルとログファイルの場所に`hostPath`をマウントすることを忘れないでください。 例えば: ```shell --audit-policy-file=/etc/kubernetes/audit-policy.yaml  --audit-log-path=/var/log/audit.log ``` それからボリュームをマウントします: ```yaml ... volumeMounts: - mountPath: /etc/kubernetes/audit-policy.yaml name: audit readOnly: true - mountPath: /var/log/audit.log name: audit-log readOnly: false ``` 最後に`hostPath`を設定します: ```yaml ... - name: audit hostPath: path: /etc/kubernetes/audit-policy.yaml type: File - name: audit-log hostPath: path: /var/log/audit.log type: FileOrCreate ``` ### Webhook バックエンド Webhook監査バックエンドは、監査イベントをリモートのWeb APIに送信しますが、 これは認証手段を含むKubernetes APIの形式であると想定されます。 Webhook監査バックエンドを設定するには、以下のkube-apiserverフラグを使用します。 - `--audit-webhook-config-file` は、Webhookの設定ファイルのパスを指定します。 webhookの設定は、事実上特化した [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters) です。 - `--audit-webhook-initial-backoff` は、最初に失敗したリクエストの後、再試行するまでに待つ時間を指定します。 それ以降のリクエストは、指数関数的なバックオフで再試行されます。 Webhookの設定ファイルは、kubeconfig 形式でサービスのリモートアドレスと接続に使用する認証情報を指定します。 ## イベントバッチ {#batching} ログバックエンドとwebhookバックエンドの両方がバッチ処理をサポートしています。 webhookを例に、利用可能なフラグの一覧を示します。 ログバックエンドで同じフラグを取得するには、フラグ名の`webhook`を`log`に置き換えてください。 デフォルトでは、バッチングは`webhook`では有効で、`log`では無効です。 同様に、デフォルトではスロットリングは `webhook` で有効で、`log`では無効です。 - `--audit-webhook-mode` は、バッファリング戦略を定義します。以下のいずれかとなります。 - `batch` - イベントをバッファリングして、非同期にバッチ処理します。これがデフォルトです。 - `blocking` - 個々のイベントを処理する際に、APIサーバーの応答をブロックします。 - `blocking-strict` - blockingと同じですが、RequestReceivedステージでの監査ログに失敗した場合は RequestReceivedステージで監査ログに失敗すると、kube-apiserverへのリクエスト全体が失敗します。 以下のフラグは `batch` モードでのみ使用されます: - `--audit-webhook-batch-buffer-size`は、バッチ処理を行う前にバッファリングするイベントの数を定義します。 入力イベントの割合がバッファをオーバーフローすると、イベントはドロップされます。 - `--audit-webhook-batch-max-size`は、1つのバッチに入れるイベントの最大数を定義します。 - `--audit-webhook-batch-max-wait`は、キュー内のイベントを無条件にバッチ処理するまでの最大待機時間を定義します。 - `--audit-webhook-batch-throttle-qps`は、1秒あたりに生成されるバッチの最大平均数を定義します。 - `--audit-webhook-batch-throttle-burst`は、許可された QPS が低い場合に、同じ瞬間に生成されるバッチの最大数を定義します。 ## パラメーターチューニング パラメーターは、APIサーバーの負荷に合わせて設定してください。 例えば、kube-apiserverが毎秒100件のリクエストを受け取り、それぞれのリクエストが`ResponseStarted`と`ResponseComplete`の段階でのみ監査されるとします。毎秒≅200の監査イベントが発生すると考えてください。 1 つのバッチに最大 100 個のイベントがあるの場合、スロットリングレベルを少なくとも2クエリ/秒に設定する必要があります。 バックエンドがイベントを書き込むのに最大で5秒かかる場合、5秒分のイベントを保持するようにバッファサイズを設定する必要があります。 10バッチ、または1000イベントとなります。 しかし、ほとんどの場合デフォルトのパラメーターで十分であり、手動で設定する必要はありません。 kube-apiserverが公開している以下のPrometheusメトリクスや、ログを見て監査サブシステムの状態を監視することができます。 - `apiserver_audit_event_total` メトリックには、エクスポートされた監査イベントの合計数が含まれます。 - `apiserver_audit_error_total` メトリックには、エクスポート中にエラーが発生してドロップされたイベントの総数が含まれます。 ### ログエントリー・トランケーション {#truncate} logバックエンドとwebhookバックエンドは、ログに記録されるイベントのサイズを制限することをサポートしています。 例として、logバックエンドで利用可能なフラグの一覧を以下に示します - `audit-log-truncate-enabled` イベントとバッチの切り捨てを有効にするかどうかです。 - `audit-log-truncate-max-batch-size` バックエンドに送信されるバッチのバイト単位の最大サイズ。 - `audit-log-truncate-max-event-size` バックエンドに送信される監査イベントのバイト単位の最大サイズです。 デフォルトでは、`webhook`と`log`の両方で切り捨ては無効になっていますが、クラスター管理者は `audit-log-truncate-enabled`または`audit-webhook-truncate-enabled`を設定して、この機能を有効にする必要があります。 ## {{% heading "whatsnext" %}} * [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). * [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) * [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) </ins>

Translate into Japanese. This page has not been translated. /language ja /assign
/triage accepted


Question: use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication) to interpret the credential format produced by the client plugin. <ins> {{< note >}} Earlier versions of `kubectl` included built-in support for authenticating to AKS and GKE, but this is no longer present. {{< /note >}} </ins> ### Example use case In a hypothetical use case, an organization would run an external service that exchanges LDAP credentials

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 (As I understand it), Kubernetes ~v1.25~ v1.26 ships an updated . The updated won't include built-in plugins for authenticating to AKS or GKE. This is likely to surprise folks. Update 3 pages: to signpost users to the right internal ~and external~ docs. We can remove this signposting once Kubernetes v1.27 (sic) is the oldest supported version of Kubernetes (consider adding an HTML comment with that detail). Optionally, also update to mention that earlier versions of included built-in support for authenticating to AKS and GKE, but this is no longer present. Why is this needed Readers may follow the “install kubectl” docs and get a tool that's missing functionality they thought was built in. Comments /sig cli /language en
/triage accepted /priority important-soon
For each of the three pages, add the following under the Verify kubectl configuration heading, at the end of the section:
/help-wanted
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /label help-wanted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
/assign
Kubernetes 1.25.0 did not remove Google and Azure auth plugins due to a regression issue, see The revert is in PR
This change is likely to arrive in v1.26, so we should get it staffed.
would you be willing to change the minor version in ?
-- as author/reviewer of the , can you please review the doc change suggested by in
A few suggestions: I probably would not put "panic" in the heading title Can we link to as well I'm on the fence about whether we need the cloud-specific links in this doc... if you try to use them in a kubectl version that has removed them, you already get a message output at time of use with the appropriate link/reference. If we do keep those links, I would say something like "These providers have released kubectl plugins to provide the cloud-specific authentication." instead of "fix the authentication"
I personally do not think the kube authn docs should contain cloud-specific links. It is on the cloud providers to migrate their users anyway, and the cloud CLI tools are fully capable of hiding the bulk of this migration by performing runtime checks and/or preferring credential plugins over the legacy approach.
I agree about not including cloud-provider-specific links. Integrations with cloud providers are not required for a (vanilla) Kubernetes cluster to function. See for some more context.
We can instead advise readers to search in their cloud provider's documentation for further advice.
Hello , 1.26 Release Docs Lead here. This feature request needs Docs for 1.26 release. Please to open a PR against dev-1.26 branch in the k/website repo. This PR can be just a placeholder at this time, and must be created by November 10. Also, take a look at to familiarize yourself with the docs requirement for the release. Any doubt, reach us! Thank you!
/unassign
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
//remove-priority important-soon /priority important-longterm /triage accepted
/remove-priority important-soon
could you kindly provide a detailed description of the issue once more? Upon reviewing the above comments, it appears that numerous changes have been implemented.
looks right to me. In terms of the “right internal and internal docs” to link to, you should use your judgement. You could link to or to a task page; you might need to write the task page first. Any more questions? It's clear to me, but I might have missed something.
/assign
Thanks , I am working on this, will create a PR soon ;)


Question: {{< glossary_definition term_id="api-eviction" length="short" >}} </br> <del> You can request eviction by directly calling the Eviction API using a client of the kube-apiserver, like the `kubectl drain` command. This creates an `Eviction` object, which causes the API server to terminate the Pod. </del> <ins> You can request eviction by calling the Eviction API directly, or programmatically using a client of the {{<glossary_tooltip term_id="kube-apiserver" text="API server">}}, like the `kubectl drain` command. This creates an `Eviction` object, which causes the API server to terminate the Pod. </ins> API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). <ins> Using the API to create an Eviction object for a Pod is like performing a policy-controlled [`DELETE` operation](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) on the Pod. ## Calling the Eviction API You can use a [Kubernetes language client](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) to access the Kubernetes API and create an `Eviction` object. To do this, you POST the attempted operation, similar to the following example: {{< tabs name="Eviction_example" >}} {{% tab name="policy/v1" %}} {{< note >}} `policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases. {{< /note >}} ```json { "apiVersion": "policy/v1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` {{% /tab %}} {{% tab name="policy/v1beta1" %}} {{< note >}} Deprecated in v1.22 in favor of `policy/v1` {{< /note >}} ```json { "apiVersion": "policy/v1beta1", "kind": "Eviction", "metadata": { "name": "quux", "namespace": "default" } } ``` {{% /tab %}} {{< /tabs >}} Alternatively, you can attempt an eviction operation by accessing the API using `curl` or `wget`, similar to the following example: ```bash curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json ``` ## How API-initiated eviction works When you request an eviction using the API, the API server performs admission checks and responds in one of the following ways: * `200 OK`: the eviction is allowed, the `Eviction` subresource is created, and the Pod is deleted, similar to sending a `DELETE` request to the Pod URL. * `429 Too Many Requests`: the eviction is not currently allowed because of the configured {{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}}. You may be able to attempt the eviction again later. You might also see this response because of API rate limiting. * `500 Internal Server Error`: the eviction is not allowed because there is a misconfiguration, like if multiple PodDisruptionBudgets reference the same Pod. If the Pod you want to evict isn't part of a workload that has a PodDisruptionBudget, the API server always returns `200 OK` and allows the eviction. If the API server allows the eviction, the Pod is deleted as follows: 1. The `Pod` resource in the API server is updated with a deletion timestamp, after which the API server considers the `Pod` resource to be terminated. The `Pod` resource is also marked with the configured grace period. 1. The {{<glossary_tooltip term_id="kubelet" text="kubelet">}} on the node where the local Pod is running notices that the `Pod` resource is marked for termination and starts to gracefully shut down the local Pod. 1. While the kubelet is shutting the Pod down, the control plane removes the Pod from {{<glossary_tooltip term_id="endpoint" text="Endpoint">}} and {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}} objects. As a result, controllers no longer consider the Pod as a valid object. 1. After the grace period for the Pod expires, the kubelet forcefully terminates the local Pod. 1. The kubelet tells the API server to remove the `Pod` resource. 1. The API server deletes the `Pod` resource. ## Troubleshooting stuck evictions In some cases, your applications may enter a broken state, where the Eviction API will only return `429` or `500` responses until you intervene. This can happen if, for example, a ReplicaSet creates pods for your application but new pods do not enter a `Ready` state. You may also notice this behavior in cases where the last evicted Pod had a long termination grace period. If you notice stuck evictions, try one of the following solutions: * Abort or pause the automated operation causing the issue. Investigate the stuck application before you restart the operation. * Wait a while, then directly delete the Pod from your cluster control plane instead of using the Eviction API. </ins> ## {{% heading "whatsnext" %}} <del> * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) </del> <ins> * Learn how to protect your applications with a [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/). * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/). </ins>

The content in for the Eviction API can be used to expand the conceptual information in . Proposed by /assign /sig node /sig docs /language en
cc
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
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]:
Bad bot /remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
Nooo /remove-lifecycle stale


Question: defaultValue: false fromVersion: "1.29" --- <del> Enables images to be pulled based on the [runtime class] (/docs/concepts/containers/runtime-class/) of the pods that reference them. </del> <ins> Enables images to be pulled based on the [runtime class](/docs/concepts/containers/runtime-class/) of the pods that reference them. </ins>

This is a Bug Report Problem: In the of the page, there is a section of that has an issue with the hyperlinking of the text. The is not hyperlinked properly. Proposed Solution: We should link the with the appropriate link, i.e., Page to Update:
/language en
I would to like to work on this issue, if the triage gets accepted.
/retitle Broken link in the description of on "Feature Gates" page
Fixes are welcomed. /triage accepted /priority backlog
I have raised PR to fix this problem.
Could you please review and merge the PR whenever free.


Question: ### Instalar el binario de kubectl con curl en Windows <del> 1. Descarga la [última versión {{< param "fullversion" >}}](https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). </del> <ins> 1. Descarga la [última versión {{< skew currentPatchVersion >}}](https://dl.k8s.io/release/v{{< skew currentPatchVersion >}}/bin/windows/amd64/kubectl.exe). </ins> O si tiene `curl` instalado, use este comando: ```powershell <del> curl -LO https://dl.k8s.io/release/{{% param "fullversion" %}}/bin/windows/amd64/kubectl.exe </del> <ins> curl -LO https://dl.k8s.io/release/v{{% skew currentPatchVersion %}}/bin/windows/amd64/kubectl.exe </ins> ``` {{< note >}}

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The param is deprecated. Proposed Solution: Replace the shortcode (Spanish pages), for example with or something close. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--Part of /language es
/triage accepted /area localization /priority backlog


Question: ### Hook handler implementations Containers can access a hook by implementing and registering a handler for that hook. <del> There are two types of hook handlers that can be implemented for Containers: </del> <ins> There are three types of hook handlers that can be implemented for Containers: </ins> * Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container. Resources consumed by the command are counted against the Container.

This is a Bug Report Fix number of types of hook handlers available to implement for Containers Problem: In the section , it's referred as just 2 possible types of hook handlers for containers , but afterwards 3 are enumerated Proposed Solution: "There are three types of hook handlers that can be implemented for Containers:" Page to Update:
/language en
I will try to help with this! /assign
/triage accepted


Question: layout: blog title:  '在 Kubernetes 上对 gRPC 服务器进行健康检查' date: 2018-10-01 <ins> slug: health-checking-grpc-servers-on-kubernetes </ins> --- <!-- <del> --- </del> layout: blog title:  'Health checking gRPC servers on Kubernetes' date: 2018-10-01 <del> --- </del> ---> <!--

This is a Feature Request This page blog/2022/05/13/grpc-probes-in- has no Chinese version What would you like to be Translate Chinese version for blog/2022/05/13/grpc-probes-in- Comments /language zh /assign
/triage accepted


Question: If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`. <ins> ### feature.node.kubernetes.io/* Used on: Nodes Example: `feature.node.kubernetes.io/network-sriov.capable: "true"` These features are advertised as labels in the Kubernetes Node object on nodes running NFD. All built-in labels use the feature.node.kubernetes.io label namespace and have the format `feature.node.kubernetes.io/<feature-name>: <true>`. NFD has many extension points for creating vendor and application-specific labels. For details, see the [customization guide](https://kubernetes-sigs.github.io/node-feature-discovery/v0.12/usage/customization-guide). ### nfd.node.kubernetes.io/master.version Example: `nfd.node.kubernetes.io/master.version: "v0.6.0"` Used on: Nodes For node(s) where the Node Feature Discovery (NFD) [master](https://kubernetes-sigs.github.io/node-feature-discovery/stable/usage/nfd-master.html) is scheduled, this annotation records the version of the NFD master. It is used for informative use only. ### nfd.node.kubernetes.io/worker.version Example: `nfd.node.kubernetes.io/worker.version: "v0.4.0"` Used on: Nodes This annotation records the version for a Node Feature Discovery's [worker](https://kubernetes-sigs.github.io/node-feature-discovery/stable/usage/nfd-worker.html) if there is one running on a node. It's used for informative use only. ### nfd.node.kubernetes.io/feature-labels Example: `nfd.node.kubernetes.io/feature-labels: "cpu-cpuid.ADX,cpu-cpuid.AESNI,cpu-hardware_multithreading,kernel-version.full"` Used on: Nodes This annotation records a comma-separated list of node feature labels managed by [Node Feature Discovery](https://kubernetes-sigs.github.io/node-feature-discovery/) (NFD). NFD uses this for an internal mechanism. You should not edit this annotation yourself. ### nfd.node.kubernetes.io/extended-resources Example: `nfd.node.kubernetes.io/extended-resources: "accelerator.acme.example/q500,example.com/coprocessor-fx5"` Used on: Nodes This annotation records a comma-separated list of [extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) managed by [Node Feature Discovery](https://kubernetes-sigs.github.io/node-feature-discovery/) (NFD). NFD uses this for an internal mechanism. You should not edit this annotation yourself. {{< note >}} These annotations only applies to nodes where NFD is running. To learn more about NFD and its components go to its official [documentation](https://kubernetes-sigs.github.io/node-feature-discovery/stable/get-started/). {{< /note >}} </ins> ### pod-security.kubernetes.io/enforce Example: `pod-security.kubernetes.io/enforce: "baseline"`

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 uses annotations matching Document these. Why is this needed I'm not sure it is. However, other official Kubernetes annotations are registered and documented in Comments /kind feature /priority awaiting-more-evidence /sig node /language en
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 We should triage this.
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Node Feature Discovery detects additional hardware features on each node in a Kubernetes cluster so the pods with special capability requests can be placed in nodes that have those capabilities. I haven't seen any mention of NFD or an example of the four annotations in docs. So I'm uncertain if it should be registered in docs. the four annotations are : I know this issue is quite old but If there is a go-ahead I can add them, however, NFD seems quite interesting and it would be great to have an example to use this addon in the docs.
If you open a PR we can get a tech review from SIG Node.
/remove-priority awaiting-more-evidence
That's great. I'll get to work then. Thanks
/assign
I'd like to confirm, should we give explanation or reference for NFD right before the annotations and nfd-master, nfd-worker etc in the annotation? WDYT?
Here is a Preview:
please confirm:
I have raised a PR , PTAL


Question: At this point, we believe that there is feature parity between Docker and the other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/) and are running production workload using these different runtimes. The plan of <del> record today is that dockershim will be removed in version 1.24, slated for </del> <ins> record today is that dockershim will be removed in version 1.24, slated for </ins> release around April of next year. For those developing or running alpha and beta versions, dockershim will be removed in December at the beginning of the 1.24 release development cycle.

Pre the first alpha cut of 1.24, a blog post should be drafted expressing the project's understanding that many users have not migrated off of dockershim, and migration can be painful but its needed for a variety of reasons and we are committed to documenting and making it as easy as possible. /assign (For visibility) /assign sig-arch / sig-node (please loop in / assign others) /assign (for myself to keep track of) /sig node architecture /priority important-soon /area blog
:100: /triage accepted
hoping can cover for me! also cc
/assign
I started the draft, which is super rough and doesnt' have all the outline yet:
IMO the draft is in a good enough place to be converted to a PR.


Question: <ins> --- title: Penyetelan Kinerja Penjadwal content_type: concept weight: 70 --- <!-- overview --> {{< feature-state for_k8s_version="v1.14" state="beta" >}} [kube-scheduler](/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster. Node-Node di dalam klaster yang sesuai dengan syarat-syarat penjadwalan dari sebuah Pod disebut sebagai Node-Node layak (_feasible_). Penjadwal mencari Node-Node layak untuk sebuah Pod dan kemudian menjalankan fungsi-fungsi untuk menskor Node-Node tersebut, memilih sebuah Node dengan skor tertinggi di antara Node-Node layak lainnya, di mana Pod akan dijalankan. Penjadwal kemudian memberitahu API server soal keputusan ini melalui sebuah proses yang disebut _Binding_. Laman ini menjelaskan optimasi penyetelan (_tuning_) kinerja yang relevan untuk klaster Kubernetes berskala besar. <!-- body --> Pada klaster berskala besar, kamu bisa menyetel perilaku penjadwal untuk menyeimbangkan hasil akhir penjadwalan antara latensi (seberapa cepat Pod-Pod baru ditempatkan) dan akurasi (seberapa akurat penjadwal membuat keputusan penjadwalan yang tepat). Kamu bisa mengonfigurasi setelan ini melalui pengaturan `percentageOfNodesToScore` pada kube-scheduler. Pengaturan KubeSchedulerConfiguration ini menentukan sebuah ambang batas untuk penjadwalan Node-Node di dalam klaster kamu. ### Pengaturan Ambang Batas Opsi `percentageOfNodesToScore` menerima semua angka numerik antara 0 dan 100. Angka 0 adalah angka khusus yang menandakan bahwa kube-scheduler harus menggunakan nilai bawaan. Jika kamu mengatur `percentageOfNodesToScore` dengan angka di atas 100, kube-scheduler akan membulatkan ke bawah menjadi 100. Untuk mengubah angkanya, sunting berkas konfigurasi kube-scheduler (biasanya `/etc/kubernetes/config/kube-scheduler.yaml`), lalu _ulang kembali_ kube-scheduler. Setelah kamu selesai menyunting, jalankan perintah ```bash kubectl get componentstatuses ``` untuk memverifikasi komponen kube-scheduler berjalan dengan baik (_healthy_). Keluarannya kira-kira seperti ini: ``` NAME                 STATUS    MESSAGE             ERROR controller-manager   Healthy   ok scheduler            Healthy   ok ... ``` ## Ambang Batas Penskoran Node {#persentase-penskoran-node} Untuk meningkatan kinerja penjadwalan, kube-scheduler dapat berhenti mencari Node-Node yang layak saat sudah berhasil menemukannya. Pada klaster berskala besar, hal ini menghemat waktu dibandingkan dengan pendekatan awam yang mengecek setiap Node. Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minimal yang dibutuhkan, sebagai persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation). [Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail. ### Ambang Batas Bawaan Jika kamu tidak mengatur sebuah ambang batas, maka Kubernetes akan menghitung sebuah nilai menggunakan pendekatan linier, yaitu 50% untuk klaster dengan 100 Node, serta 10% untuk klaster dengan 5000 Node. Artinya, kube-scheduler selalu menskor paling tidak 5% dari klaster kamu, terlepas dari seberapa besar klasternya, kecuali kamu secara eksplisit mengatur `percentageOfNodesToScore` menjadi lebih kecil dari 5. Jika kamu ingin penjadwal untuk memasukkan seluruh Node di dalam klaster ke dalam penskoran, maka aturlah `percentageOfNodesToScore` menjadi 100. ## Contoh Contoh konfigurasi di bawah ini mengatur `percentageOfNodesToScore` menjadi 50%. ```yaml apiVersion: kubescheduler.config.k8s.io/v1alpha1 kind: KubeSchedulerConfiguration algorithmSource: provider: DefaultProvider ... percentageOfNodesToScore: 50 ``` ##  Menyetel percentageOfNodesToScore `percentageOfNodesToScore` merupakan angka 1 sampai 100 dengan nilai bawaan yang dihitung berdasarkan ukuran klaster. Di sini juga terdapat batas bawah yang telah ditetapkan, yaitu 50 Node. {{< note >}}Pada klaster dengan kurang dari 50 Node layak, penjadwal masih terus memeriksa seluruh Node karena Node-Node layak belum mencukupi supaya penjadwal dapat menghentikan proses pencarian lebih awal. Pada klaster kecil, jika kamu mengatur `percentageOfNodesToScore` dengan angka kecil, pengaturan ini hampir atau sama sekali tidak berpengaruh, karena alasan yang sama. Jika klaster kamu punya ratusan Node, gunakan angka bawaan untuk opsi konfigurasi ini. Mengubah angkanya kemungkinan besar tidak akan mengubah kinerja penjadwal secara berarti. {{< /note >}} Sebuah catatan penting yang perlu dipertimbangkan saat mengatur angka ini adalah ketika klaster dengan jumlah Node sedikit diperiksa untuk kelayakan, beberapa Node tidak dikirim untuk diskor bagi sebuah Pod. Hasilnya, sebuah Node yang mungkin memiliki nilai lebih tinggi untuk menjalankan Pod tersebut bisa saja tidak diteruskan ke fase penskoran. Hal ini berdampak pada penempatan Pod yang kurang ideal. Kamu sebaiknya menghindari pengaturan `percentageOfNodesToScore` menjadi sangat rendah, agar kube-scheduler tidak seringkali membuat keputusan penempatan Pod yang buruk. Hindari pengaturan persentase di bawah 10%, kecuali _throughput_ penjadwal sangat penting untuk aplikasi kamu dan skor dari Node tidak begitu penting. Dalam kata lain, kamu memilih untuk menjalankan Pod pada Node manapun selama Node tersebut layak. ## Bagaimana Penjadwal Mengecek Node Bagian ini ditujukan untuk kamu yang ingin mengerti bagaimana fitur ini bekerja secara internal. Untuk memberikan semua Node di dalam klaster sebuah kesempatan yang adil untuk dipertimbangkan dalam menjalankan Pod, penjadwal mengecek Node satu persatu secara _round robin_. Kamu dapat membayangkan Node-Node ada di dalam sebuah array. Penjadwal mulai dari indeks array pertama dan mengecek kelayakan dari Node sampai jumlahnya telah mencukupi sesuai dengan `percentageOfNodesToScore`. Untuk Pod berikutnya, penjadwal melanjutkan dari indeks array Node yang terhenti ketika memeriksa kelayakan Node-Node untuk Pod sebelumnya. Jika Node-Node berada di beberapa zona, maka penjadwal akan mengecek Node satu persatu pada seluruh zona untuk memastikan bahwa Node-Node dari zona berbeda masuk dalam pertimbangan kelayakan. Sebagai contoh, ada 6 Node di dalam 2 zona: ``` Zona 1: Node 1, Node 2, Node 3, Node 4 Zona 2: Node 5, Node 6 ``` Penjadwal mempertimbangkan kelayakan dari Node-Node tersebut dengan urutan berikut: ``` Node 1, Node 5, Node 2, Node 6, Node 3, Node 4 ``` Setelah semua Node telah dicek, penjadwal akan kembali pada Node 1. </ins>

This is tracking issue of our progress from Q1 2021 onwards. In the beginning of this milestone, as per our , we have translated 220 pages from 84 contributors (the script from main repo shows 260+ pages), with around 8,000 views per month. In this milestone, we still continuing on updating the obsolete pages. We are not officially listing down target pages to translate, but feel free if you have spare time to translate some. Please check this documentation about which gives step-by-step on how to start to contribute and translate using official guidelines. There is a list of outdated pages (40 out of 162 pages for this milestone) and please feel free if you want to take part on this work.

[X] removed [X] removed content/en//docs/tasks/tools/install- [X] removed [X] removed content/en//docs/tasks/example-task- [X] removed content/en//docs/tasks/administer-cluster/cluster- [X] removed content/en//docs/setup/learning- [X] removed content/en//docs/concepts/configuration/assign-pod- [X] removed content/en//docs/concepts/configuration/pod- [ ] removed content/en//docs/concepts/configuration/manage-compute-resources- [X] moved content/en//docs/concepts/configuration/resource-bin- [X] moved content/en//docs/concepts/configuration/taint-and- [X] renamed content/en//docs/concepts/scheduling/scheduling- [X] renamed content/en//docs/concepts/scheduling/scheduler-perf- [X] renamed content/en//docs/concepts/scheduling/kube- [X] renamed [ ] removed content/en//docs/concepts/workloads/pods/pod-[ ] removed [ ] removed content/en//docs/concepts/workloads/controllers/jobs-run-to- [ ] removed content/en//docs/concepts/extend-kubernetes/poseidon-firmament-alternate- [ ] removed [ ] removed content/en//docs/concepts/cluster-administration/cluster-administration- [ ] removed content/en//docs/concepts/cluster- [ ] removed content/en//docs/concepts/cluster-administration/cloud- [ ] removed content/en//docs/concepts/cluster-administration/controller-[X] removed content/en//docs/concepts/cluster- [X] removed [X] removed [X] removed [X] modified content/en/includes/task-tutorial- [X] modified content/en/docs/home/supported-doc- [ ] modified [ ] modified content/en/docs/tasks/debug-application-cluster/resource-usage-[ ] modified content/en/docs/tasks/run-application/horizontal-pod-autoscale- [ ] modified content/en/docs/tasks/run-application/horizontal-pod- [ ] modified content/en/docs/tasks/run-application/run-stateless-application- [ ] modified content/en/docs/tasks/run-application/force-delete-stateful-set- [ ] modified content/en/docs/tasks/tools/install- [ ] modified [ ] modified content/en/docs/tasks/configure-pod-container/configure-service- [ ] modified content/en/docs/tasks/configure-pod-container/configure-persistent-volume- /language id /cc
/triage accepted
I'm taking the 4th part, as I've done the in
Thanks .

it is updated.
is moved to as mentioned here
is removed and redirect to official minikube webpage , as mentioned here
The whole pages are move into including as mentioned here
The whole are removed in , I'm going to remove the directory as well as it's unused now.
is moved to via
is removed via
Just sharing a useful trick for finding related PR which delete/modified a file: e.g. The output will be similar with this: Please note the commit hash in the output (, in the case of the example above). You can use the same command to find which commit modified a file by changing the filter from to (refer to for more filters). In case of modified file, you might get multiple commit hashes, pick the latest one (contains the recent changes), or just pick ones that suit your needs. Go to, e.g., (replace with your commit hash in step 1). Find the related PR with the commit, e.g. via web UI: ! In bottom left hand corner near the branch name, in this case , you can see the PR id . Click on the link and you will be redirected to the respective PR page, then you can analyse what changes has been made and what actions needed to incorporate it to our localization.
is removed here together with others.
is removed here
Hi ... it seems this issue is automatically closed. Do you have any idea how to re-opened it?
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Thanks :)
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi .... I think we need to close this issue, because it has already behind the schedule. Do we need to complete all within 1-2 weeks? or we need to carry forward to next quarter?
Hi All, I have opened Q2 2021 tracking issue


Question: <!-- maintenance note: OK to remove all mention of glusterfs once the v1.25 release of Kubernetes has gone out of support --> <del> - </del> Kubernetes {{< skew currentVersion >}} does not include a `glusterfs` volume type. The GlusterFS in-tree storage driver was deprecated in the Kubernetes v1.25 release

This is a Bug Report Problem: Under concept page, content for volume type is missing. In it is mentioned like: ! Due to this, content() is missing from the page: ! Instead of that it should be like the below screenshot: ! Proposed Solution: Above missing content Content for should be there. Page to Update:
/assign
/sig docs
Fixed it here:
/triage accepted /retitle Formatting problem for volume details in Volumes concept /language en


Question: If `PersistentVolumeLabel` does not support automatic labeling of your PersistentVolumes, you should consider adding the labels manually (or adding support for `PersistentVolumeLabel`). With `PersistentVolumeLabel`, the scheduler prevents Pods from mounting volumes in a different zone. If your infrastructure doesn't have this constraint, you don't need to add the zone labels to the volumes at all. <ins> ## volume.beta.kubernetes.io/storage-provisioner (deprecated) Example: `volume.beta.kubernetes.io/storage-provisioner: k8s.io/minikube-hostpath` Used on: PersistentVolumeClaim This annotation has been deprecated. ## volume.kubernetes.io/storage-provisioner Used on: PersistentVolumeClaim This annotation will be added to dynamic provisioning required PVC. </ins> ## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} Example: `node.kubernetes.io/windows-build=10.0.17763`

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: Kubernetes sets an annotation, . However, this annotation is not registered / documented. Proposed Solution: Add that annotation to . There is also a deprecated beta annotation, ; register / document that, and mark it as deprecated. Page to Update: Additional Information: /sig storage /language en /priority backlog and may provide some context for this.
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 I would like to work on this


Question: ### Upgrade kubeadm <del> 1.  Upgrade kubeadm on all worker nodes: </del> <ins> -  Upgrade kubeadm on all worker nodes: </ins> <del> {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </del> <ins> {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} </ins> # replace x in 1.18.x-00 with the latest patch version apt-mark unhold kubeadm &&  apt-get update && apt-get install -y kubeadm=1.18.x-00 &&  apt-mark hold kubeadm <ins> - </ins> # since apt-get version 1.1 you can also use the following method apt-get update &&  apt-get install -y --allow-change-held-packages kubeadm=1.18.x-00 <del> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </del> <ins> {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} </ins> # replace x in 1.18.x-0 with the latest patch version yum install -y kubeadm-1.18.x-0 --disableexcludes=kubernetes <del> {{% /tab %}} {{< /tabs >}} </del> <ins> {{% /tab %}} {{< /tabs >}} </ins> ### Drain the node <del> 1.  Prepare the node for maintenance by marking it unschedulable and evicting the workloads: </del> <ins> -  Prepare the node for maintenance by marking it unschedulable and evicting the workloads: </ins> ```shell # replace <node-to-drain> with the name of your node you are draining

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


Question: docs/user-guide/logging/#cluster-level-logging-to-google-cloud-logging) * [Cluster-level Logging with Elasticsearch and Kibana]( <del> docs/user-guide/logging/#cluster-level-logging-with-elasticsearch-and-kibana) </del> <ins> docs/getting-started-guides/logging-elasticsearch/) </ins> ## Node components

I wish /docs/admin/cluster-components/ Didn't have a broken link to Cluster Logging with ELK


Question: <del> <!-- </del> <ins> --- </ins> api_metadata: apiVersion: "" import: "k8s.io/apimachinery/pkg/apis/meta/v1" kind: "LabelSelector" content_type: "api_reference" <del> description: "A label selector is a label query over a set of resources." title: "LabelSelector" </del> <ins> description: "标签选择器是对一组资源的标签查询。" title: "标签选择器" </ins> weight: 2 <del> --> </del> <ins> auto_generated: true </ins> --- <ins> <!-- </ins> api_metadata: apiVersion: "" import: "k8s.io/apimachinery/pkg/apis/meta/v1" kind: "LabelSelector" content_type: "api_reference" <del> description: "标签选择器是对一组资源的标签查询。" title: "标签选择器" </del> <ins> description: "A label selector is a label query over a set of resources." title: "LabelSelector" </ins> weight: 2 <del> auto_generated: true --- </del> <ins> --> </ins> `import "k8s.io/apimachinery/pkg/apis/meta/v1"`

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: Wrong rendering in ! cf. en version page: ! en file: zh file: Proposed Solution: Place Hugo-related fields in the beginning of . Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--/language zh /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: This annotation has been deprecated. <ins> ### volume.beta.kubernetes.io/mount-options (deprecated) {#mount-options} Example : `volume.beta.kubernetes.io/mount-options: "ro,soft"` Used on: PersistentVolume A Kubernetes administrator can specify additional [mount options](/docs/concepts/storage/persistent-volumes/#mount-options) for when a PersistentVolume is mounted on a node. This annotation has been deprecated. </ins> ### volume.kubernetes.io/storage-provisioner Used on: PersistentVolumeClaim

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The volume mount mechanism in Kubernetes used to rely on an unregistered annotation. That annotation () is already document, but isn't yet registered. Proposed Solution: Add to (list it as deprecated) Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /language en /kind bug /priority backlog
You can refer to for details of what the annotation does. Also the text of the annotation description should in any case hyperlink to so that readers can learn about the mechanism that replaced it.
/sig storage I would like to give a try.
/sig storage /assign
/triage accepted


Question: fromVersion: "1.23" toVersion: "1.26" - stage: beta <del> defaultValue: false </del> <ins> defaultValue: true </ins> fromVersion: "1.27" --- Allows the use of the optional `.spec.persistentVolumeClaimRetentionPolicy` field,

This is a Bug Report default value for StatefulsetAutoDeletePVC is true in 1.27 <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Proposed Solution: Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
/language en
page to update
/assign
/triage accepted /sig apps


Question:
 --- ---   필터하려면 태그를 클릭하거나 드롭 다운을 사용하세요. 정순 또는 역순으로 정렬하려면 테이블 헤더를 클릭하세요.
 개념으로 필터:
 오브젝트로 필터:
 커맨드로 필터:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Elements that should be hidden appears on the screen. The "(EN)" in the next image is that element. ! Proposed Solution: Add to . Page to Update: /language ko /kind bug


Question: title: Picking the Right Solution --- <del> Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to rack of </del> <ins> Kubernetes can run on various platforms: from your laptop, to VMs on a cloud provider, to a rack of </ins> bare metal servers. The effort required to set up a cluster varies from running a single command to crafting your own customized cluster. Use this guide to choose a solution that fits your needs.

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


Question: - tallclair title: Pod Overhead content_template: templates/concept <del> weight: 20 </del> <ins> weight: 50 </ins> --- {{% capture overview %}}

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 write a new concept page: (or possibly ) If the does not work as the page overview, consider tweaking the glossary entry so that it does. Then use a Hugo shortcode. Why is this needed ConfigMap is a core object type for Kubernetes; as such, it needs documenting properly. Comments Consider using as an example for page structure. It's better to put Task-style documentation in task pages such as and then hyperlink to those from the Concept page. Also see: /docs/user-guide/configmap need more details on ConfigMap updates Actionable user-guide/configmap does not document self-updating It's unclear what happens when ConfigMap is changed Need doc on using ConfigMap updates Wanted: ConfigMap Rollout Options Doc
/language en /sig apps
/priority important-longterm
This is worth prioritizing /priority important-soon
/remove-priority important-longterm
/project Doc Sprints
/assign
/unassign
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
Still worth documenting /remove-lifecycle stale
/reopen let's collaborate on this!


Question:
{{/* We cache this partial for bigger sites and set the active class client side. */}}  {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 }} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit }}   {{ $sidebarCacheLimit := cond (isset .Site.Params.ui "sidebar_cache_limit") .Site.Params.ui.sidebar_cache_limit 2000 -}} {{ $shouldDelayActive := ge (len .Site.Pages) $sidebarCacheLimit -}}
  {{ if not .Site.Params.ui.sidebar_search_disable }}   {{ if not .Site.Params.ui.sidebar_search_disable -}}  <form class="td-sidebar__search d-flex align-items-center"> {{ partial "search-input.html" . }} <button class="btn btn-link td-sidebar__toggle d-md-none p-0 ml-3 fas fa-bars" type="button" data-toggle="collapse" data-target="#td-section-nav" aria-controls="td-docs-nav" aria-expanded="false" aria-label="Toggle section navigation"> </button> </form>  {{ else }}   {{ else -}}
 <form class="td-sidebar__search d-flex align-items-center"> {{ partial "search-input.html" . }}

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 by accident very big page files on Kubernetes documentation. For example is lines long and the lines 286- are taken for the sidebar menu containing a lot of whitespace (do right-mouse and "view page source"). Proposed Solution: I reported the issue already with Docsy: and proposed a pull request. But this will not be enough. Somebody has to update too. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
The hugo Docsy theme side issue is resolved and closed: When will somebody review and implement pull request ? You can do this separate from a Docsy theme update at It is only about (huge) whitespace reduction, not a functional change. But k8s website users will benefit in user experience.


Question: ## Migrating to the `systemd` driver <del> To change the cgroup driver of an existing kubeadm cluster to `systemd` in-place, </del> <ins> To change the cgroup driver of an existing kubeadm cluster from `cgroupfs` to `systemd` in-place, </ins> a similar procedure to a kubelet upgrade is required. This must include both steps outlined below.

says the default value for is . says: The latter does not say, that prior to 1.23 (thus 1.22, 1.21, 1.20) the default was and was later changed to . It says, that in the nearly end-of-life 1.22 the default is . Later contains: In the above text, it is nowhere stated, that there is a plan to switch the default value of KubeletConfiguration.cgroupDriver from cgroupfs to systemd. The last citation suggests, that will perform implicit switch from to . This is strengthened by the fact about 1.22, where the implicit (default) value seems to be . All in all, the above information stipulates, that in 1.22 the default value was , not it is and in the future will use as implicit (default) value again . In the lack of discussion in the documentation why the defauls change back and forth, this does not make sense,
the kubelet default is cgroupfs and it's not clear if the kubelet graduates cgroupv2 support to GA the value will change. afaik, cgroupfs does not support v2. in any case this can be a disruptive change. kubeadm changed its default to systemd because the kubelet in kubeadm setups is managed by systemd. the reason is explained here long term, the cgroup driver detail should not be exposed to users, but that is blocked on some cri work. /kind support
Ah, so the default cgroup driver for kubelet is cgroupfs, while for kubeadm the default is systemd. This shall be spelled explicitly, as it is counter-intuitive. My understanding so far is, that the systemd-driver supports kernel’s cgroup v2, while kubernetes’ cgroup-driver does not support kernel’s cgroup v2. This shall also be spelled explicitly, as it is confusing.
It sounds like the thing to call out is that, in the kubeadm docs, we should explicitly say that the setting that kubeadm applies by default is an override to the built-in kubelet default. Does that sound right?
Yes. Ideally kubeadm and kubelet shall explicitly state, that their default is distinct from the default of the other tool.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /help
This request has been marked as needing help from a contributor. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-lifecycle stale /help </details
/triage accepted
/assign


Question: StatefulSetのPodについては、[StatefulSetからPodを削除するためのタスクのドキュメント](/ja/docs/tasks/run-application/force-delete-stateful-set-pod/)を参照してください。 <del> ### 失敗したPodのガベージコレクション {#pod-garbage-collection} </del> <ins> ### 終了したPodのガベージコレクション {#pod-garbage-collection} </ins> 失敗したPodは人間または{{< glossary_tooltip term_id="controller" text="controller" >}}が明示的に削除するまで存在します。

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


Question: --> 如果你希望新来的 Pod 均匀分布在现有的可用区域，则可以按如下设置其清单： <del> {{< codenew file="pods/topology-spread-constraints/one-constraint.yaml" >}} </del> <ins> {{% code file="pods/topology-spread-constraints/one-constraint.yaml" %}} </ins> <!-- From that manifest, `topologyKey: zone` implies the even distribution will only be applied

the Chinese translation is wrong, "" should be "" see from English site:
/language zh
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /language zh-cn </details
/language zh
/sig docs
/triage accepted
/assign


Question: deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o:/$VERSION/$OS/ / EOF <del> curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg - curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key add --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg - </del> <ins> curl -L https://download.opensuse.org/repositories/devel:kubic:libcontainers:stable:cri-o:$VERSION/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add - curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/$OS/Release.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/libcontainers.gpg add - </ins> sudo apt-get update sudo apt-get install cri-o cri-o-runc

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


Question: ## Cluster-level logging architectures <del> While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: </del> <ins> While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: </ins> * Use a node-level logging agent that runs on every node. * Include a dedicated sidecar container for logging in an application pod.

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: Url selector #kubelet-config-k8s-io-v1beta1-KubeletConfiguration doesn't make a difference between: and Proposed Solution: Removing the selector from the URLs 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
/assign
/retitle Problems with (generated) reference for kubelet configuration


Question: For example, ```shell <del> kubectl taint nodes node1 key=value:NoSchedule </del> <ins> kubectl taint nodes node1 key1=value1:NoSchedule </ins> ``` <del> places a taint on node `node1`. The taint has key `key`, value `value`, and taint effect `NoSchedule`. </del> <ins> places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`. </ins> This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. To remove the taint added by the command above, you can run: ```shell <del> kubectl taint nodes node1 key=value:NoSchedule- </del> <ins> kubectl taint nodes node1 key1=value1:NoSchedule- </ins> ``` You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the

This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be Update to use a key of rather than , and a value of rather than . Why is this needed Some sections of Taints and Tolerations concept page suggest setting a taint where the key is called and the value is . This is confusing because when the reader sees example commands they are unsure whether represents the literal text or the example. This change will help clear up that confusion. Comments /language en /good first issue
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
It's also OK to use and rather than my suggestion of and . Whichever you prefer.
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign


Question: kubectl port-forward deployment/mongo :27017 ``` <del> The output is similar to this: ``` Forwarding from 127.0.0.1:63753 -> 27017 Forwarding from [::1]:63753 -> 27017 ``` </del> The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers, because these might be used by other applications). The output is similar to:

This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: There is a duplicate code block in . FYI: is like this: Proposed Solution: Delete one of the duplicate code block. 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


Question: description: > A detailed look at the different policy levels defined in the Pod Security Standards. content_type: concept <del> weight: 10 </del> <ins> weight: 15 </ins> --- <!-- overview -->

This is a Refactor request <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The overview page at is a bit out of date: no reference to I'm not convinced that the “Four Cs of cloud native security” model is useful for readers to learn Does not align with other CNCF documents, such as Proposed Solution: Either: remove outright migrate content from into several destinations (keep this brief but on-point) …and then redirect to Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig docs /sig security /language en
If we keep the link to then we should update it to be as this is the English docs.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale /triage accepted
Also see
/assign
I'd appreciate a (fresh) review on .


Question: * Learn more about [debugging a StatefulSet](/docs/tasks/debug-application-cluster/debug-stateful-set/). * Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/). * Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/). <del> * Look in the [Helm Charts repository](https://github.com/kubernetes/charts) </del> <ins> * Look in the [Helm Charts repository](https://artifacthub.io/) </ins> for other stateful application examples.

Helm Charts repository ( ) is obsolete. This sentence should be removed or updated. might be appropriate.
If this issue is validated, may I take this up?
/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 : /help Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/assign


Question: #### Dockerfile ```conf <del> FROM node:0.12 </del> <ins> FROM node:4.4 </ins> EXPOSE 8080 COPY server.js . CMD node server.js ``` <del> This "recipe" for the Docker image will start from the Node 0.12 image found on the Docker registry, expose port 8080, copy our `server.js` file to the image and start the Node server. </del> <ins> This "recipe" for the Docker image will start from the official Node.js LTS image found on the Docker registry, expose port 8080, copy our `server.js` file to the image and start the Node server. </ins> Now build an image of your container by running `docker build`, tagging the image with the Google  Container Registry repo for your `PROJECT_ID`:

NodeJS 0.10 is going into security-only release mode very soon. The first version of 0.10 was released in March 2013, so it's over 3 years old. It would be great if we could update the tutorial/dockerfile to list the latest (or at least a newer) nodejs version.
Resolved by, thanks to


Question: <!-- overview --> <del> {{< glossary_tooltip text="Pod" term_id="pod" >}}が稼働する{{< glossary_tooltip text="Node" term_id="node" >}}を特定のものに指定したり、優先条件を指定して制限することができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は[ラベルでの選択](/ja/docs/concepts/overview/working-with-objects/labels/)です。 スケジューラーが最適な配置を選択するため、一般的にはこのような制限は不要です(例えば、複数のPodを別々のNodeへデプロイしたり、Podを配置する際にリソースが不十分なNodeにはデプロイされないことが挙げられます)が、 SSDが搭載されているNodeにPodをデプロイしたり、同じアベイラビリティーゾーン内で通信する異なるサービスのPodを同じNodeにデプロイする等、柔軟な制御が必要なこともあります。 </del> <ins> {{< glossary_tooltip text="Pod" term_id="pod" >}}を特定の{{< glossary_tooltip text="Node" term_id="node" >}}で実行するように _制限_ したり、特定のNodeで実行することを _優先_ させたりといった制約をかけることができます。 これを実現するためにはいくつかの方法がありますが、推奨されている方法は、すべて[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/)を使用して選択を容易にすることです。 多くの場合、このような制約を設定する必要はなく、{{< glossary_tooltip text="スケジューラー" term_id="kube-scheduler" >}}が自動的に妥当な配置を行います(例えば、Podを複数のNodeに分散させ、空きリソースが十分でないNodeにPodを配置しないようにすることができます)。 しかし、例えばSSDが接続されているNodeにPodが配置されるようにしたり、多くの通信を行う2つの異なるサービスのPodを同じアベイラビリティーゾーンに配置したりする等、どのNodeに配置するかを制御したい状況もあります。 <!-- body --> Kubernetesが特定のPodの配置場所を選択するために、以下の方法があります: </ins> <del> <!-- body --> </del> <ins> * [nodeラベル](#built-in-node-labels)に対してマッチングを行う[nodeSelector](#nodeselector)フィールド * [アフィニティとアンチアフィニティ](#affinity-and-anti-affinity) * [nodeName](#nodename)フィールド * [Podのトポロジー分散制約](#pod-topology-spread-constraints) </ins> <del> ## nodeSelector </del> <ins> ## Nodeラベル {#built-in-node-labels} </ins> <del> `nodeSelector`は、Nodeを選択するための、最も簡単で推奨されている手法です。 `nodeSelector`はPodSpecのフィールドです。これはkey-valueペアのマップを特定します。 あるノードでPodを稼働させるためには、そのノードがラベルとして指定されたkey-valueペアを保持している必要があります(複数のラベルを保持することも可能です)。 最も一般的な使用方法は、1つのkey-valueペアを付与する方法です。 </del> <ins> 他の多くのKubernetesオブジェクトと同様に、Nodeにも[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)があります。[手動でラベルを付ける](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/#ラベルをNodeに追加する)ことができます。 また、Kubernetesはクラスター内のすべてのNodeに対し、いくつかの標準ラベルを付けます。Nodeラベルの一覧については[よく使われるラベル、アノテーションとtaint](/docs/reference/labels-annotations-taints/)を参照してください。 </ins> <del> 以下に、`nodeSelector`の使用例を紹介します。 </del> <ins> {{<note>}} これらのラベルの値はクラウドプロバイダー固有のもので、信頼性を保証できません。 例えば、`kubernetes.io/hostname`の値はある環境ではNode名と同じになり、他の環境では異なる値になることがあります。 {{</note>}} </ins> <del> ### ステップ0: 前提条件 </del> <ins> ### Nodeの分離/制限 </ins> <del> この例では、KubernetesのPodに関して基本的な知識を有していることと、[Kubernetesクラスターのセットアップ](/ja/docs/setup/)がされていることが前提となっています。 </del> <ins> Nodeにラベルを追加することで、Podを特定のNodeまたはNodeグループ上でのスケジューリングの対象にすることができます。この機能を使用すると、特定のPodが一定の独立性、安全性、または規制といった属性を持ったNode上でのみ実行されるようにすることができます。 </ins> <del> ### ステップ1: Nodeへのラベルの付与 </del> <ins> Node分離するのにラベルを使用する場合、{{<glossary_tooltip text="kubelet" term_id="kubelet">}}が修正できないラベルキーを選択してください。 これにより、侵害されたNodeが自身でそれらのラベルを設定することで、スケジューラーがそのNodeにワークロードをスケジュールしてしまうのを防ぐことができます。 </ins> <del> `kubectl get nodes`で、クラスターのノードの名前を取得してください。 そして、ラベルを付与するNodeを選び、`kubectl label nodes <node-name> <label-key>=<label-value>`で選択したNodeにラベルを付与します。 例えば、Nodeの名前が'kubernetes-foo-node-1.c.a-robinson.internal'、付与するラベルが'disktype=ssd'の場合、`kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`によってラベルが付与されます。 </del> <ins> [`NodeRestriction`アドミッションプラグイン](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)は、kubeletが`node-restriction.kubernetes.io/`というプレフィックスを持つラベルを設定または変更するのを防ぎます。 </ins> <del> `kubectl get nodes --show-labels`によって、ノードにラベルが付与されたかを確認することができます。 また、`kubectl describe node "nodename"`から、そのNodeの全てのラベルを表示することもできます。 </del> <ins> ラベルプレフィックスをNode分離に利用するには: </ins> <del> ### ステップ2: PodへのnodeSelectorフィールドの追加 </del> <ins> 1. [Node認可](/docs/reference/access-authn-authz/node/)を使用していることと、`NodeRestriction` アドミッションプラグインが _有効_ になっていることを確認します。 2. `node-restriction.kubernetes.io/`プレフィックスを持つラベルをNodeに追加し、 [nodeSelector](#nodeselector)でそれらのラベルを使用します。 例えば、`example.com.node-restriction.kubernetes.io/fips=true`や`example.com.node-restriction.kubernetes.io/pci-dss=true`などです。 </ins> <del> 該当のPodのconfigファイルに、nodeSelectorのセクションを追加します: 例として以下のconfigファイルを扱います: </del> <ins> ## nodeSelector {#nodeselector} </ins> <del> ```yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx ``` </del> <ins> `nodeSelector`は、Node選択制約の中で最もシンプルな推奨形式です。 Podのspec(仕様)に`nodeSelector`フィールドを追加することで、ターゲットNodeが持つべき[Nodeラベル](#built-in-node-labels)を指定できます。 Kubernetesは指定された各ラベルを持つNodeにのみ、Podをスケジューリングします。 詳しい情報については[PodをNodeに割り当てる](/ja/docs/tasks/configure-pod-container/assign-pods-nodes/)を参照してください。 </ins> <del> nodeSelectorを以下のように追加します: </del> <ins> ## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} </ins> <del> {{< codenew file="pods/pod-nginx.yaml" >}} </del> <ins> `nodeSelector`はPodを特定のラベルが付与されたNodeに制限する最も簡単な方法です。 アフィニティとアンチアフィニティでは、定義できる制約の種類が拡張されています。 アフィニティとアンチアフィニティのメリットは以下の通りです。 </ins> <del> `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`により、Podは先ほどラベルを付与したNodeへスケジュールされます。 `kubectl get pods -o wide`で表示される"NODE"の列から、PodがデプロイされているNodeを確認することができます。 </del> <ins> * アフィニティとアンチアフィニティで使われる言語は、より表現力が豊かです。`nodeSelector`は指定されたラベルを全て持つNodeを選択するだけです。アフィニティとアンチアフィニティは選択ロジックをより細かく制御することができます。 * ルールが*柔軟*であったり*優先*での指定ができたりするため、一致するNodeが見つからない場合でも、スケジューラーはPodをスケジュールします。 * Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルを使ってPodを制約することができます。これにより、Node上にどのPodを共存させるかのルールを定義することができます。 </ins> <del> ## 補足: ビルトインNodeラベル {#built-in-node-labels} </del> <ins> アフィニティ機能は、2種類のアフィニティで構成されています: </ins> <del> 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。 </del> <ins> * *Nodeアフィニティ*は`nodeSelector`フィールドと同様に機能しますが、より表現力が豊かで、より柔軟にルールを指定することができます。 * *Pod間アフィニティとアンチアフィニティ*は、他のPodのラベルを元に、Podを制約することができます。 </ins> <del> {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 例えば、`kubernetes.io/hostname`の値はNodeの名前と同じである環境もあれば、異なる環境もあります。 {{< /note >}} </del> <ins> ### Nodeアフィニティ {#node-affinity} Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 </ins> <del> ## Nodeの隔離や制限 Nodeにラベルを付与することで、Podは特定のNodeやNodeグループにスケジュールされます。 これにより、特定のPodを、確かな隔離性や安全性、特性を持ったNodeで稼働させることができます。 この目的でラベルを使用する際に、Node上のkubeletプロセスに上書きされないラベルキーを選択することが強く推奨されています。 これは、安全性が損なわれたNodeがkubeletの認証情報をNodeのオブジェクトに設定したり、スケジューラーがそのようなNodeにデプロイすることを防ぎます。 </del> <ins> Nodeアフィニティには2種類あります: </ins> <del> `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 </del> <ins> * `requiredDuringSchedulingIgnoredDuringExecution`: スケジューラーは、ルールが満たされない限り、Podをスケジュールすることができません。これは`nodeSelector`と同じように機能しますが、より表現力豊かな構文になっています。 * `preferredDuringSchedulingIgnoredDuringExecution`: スケジューラーは、対応するルールを満たすNodeを探そうとします。 一致するNodeが見つからなくても、スケジューラーはPodをスケジュールします。 </ins> <del> 1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。 2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 </del> <ins> {{<note>}} 上記の2種類にある`IgnoredDuringExecution`は、KubernetesがPodをスケジュールした後にNodeラベルが変更されても、Podは実行し続けることを意味します。 {{</note>}} </ins> <del> ## アフィニティとアンチアフィニティ {#affinity-and-anti-affinity} </del> <ins> Podのspec(仕様)にある`.spec.affinity.nodeAffinity`フィールドを使用して、Nodeアフィニティを指定することができます。 </ins> <del> `nodeSelector`はPodの稼働を特定のラベルが付与されたNodeに制限する最も簡単な方法です。 アフィニティ/アンチアフィニティでは、より柔軟な指定方法が提供されています。 拡張機能は以下の通りです。 </del> <ins> 例えば、次のようなPodのspec(仕様)を考えてみましょう: </ins> <del> 1. アフィニティ/アンチアフィニティという用語はとても表現豊かです。この用語は論理AND演算で作成された完全一致だけではなく、より多くのマッチングルールを提供します。 2. 必須条件ではなく優先条件を指定でき、条件を満たさない場合でもPodをスケジュールさせることができます。 3. Node自体のラベルではなく、Node(または他のトポロジカルドメイン)上で稼働している他のPodのラベルに対して条件を指定することができ、そのPodと同じ、または異なるドメインで稼働させることができます。 </del> <ins> {{< codenew file="pods/pod-with-node-affinity.yaml" >}} </ins> <del> アフィニティは"Nodeアフィニティ"と"Pod間アフィニティ/アンチアフィニティ"の2種類から成ります。 Nodeアフィニティは`nodeSelector`(前述の2つのメリットがあります)に似ていますが、Pod間アフィニティ/アンチアフィニティは、上記の3番目の機能に記載している通り、NodeのラベルではなくPodのラベルに対して制限をかけます。 </del> <ins> この例では、以下のルールが適用されます: </ins> <del> ### Nodeアフィニティ </del> <ins> * Nodeには`topology.kubernetes.io/zone`をキーとするラベルが*必要*で、そのラベルの値は`antarctica-east1`または`antarctica-west1`のいずれかでなければなりません。 * Nodeにはキー名が`another-node-label-key`で、値が`another-node-label-value`のラベルを持つことが*望ましい*です。 </ins> <del> Nodeアフィニティは概念的には、NodeのラベルによってPodがどのNodeにスケジュールされるかを制限する`nodeSelector`と同様です。 </del> <ins> `operator`フィールドを使用して、Kubernetesがルールを解釈する際に使用できる論理演算子を指定することができます。`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`が使用できます。 </ins> <del> 現在は2種類のNodeアフィニティがあり、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`です。 前者はNodeにスケジュールされるPodが条件を満たすことが必須(`nodeSelector`に似ていますが、より柔軟に条件を指定できます)であり、後者は条件を指定できますが保証されるわけではなく、優先的に考慮されます。 "IgnoredDuringExecution"の意味するところは、`nodeSelector`の機能と同様であり、Nodeのラベルが変更され、Podがその条件を満たさなくなった場合でも PodはそのNodeで稼働し続けるということです。 将来的には、`requiredDuringSchedulingIgnoredDuringExecution`に、PodのNodeアフィニティに記された必須要件を満たさなくなったNodeからそのPodを退避させることができる機能を備えた`requiredDuringSchedulingRequiredDuringExecution`が提供される予定です。 </del> <ins> `NotIn`と`DoesNotExist`を使って、Nodeのアンチアフィニティ動作を定義することができます。また、[NodeのTaint](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)を使用して、特定のNodeからPodをはじくこともできます。 </ins> <del> それぞれの使用例として、 `requiredDuringSchedulingIgnoredDuringExecution` は、"インテルCPUを供えたNode上でPodを稼働させる"、 `preferredDuringSchedulingIgnoredDuringExecution`は、"ゾーンXYZでPodの稼働を試みますが、実現不可能な場合には他の場所で稼働させる" といった方法が挙げられます。 </del> <ins> {{<note>}} `nodeSelector`と`nodeAffinity`の両方を指定した場合、*両方の*条件を満たさないとPodはNodeにスケジュールされません。 </ins> <del> Nodeアフィニティは、PodSpecの`affinity`フィールドにある`nodeAffinity`フィールドで特定します。 </del> <ins> `nodeAffinity`タイプに関連付けられた`nodeSelectorTerms`内に、複数の条件を指定した場合、Podは指定した条件のいずれかを満たしたNodeへスケジュールされます(条件はORされます)。 </ins> <del> Nodeアフィニティを使用したPodの例を以下に示します: </del> <ins> `nodeSelectorTerms`内の条件に関連付けられた1つの`matchExpressions`フィールド内に、複数の条件を指定した場合、Podは全ての条件を満たしたNodeへスケジュールされます(条件はANDされます)。 {{</note>}} </ins> <del> {{< codenew file="pods/pod-with-node-affinity.yaml" >}} </del> <ins> 詳細については[Nodeアフィニティを利用してPodをNodeに割り当てる](/ja/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)を参照してください。 #### Nodeアフィニティの重み `preferredDuringSchedulingIgnoredDuringExecution`アフィニティタイプの各インスタンスに、1から100の範囲の`weight`を指定できます。 Podの他のスケジューリング要件をすべて満たすNodeを見つけると、スケジューラーはそのNodeが満たすすべての優先ルールを繰り返し実行し、対応する式の`weight`値を合計に加算します。 最終的な合計は、そのNodeの他の優先度関数のスコアに加算されます。合計スコアが最も高いNodeが、スケジューラーがPodのスケジューリングを決定する際に優先されます。 例えば、次のようなPodのspec(仕様)を考えてみましょう: {{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}} </ins> <del> このNodeアフィニティでは、Podはキーが`kubernetes.io/e2e-az-name`、値が`e2e-az1`または`e2e-az2`のラベルが付与されたNodeにしか配置されません。 加えて、キーが`another-node-label-key`、値が`another-node-label-value`のラベルが付与されたNodeが優先されます。 </del> <ins> `preferredDuringSchedulingIgnoredDuringExecution`ルールにマッチするNodeとして、一つは`label-1:key-1`ラベル、もう一つは`label-2:key-2`ラベルの2つの候補がある場合、スケジューラーは各Nodeの`weight`を考慮し、その重みとNodeの他のスコアを加え、最終スコアが最も高いNodeにPodをスケジューリングします。 </ins> <del> この例ではオペレーター`In`が使われています。 Nodeアフィニティでは、`In`、`NotIn`、`Exists`、`DoesNotExist`、`Gt`、`Lt`のオペレーターが使用できます。 `NotIn`と`DoesNotExist`はNodeアンチアフィニティ、またはPodを特定のNodeにスケジュールさせない場合に使われる[Taints](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)に使用します。 </del> <ins> {{<note>}} この例でKubernetesにPodを正常にスケジュールさせるには、`kubernetes.io/os=linux`ラベルを持つ既存のNodeが必要です。 {{</note>}} </ins> <del> `nodeSelector`と`nodeAffinity`の両方を指定した場合、Podは**両方の**条件を満たすNodeにスケジュールされます。 </del> <ins> #### スケジューリングプロファイルごとのNodeアフィニティ {#node-affinity-per-scheduling-profile} </ins> <del> `nodeAffinity`内で複数の`nodeSelectorTerms`を指定した場合、Podは**いずれかの**`nodeSelectorTerms`を満たしたNodeへスケジュールされます。 </del> <ins> {{< feature-state for_k8s_version="v1.20" state="beta" >}} </ins> <del> `nodeSelectorTerms`内で複数の`matchExpressions`を指定した場合にはPodは**全ての**`matchExpressions`を満たしたNodeへスケジュールされます。 </del> <ins> 複数の[スケジューリングプロファイル](/ja/docs/reference/scheduling/config/#multiple-profiles)を設定する場合、プロファイルにNodeアフィニティを関連付けることができます。これは、プロファイルが特定のNode群にのみ適用される場合に便利です。[スケジューラーの設定](/ja/docs/reference/scheduling/config/)にある[`NodeAffinity`プラグイン](/ja/docs/reference/scheduling/config/#scheduling-plugins)の`args`フィールドに`addedAffinity`を追加すると実現できます。例えば: </ins> <del> PodがスケジュールされたNodeのラベルを削除したり変更しても、Podは削除されません。 言い換えると、アフィニティはPodをスケジュールする際にのみ考慮されます。 </del> <ins> ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler - schedulerName: foo-scheduler pluginConfig: - name: NodeAffinity args: addedAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: scheduler-profile operator: In values: - foo ``` `addedAffinity`は、Podの仕様(spec)で指定されたNodeアフィニティに加え、`.spec.schedulerName`を`foo-scheduler`に設定したすべてのPodに適用されます。つまり、Podにマッチするためには、Nodeは`addedAffinity`とPodの`.spec.NodeAffinity`を満たす必要があるのです。 `addedAffinity`はエンドユーザーには見えないので、その動作はエンドユーザーにとって予期しないものになる可能性があります。スケジューラープロファイル名と明確な相関関係のあるNodeラベルを使用すべきです。 {{< note >}} [DaemonSetのPodを作成する](/ja/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)DaemonSetコントローラーは、スケジューリングプロファイルをサポートしていません。DaemonSetコントローラーがPodを作成すると、デフォルトのKubernetesスケジューラーがそれらのPodを配置し、DaemonSetコントローラーの`nodeAffinity`ルールに優先して従います。 {{< /note >}} </ins> <del> `preferredDuringSchedulingIgnoredDuringExecution`内の`weight`フィールドは、1から100の範囲で指定します。 全ての必要条件(リソースやRequiredDuringSchedulingアフィニティ等)を満たしたNodeに対して、スケジューラーはそのNodeがMatchExpressionsを満たした場合に、このフィルードの"weight"を加算して合計を計算します。 このスコアがNodeの他の優先機能のスコアと組み合わせれ、最も高いスコアを有したNodeが優先されます。 </del> <ins> ### Pod間のアフィニティとアンチアフィニティ </ins> <del> ### Pod間アフィニティとアンチアフィニティ </del> <ins> Pod間のアフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNode上で稼働している**Pod**のラベルに従って、PodがどのNodeにスケジュールされるかを制限できます。 </ins> <del> Pod間アフィニティとアンチアフィニティは、Nodeのラベルではなく、すでにNodeで稼働しているPodのラベルに従ってPodがスケジュールされるNodeを制限します。 このポリシーは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで稼働させる(アンチアフィニティの場合は稼働させない)"という形式です。 Yはnamespaceのリストで指定したLabelSelectorで表されます。 Nodeと異なり、Podはnamespaceで区切られているため(それゆえPodのラベルも暗黙的にnamespaceで区切られます)、Podのラベルを指定するlabel selectorは、どのnamespaceにselectorを適用するかを指定する必要があります。 概念的に、XはNodeや、ラック、クラウドプロバイダゾーン、クラウドプロバイダのリージョン等を表すトポロジードメインです。 これらを表すためにシステムが使用するNodeラベルのキーである`topologyKey`を使うことで、トポロジードメインを指定することができます。 先述のセクション[補足: ビルトインNodeラベル](#interlude-built-in-node-labels)にてラベルの例が紹介されています。 </del> <ins> XはNodeや、ラック、クラウドプロバイダーのゾーンやリージョン等を表すトポロジードメインで、YはKubernetesが満たそうとするルールである場合、Pod間のアフィニティとアンチアフィニティのルールは、"XにてルールYを満たすPodがすでに稼働している場合、このPodもXで実行すべき(アンチアフィニティの場合はすべきではない)"という形式です。 これらのルール(Y)は、オプションの関連する名前空間のリストを持つ[ラベルセレクター](/ja/docs/concepts/overview/working-with-objects/labels/#label-selectors)で表現されます。PodはKubernetesの名前空間オブジェクトであるため、Podラベルも暗黙的に名前空間を持ちます。Kubernetesが指定された名前空間でラベルを探すため、Podラベルのラベルセレクターは、名前空間を指定する必要があります。 トポロジードメイン(X)は`topologyKey`で表現され、システムがドメインを示すために使用するNodeラベルのキーになります。具体例は[よく知られたラベル、アノテーションとTaint](/docs/reference/labels-annotations-taints/)を参照してください。 </ins> {{< note >}} <del> Pod間アフィニティとアンチアフィニティは、大規模なクラスター上で使用する際にスケジューリングを非常に遅くする恐れのある多くの処理を要します。 そのため、数百台以上のNodeから成るクラスターでは使用することを推奨されません。 </del> <ins> Pod間アフィニティとアンチアフィニティはかなりの処理量を必要とするため、大規模クラスターでのスケジューリングが大幅に遅くなる可能性があります そのため、数百台以上のNodeから成るクラスターでの使用は推奨されません。 </ins> {{< /note >}} {{< note >}} <del> Podのアンチアフィニティは、Nodeに必ずラベルが付与されている必要があります。 言い換えると、クラスターの全てのNodeが、`topologyKey`で指定されたものに合致する適切なラベルが必要になります。 それらが付与されていないNodeが存在する場合、意図しない挙動を示すことがあります。 </del> <ins> Podのアンチアフィニティは、Nodeに必ず一貫性の持つラベルが付与されている必要があります。 言い換えると、クラスターの全てのNodeが、`topologyKey`に合致する適切なラベルが必要になります。 一部、または全部のNodeに`topologyKey`ラベルが指定されていない場合、意図しない挙動に繋がる可能性があります。 </ins> {{< /note >}} <del> Nodeアフィニティと同様に、PodアフィニティとPodアンチアフィニティにも必須条件と優先条件を示す`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`があります。 前述のNodeアフィニティのセクションを参照してください。 `requiredDuringSchedulingIgnoredDuringExecution`を指定するアフィニティの使用例は、"Service AのPodとService BのPodが密に通信する際、それらを同じゾーンで稼働させる場合"です。 また、`preferredDuringSchedulingIgnoredDuringExecution`を指定するアンチアフィニティの使用例は、"ゾーンをまたいでPodのサービスを稼働させる場合"(Podの数はゾーンの数よりも多いため、必須条件を指定すると合理的ではありません)です。 </del> <ins> #### Pod間のアフィニティとアンチアフィニティの種類 [Nodeアフィニティ](#node-affinity)と同様に、Podアフィニティとアンチアフィニティにも下記の2種類があります: * `requiredDuringSchedulingIgnoredDuringExecution` * `preferredDuringSchedulingIgnoredDuringExecution` </ins> <del> Pod間アフィニティは、PodSpecの`affinity`フィールド内に`podAffinity`で指定し、Pod間アンチアフィニティは、`podAntiAffinity`で指定します。 </del> <ins> 例えば、`requiredDuringSchedulingIgnoredDuringExecution`アフィニティを使用して、2つのサービスのPodはお互いのやり取りが多いため、同じクラウドプロバイダーゾーンに併置するようにスケジューラーに指示することができます。 同様に、`preferredDuringSchedulingIgnoredDuringExecution`アンチアフィニティを使用して、あるサービスのPodを複数のクラウドプロバイダーゾーンに分散させることができます。 </ins> <del> #### Podアフィニティを使用したPodの例 </del> <ins> Pod間アフィニティを使用するには、Pod仕様(spec)の`affinity.podAffinity`フィールドで指定します。Pod間アンチアフィニティを使用するには、Pod仕様(spec)の`affinity.podAntiAffinity`フィールドで指定します。 #### Podアフィニティ使用例 {#an-example-of-a-pod-that-uses-pod-affinity} 次のようなPod仕様(spec)を考えてみましょう: </ins> {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} <del> このPodのアフィニティは、PodアフィニティとPodアンチアフィニティを1つずつ定義しています。 この例では、`podAffinity`に`requiredDuringSchedulingIgnoredDuringExecution`、`podAntiAffinity`に`preferredDuringSchedulingIgnoredDuringExecution`が設定されています。 Podアフィニティは、「キーが"security"、値が"S1"のラベルが付与されたPodが少なくとも1つは稼働しているNodeが同じゾーンにあれば、PodはそのNodeにスケジュールされる」という条件を指定しています(より正確には、キーが"security"、値が"S1"のラベルが付与されたPodが稼働しており、キーが`topology.kubernetes.io/zone`、値がVであるNodeが少なくとも1つはある状態で、 Node Nがキー`topology.kubernetes.io/zone`、値Vのラベルを持つ場合に、PodはNode Nで稼働させることができます)。 Podアンチアフィニティは、「すでにあるNode上で、キーが"security"、値が"S2"であるPodが稼働している場合に、Podを可能な限りそのNode上で稼働させない」という条件を指定しています (`topologyKey`が`topology.kubernetes.io/zone`であった場合、キーが"security"、値が"S2"であるであるPodが稼働しているゾーンと同じゾーン内のNodeにはスケジュールされなくなります)。 PodアフィニティとPodアンチアフィニティや、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`に関する他の使用例は[デザインドック](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)を参照してください。 </del> <ins> この例では、PodアフィニティルールとPodアンチアフィニティルールを1つずつ定義しています。 Podアフィニティルールは"ハード"な`requiredDuringSchedulingIgnoredDuringExecution`を使用し、アンチアフィニティルールは"ソフト"な`preferredDuringSchedulingIgnoredDuringExecution`を使用しています。 </ins> <del> PodアフィニティとPodアンチアフィニティで使用できるオペレーターは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 </del> <ins> アフィニティルールは、スケジューラーがNodeにPodをスケジュールできるのは、そのNodeが、`security=S1`ラベルを持つ1つ以上の既存のPodと同じゾーンにある場合のみであることを示しています。より正確には、現在Podラベル`security=S1`を持つPodが1つ以上あるNodeが、そのゾーン内に少なくとも1つ存在する限り、スケジューラーは`topology.kubernetes.io/zone=V`ラベルを持つNodeにPodを配置しなければなりません。 </ins> <del> 原則として、`topologyKey`には任意のラベルとキーが使用できます。 しかし、パフォーマンスやセキュリティの観点から、以下の制約があります: </del> <ins> アンチアフィニティルールは、`security=S2`ラベルを持つ1つ以上のPodと同じゾーンにあるNodeには、スケジューラーがPodをスケジュールしないようにすることを示しています。より正確には、Podラベル`Security=S2`を持つPodが稼働している他のNodeが、同じゾーン内に存在する場合、スケジューラーは`topology.kubernetes.io/zone=R`ラベルを持つNodeにはPodを配置しないようにしなければなりません。 </ins> <del> 1. アフィニティと、`requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティは、`topologyKey`を指定しないことは許可されていません。 2. `requiredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`kubernetes.io/hostname`の`topologyKey`を制限するため、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が導入されました。 トポロジーをカスタマイズする場合には、アドミッションコントローラーを修正または無効化する必要があります。 3. `preferredDuringSchedulingIgnoredDuringExecution`を指定したPodアンチアフィニティでは、`topologyKey`を省略することはできません。 4. 上記の場合を除き、`topologyKey` は任意のラベルとキーを指定することができます。 </del> <ins> Podアフィニティとアンチアフィニティの使用例についてもっと知りたい方は[デザイン案](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md)を参照してください。 </ins> <del> `labelSelector`と`topologyKey`に加え、`labelSelector`が合致すべき`namespaces`のリストを特定することも可能です(これは`labelSelector`と`topologyKey`を定義することと同等です)。 省略した場合や空の場合は、アフィニティとアンチアフィニティが定義されたPodのnamespaceがデフォルトで設定されます。 </del> <ins> Podアフィニティとアンチアフィニティの`operator`フィールドで使用できるのは、`In`、`NotIn`、 `Exists`、 `DoesNotExist`です。 </ins> <del> `requiredDuringSchedulingIgnoredDuringExecution`が指定されたアフィニティとアンチアフィニティでは、`matchExpressions`に記載された全ての条件が満たされるNodeにPodがスケジュールされます。 </del> <ins> 原則として、`topologyKey`には任意のラベルキーが指定できますが、パフォーマンスやセキュリティの観点から、以下の例外があります: * Podアフィニティとアンチアフィニティでは、`requiredDuringSchedulingIgnoredDuringExecution`と`preferredDuringSchedulingIgnoredDuringExecution`内のどちらも、`topologyKey`フィールドが空であることは許可されていません。 * Podアンチアフィニティルールの`requiredDuringSchedulingIgnoredDuringExecution`では、アドミッションコントローラー`LimitPodHardAntiAffinityTopology`が`topologyKey`を`kubernetes.io/hostname`に制限しています。アドミッションコントローラーを修正または無効化すると、トポロジーのカスタマイズができるようになります。 </ins> <del> #### 実際的なユースケース </del> <ins> `labelSelector`と`topologyKey`に加え、`labelSelector`と`topologyKey`と同じレベルの`namespaces`フィールドを使用して、`labelSelector`が合致すべき名前空間のリストを任意に指定することができます。省略または空の場合、`namespaces`がデフォルトで、アフィニティとアンチアフィニティが定義されたPodの名前空間に設定されます。 </ins> <del> Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。 Workloadが、Node等の定義された同じトポロジーに共存させるよう、簡単に設定できます。 </del> <ins> #### 名前空間セレクター {{< feature-state for_k8s_version="v1.24" state="stable" >}} `namespaceSelector`を使用し、ラベルで名前空間の集合に対して検索することによって、名前空間を選択することができます。 アフィニティ項は`namespaceSelector`と`namespaces`フィールドによって選択された名前空間に適用されます。 要注意なのは、空の`namespaceSelector`({})はすべての名前空間にマッチし、nullまたは空の`namespaces`リストとnullの`namespaceSelector`は、ルールが定義されているPodの名前空間にマッチします。 </ins> <del> ##### 常に同じNodeで稼働させる場合 </del> <ins> #### 実践的なユースケース </ins> <del> ３つのノードから成るクラスターでは、ウェブアプリケーションはredisのようにインメモリキャッシュを保持しています。 このような場合、ウェブサーバーは可能な限りキャッシュと共存させることが望ましいです。 </del> <ins> Pod間アフィニティとアンチアフィニティは、ReplicaSet、StatefulSet、Deploymentなどのより高レベルなコレクションと併せて使用するとさらに有用です。これらのルールにより、ワークロードのセットが同じ定義されたトポロジーに併置されるように設定できます。たとえば、2つの関連するPodを同じNodeに配置することが好ましい場合です。 </ins> <del> ラベル`app=store`を付与した3つのレプリカから成るredisのdeploymentを記述したyamlファイルを示します。 Deploymentには、1つのNodeにレプリカを共存させないために`PodAntiAffinity`を付与しています。 </del> <ins> 例えば、3つのNodeで構成されるクラスターを想像してください。そのクラスターを使用してウェブアプリケーションを実行し、さらにインメモリーキャッシュ(Redisなど)を使用します。この例では、ウェブアプリケーションとメモリーキャッシュの間のレイテンシーは実用的な範囲の低さも想定しています。Pod間アフィニティやアンチアフィニティを使って、ウェブサーバーとキャッシュをなるべく同じ場所に配置することができます。 以下のRedisキャッシュのDeploymentの例では、各レプリカはラベル`app=store`が付与されています。`podAntiAffinity`ルールは、`app=store`ラベルを持つ複数のレプリカを単一Nodeに配置しないよう、スケジューラーに指示します。これにより、各キャッシュが別々のNodeに作成されます。 </ins> ```yaml apiVersion: apps/v1

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