Podが見えないときは、実行許可の前後を分ける

Jobが始まらず、Podも一つも見えないときがあります。Kueueで管理するJobでは、Podの配置先を決める前に、利用枠の予約や実行許可を待っている場合があります。Jobは完了までの処理を管理するKubernetesのリソース、Podはコンテナを動かす単位です [3, 4]。

Kueueはバッチ処理などの利用枠を調整する仕組みです。Kubernetesを操作・確認するWeb UIのHeadlampには、Kueue用のプラグインがあります。Jobなどの要求量と許可状態を表すWorkloadから、関連するキューをリンクでたどれます [26, 27]。

まず、KueueがWorkloadに実行許可を出したかどうかを確認します。この判断をadmissionと呼びます。許可前は予約や検査を、許可後はJobとPodの状態を確認します。Admitted=TrueはKueueの実行許可を示します。アプリケーションの稼働状況はJobとPodで確認します [11]。

予約とadmissionは、別の条件で確認する

まずHeadlampの「Kueue → Workloads」で対象の名前空間（リソースを分けて管理する区画）を選び、Workloadを開きます。詳細画面のconditionは状態を示し、reasonとmessageは理由を読む手掛かりになります [27]。

quotaはリソースの割当枠です。QuotaReservedとAdmittedを分けて読むと、次に調べる場所を絞れます。

Workloadで見る状態読み取れること次の確認
QuotaReserved=False現在は割当枠を予約していないreasonがPendingかInadmissibleか、messageに何が記されているかを読む [5]
conditionがまだない未試行の場合もあるStrictFIFOでは各ClusterQueue内で優先度、次いで作成時刻の順に評価する。先頭をadmitできないと後続も待つため、未試行のWorkloadもある。キューの順序や状態を確認する [6]（評価順序の公式説明）
QuotaReserved=TrueだがAdmitted=Trueではない予約後の実行条件を満たしていない可能性がある必要なAdmissionChecksのstateとmessageを確認する [7]
Admitted=TrueKueueの実行許可は通過しているJobの停止状態、Podの配置・コンテナ起動を調べる [11, 12]

AdmissionChecksは、実行許可に必要な追加条件を検査する仕組みです。必要な検査がすべてReadyになるまでWorkloadはadmittedになりません。status.admissionの割当情報は、Workloadに割り当てた資源量を示します。稼働状況はJobとPodで確認します [7, 17]。

各検査のstateは、未実施・未完了のPending、合格のReady、一時的に通らず再試行するRetry、近いうちに合格する見込みがないRejectedです。messageが空の場合もあるため、stateも併せて読みます [8]。

Jobの.spec.suspend=trueは一時停止を表します。Jobコントローラ（Jobを監視してPodを作成・管理する機能）は、新しいPodを作成しません。Podがない段階では、この値と対応するWorkloadを確認します [4]。

一度許可されたWorkloadが、別のWorkloadを受け入れるために退避される場合もあります。これがKueueのpreemptionです。割当枠が不足した場合に他のWorkloadを退避できるかは、設定や優先度などで決まります [9]。対象のEvicted=True、reasonのPreemptedやEvents（最近の出来事の記録）も確認します。suspendは初回の待機後にも確認します [10]。

KueueのWorkload退避と、Pod scheduler（Podをノードに割り当てる機能）のpreemptionは、異なる段階の判断です。前者の状態はWorkloadで、Pod配置に関わる判断はPodの条件やEventsで追います。

後輩割当枠を予約できれば、もう実行中と考えてよいですか？

先輩予約後も必要な検査を待つ場合があるよ。実行許可が出た後にも、Podの配置やコンテナ起動を確認する段階があるんだ。

要求量は、Kueueが計上した値で比較する

PodSetは、Pod数やリソース要求量をまとめた設定単位です [16]。以下では、すべてのPodをまとめて受け入れるケースを例にします。Pod数を示すcountを3とします。Kueueが各Podに算入するCPU request（要求量）が1 CPUなら、PodSetの要求は合計3 CPUです [14]。ここでは、Kueueが計上した要求資源量を比較します。

テンプレートに書いた値だけで判断すると、計上量を見落とす場合があります。要求値などの既定値を設定するLimitRangeや、実行環境の設定であるRuntimeClassに記された追加の要求資源量（overhead）も反映されるためです [15]。

未承認時はspec.podSetsやstatus.resourceRequestsを、予約後はstatus.admission.podSetAssignmentsのcount、割当Flavor（計算資源の特性区分）、resourceUsageを照合します。resourceUsageは、そのPodSetについて計上した総リソース量です。Workloadの要求量は、Jobのparallelism（同時に実行するPod数）やコンテナの指定値と、Workloadに記録された計上値を照合して確認します [16, 17]。

次にWorkloadからLocalQueueへ進みます。LocalQueueは名前空間内の入口で、クラスタ全体の割当枠と規則を持つClusterQueueを参照します。想定したキュー経路かを確認してください [18]。

