kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
website/content/ja/docs/concepts/scheduling-eviction/pod-scheduling-readiness.md

6.1 KiB
Raw Permalink Blame History

title content_type weight
Podのスケジューリング準備 concept 40

{{< feature-state for_k8s_version="v1.30" state="stable" >}}

Podは1度作成されると、スケジュールの準備ができたとみなされます。Kubernetesのスケジューラーは、すべての保留中のPodを配置するためにノードを見つけることに最善を尽くします。しかし実際のケースでは、一部のPodが「必要なリソースを満たさない」状態に長期間とどまることがあります。このようなPodは、実際にはスケジューラー(およびCluster AutoScalerのようなダウンストリームのインテグレーター)を不必要に混乱させます。

Podの.spec.schedulingGatesを指定したり削除したりすることで、Podがスケジューリングの対象になるタイミングを制御できます。

PodにschedulingGatesを設定する

schedulingGatesのフィールドは、文字列のリストで構成されており、各文字列はPodがスケジューリング可能とみなされる前に満たすべき条件を表します。このフィールドは、Pod作成時のみ初期化できます(クライアントによる作成時、またはアドミッション中の変更時)。作成後、個々のschedulingGateは順序不同で削除できますが、新しいschedulingGateを追加することはできません。

{{< figure src="/docs/images/podSchedulingGates.svg" alt="pod-scheduling-gates-diagram" caption="Pod スケジューリングゲートの図" class="diagram-large" link="https://mermaid.live/edit#pako:eNplkktTwyAUhf8KgzuHWpukaYszutGlK3caFxQuCVMCGSDVTKf_XfKyPlhxz4HDB9wT5lYAptgHFuBRsdKxenFMClMYFIdfUdRYgbiD6ItJTEbR8wpEq5UpUfnDTf-5cbPoJjcbXdcaE61RVJIiqJvQ_Y30D-OCt-t3tFjcR5wZayiVnIGmkv4NiEfX9jijKTmmRH5jf0sRugOP0HyHUc1m6KGMFP27cM28fwSJDluPpNKaXqVJzmFNfHD2APRKSjnNFx9KhIpmzSfhVls3eHdTRrwG8QnxKfEZUUNeYTDBNbiaKRF_5dSfX-BQQQ0FpnEqQLJWhwIX5hyXsjbYl85wTINrgeC2EZd_xFQy7b_VJ6GCdd-itkxALE84dE3fAqXyIUZya6Qqe711OspVCI2ny2Vv35QqVO3-htt66ZWomAvVcZcv8yTfsiSFfJOydZoKvl_ttjLJVlJsblcJw-czwQ0zr9ZeqGDgeR77b2jD8xdtjtDn" >}}

使用例

Podがスケジューリングされる準備ができていないと示すには、次のように1つ以上のスケジューリングゲートを使って作成します。

{{% code_sample file="pods/pod-with-scheduling-gates.yaml" %}}

Podの作成後、状態を確認するには以下のようにします。

kubectl get pod test-pod

出力からSchedulingGated状態であることがわかります。

NAME       READY   STATUS            RESTARTS   AGE
test-pod   0/1     SchedulingGated   0          7s

また、schedulingGatesフィールドから確認することもできます。

kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'

出力は以下のようになります。

[{"name":"example.com/foo"},{"name":"example.com/bar"}]

このPodがスケジューリング可能であることをスケジューラーに知らせるには、変更したマニフェストを再適用することで、schedulingGatesを完全に削除できます。

{{% code_sample file="pods/pod-without-scheduling-gates.yaml" %}}

schedulingGatesが削除されているかどうかは、以下のように確認できます。

kubectl get pod test-pod -o jsonpath='{.spec.schedulingGates}'

出力は、空であることが期待されます。そして、以下のように実行することで最新の状態を確認することができます。

kubectl get pod test-pod -o wide

test-podがCPU/メモリリソースを要求しないため、このPodのステータスは、以前のSchedulingGatedからRunningに遷移することが予想されます。

NAME       READY   STATUS    RESTARTS   AGE   IP         NODE
test-pod   1/1     Running   0          15s   10.0.0.4   node-2

可観測性

scheduler_pending_podsメトリックには、Podがスケジューリングされようとしているがスケジューリング不可能とされているのか、それとも明示的にスケジューリングの準備ができておらずマークされているのかを区別する新しいラベル"gated"があります。scheduler_pending_pods{queue="gated"}でメトリックの結果を確認できます。

変更可能なPodのスケジューリング命令

Podにスケジューリングゲートが設定されている間、Podのスケジューリング命令は、一定の制約のもとで変更できます。高いレベルでは、Podのスケジューリング命令を厳格にすることしかできません。言い換えると、更新された命令は、Podが以前マッチしていたノードのサブセットでしかスケジューリングできなくなります。より具体的には、Podのスケジューリング命令を更新するルールは以下のようになります。

  1. .spec.nodeSelectorは、追加のみが許可されます。 存在しない場合は設定が許可されます。

  2. spec.affinity.nodeAffinityは、空の場合、何でも設定できます。

  3. NodeSelectorTermsが空の場合、設定が許可されます。 空でない場合は、matchExpressionsまたはfieldExpressionsへのNodeSelectorRequirementsの追加のみが許可され、既存のmatchExpressionsおよびfieldExpressionsへの変更は許可されません。これは、.requiredDuringSchedulingIgnoredDuringExecution.NodeSelectorTermsの項目がORで結合されるのに対し、nodeSelectorTerms[].matchExpressionsおよびnodeSelectorTerms[].fieldExpressionsの項目はANDで結合されるためです。

  4. .preferredDuringSchedulingIgnoredDuringExecutionは、すべての更新が許可されます。これは、優先項目の権威がないため、ポリシーコントローラーがこれらの項目を検証しないためです。

{{% heading "whatsnext" %}}