Podのスケジューリング準備
Kubernetes v1.30 [stable]
Podは1度作成されると、スケジュールの準備ができたとみなされます。Kubernetesのスケジューラーは、すべての保留中のPodを配置するためにノードを見つけることに最善を尽くします。しかし実際のケースでは、一部のPodが「必要なリソースを満たさない」状態に長期間とどまることがあります。このようなPodは、実際にはスケジューラー(およびCluster AutoScalerのようなダウンストリームのインテグレーター)を不必要に混乱させます。
Podの.spec.schedulingGates
を指定したり削除したりすることで、Podがスケジューリングの対象になるタイミングを制御できます。
PodにschedulingGatesを設定する
schedulingGates
のフィールドは、文字列のリストで構成されており、各文字列はPodがスケジューリング可能とみなされる前に満たすべき条件を表します。このフィールドは、Pod作成時のみ初期化できます(クライアントによる作成時、またはアドミッション中の変更時)。作成後、個々のschedulingGateは順序不同で削除できますが、新しいschedulingGateを追加することはできません。
使用例
Podがスケジューリングされる準備ができていないと示すには、次のように1つ以上のスケジューリングゲートを使って作成します。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
schedulingGates:
- name: example.com/foo
- name: example.com/bar
containers:
- name: pause
image: registry.k8s.io/pause:3.6
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
を完全に削除できます。
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: pause
image: registry.k8s.io/pause:3.6
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のスケジューリング命令を更新するルールは以下のようになります。
.spec.nodeSelector
は、追加のみが許可されます。 存在しない場合は設定が許可されます。spec.affinity.nodeAffinity
は、空の場合、何でも設定できます。NodeSelectorTerms
が空の場合、設定が許可されます。 空でない場合は、matchExpressions
またはfieldExpressions
へのNodeSelectorRequirements
の追加のみが許可され、既存のmatchExpressions
およびfieldExpressions
への変更は許可されません。これは、.requiredDuringSchedulingIgnoredDuringExecution.NodeSelectorTerms
の項目がORで結合されるのに対し、nodeSelectorTerms[].matchExpressions
およびnodeSelectorTerms[].fieldExpressions
の項目はANDで結合されるためです。.preferredDuringSchedulingIgnoredDuringExecution
は、すべての更新が許可されます。これは、優先項目の権威がないため、ポリシーコントローラーがこれらの項目を検証しないためです。
次の項目
- 詳しくはPodSchedulingReadiness KEPをお読みください。