ResourceFlavorは、GPUの機種やspot／on-demandなど、計算資源の特性の違いを表します [24]。ClusterQueueではResourceFlavorごとに、対象リソースと基準割当量のnominalQuotaを見ます [20]。flavorsReservationは予約されたquota、flavorsUsageはadmitted Workloadに対応する使用quotaの集計です。どちらもCPUやメモリの実測使用率を表す値ではありません [21]。

nominalQuotaと要求量の大小だけでは、待機を断定できません。CohortはClusterQueue間で未使用quotaを融通するグループで、条件を満たせば基準割当量を超えて借用できます [22]。現在の予約と、借用・貸出の上限も合わせて確認します [23]。

nodeSelectorとnodeAffinityは配置先のノード（Podを配置する計算機）の条件、taintとtolerationはノード側の制約とPod側の許容条件です。quota量が足りても、適合するFlavorを割り当てられなければ実行許可には進めません [24]。

確認先見るもの判断の要点
WorkloadPodSetのcount、有効request、予約後の割当個数と資源ごとの要求量を照合する [16, 17]
LocalQueue・ClusterQueueActive条件、reason、message非アクティブなら、参照先や設定の問題を調べる [19]
ClusterQueue対象リソース、nominalQuota、現在の予約・使用quota予約済みの枠も含めて状況を読む [20, 21]
CohortとClusterQueue未使用quota、borrowingLimit、lendingLimit必要なresource・Flavorの枠を、許された範囲で借りられるか確認する [23]
ResourceFlavorラベルやテイントなどの配置条件PodのnodeSelector、必須nodeAffinity、tolerationsとの適合を確認する [24]
ClusterQueue・WorkloadstopPolicy、AdmissionChecks、preemption設定停止や追加検査、他のWorkloadを退避できる条件も確認する [25, 7, 9]

許可後は、Podの配置とコンテナ起動を調べる

Admitted=Trueを確認したら、Headlamp標準のJob・Pod画面へ進みます。Jobが停止されたままか、Podが作られているかを確認し、Podの条件とEventsを読みます [11, 12]。

FailedScheduling（Podの配置失敗を示すイベント）が出たら、ノード容量や配置条件を調べます [12]。トポロジー（ノード間の配置関係）やボリュームの割当も確認します。一方、ノードへ配置済みでもコンテナが起動を待つ場合があります。コンテナのWaiting（起動待ち）と、その理由を確認します。理由がImagePullBackOff（イメージ取得失敗後の再試行待ち）なら、イメージ名、取得先、認証情報を調べます。

PodのPendingは、スケジュール待ちやコンテナ起動準備中の状態を含みます。Pod配置とイメージ取得などの起動処理を分けて調べます。Eventsは保持期間が限られる補助情報なので、完全な長期履歴として扱わず、現在のconditionと併せて確認します [13]。

Headlampは、関連リソースをリンクでたどって調べるための入口です。個別のYAMLを探し回る作業を減らせます [28]。CLIでの確認手順も、公式記事で紹介されています。

alpha版の表示範囲と、実際の操作権限

0.1.0-alphaは、開発初期の試験版を示すHeadlamp用プラグインのバージョンです。Kueue API（ソフトウェア同士で情報をやり取りする仕組み）kueue.x-k8s.io/v1beta2のCohort、ClusterQueue、LocalQueue、ResourceFlavor、Workloadという5種のリソースを表示します [29]。

専用ビューは読み取り専用で、独自の作成・編集・停止・再開・削除フローを追加しません。ただし、Headlamp標準のYAML機能やresource actionsは、利用者のKubernetes RBAC（ロールに基づくAPI操作の認可）に従って動きます。専用画面の読み取り専用設定と、利用者に割り当てられた更新権限は別に管理されます [33]。

専用ページの権限確認では一覧にlist、個別表示にgetを使います。アクセスメッセージが出たら、選択した名前空間と利用者の権限を確認します [30]。閲覧だけを目的にする場合は、対象資源への書き込み権限を含めず、必要な操作の範囲で認可を設計します [33]。

WorkloadのownerReferencesは、所有元を示すKind/nameの文字表示です。クリックしてJobへ直接移動する機能はなく、表示名を手掛かりに標準のJob画面などで探します [31]。このalphaの実測指標の表示や視覚的な関係マップも将来の拡張候補で、現在の専用ビューの機能には含まれません [32]。

後輩プラグインが読み取り専用なら、認証情報の更新権限も制限されますか？

先輩専用画面の機能とAPIの認可は別だよ。標準の操作も含めて、利用者に許す権限を確認する必要があるんだ。

プラグインの公開は2026年8月28日です [1]。調査手順を紹介したHeadlamp原文は10月12日、Kubernetesへのミラー掲載は10月14日であり、掲載日とリリース日は分けて読みます [2]。

この整理は公開資料に基づきます。実クラスタへの導入や、サンプル構成の再現試験は確認範囲に含まれません。利用時は導入済みのKueueとプラグインの版、設定、権限を確認し、実行許可の状態から調べる場所を選んでください。