frontend: Add PodGroup and Workload scheduling views

[Anjali-Chauhan1]

Summary

This PR adds support for Workload-Aware Scheduling in Headlamp by displaying the two new gang-scheduling APIs introduced in Kubernetes v1.36 — PodGroup and Workload (scheduling.k8s.io/v1alpha2). These are built-in aggregated APIs (not CRDs), so Headlamp previously had no way to surface them: they don't appear under Custom Resources or in Advanced Search. As a result, a user whose Pod is stuck Pending because its gang group is incomplete had no way to see why. This PR closes that gap with dedicated list/details views, a Pod → PodGroup link, and a gated sidebar section.

Related Issue

Fixes #6488

Changes

• Added PodGroup and Workload resource classes under lib/k8s/ (podGroup.ts, schedulingWorkload.ts), registered in ResourceClasses.
• Added list + details views for both kinds — PodGroups show Policy (Gang/Basic), Min Count, parent Workload, and scheduling status; Workloads show their Pod Group Templates and controller reference.
• Added a "Scheduling (alpha)" sidebar section, gated on PodGroup.isEnabled() so it only shows on clusters that actually serve the alpha API.
• Added a "Pod Group" row to the Pod details page (issue requirement c), linking a Pod to its scheduling group via the new spec.schedulingGroup.podGroupName field.
• Added unit tests for the new classes and list views, plus translations for all 16 supported locales.
• Fixed a column-width issue so the PodGroups list matches the layout of other Headlamp resource tables.

Steps to Test

Requires a Kubernetes v1.36 cluster with the GenericWorkload feature gate — these APIs are alpha and not served by default. See the demo kind config.

1. Open a cluster with the feature gate → the sidebar shows Scheduling (alpha) with Pod Groups and Workloads.
2. Go to Pod Groups → see the group listed with Policy, Min Count, Workload, and Status. Click it → details show the scheduling policy, template reference (linked to the Workload), and Conditions.
3. Go to Workloads → click a workload → its Pod Group Templates table lists each template's policy and min count.
4. Open a Pod that belongs to a group → the details grid shows a Pod Group row linking to its PodGroup.
5. Open a cluster without the gate (e.g. an older cluster) → confirm the Scheduling (alpha) section does not appear.

Screenshots (if applicable)

Before	After
Pod details — no Pod Group row	Pod details — Pod Group linked
/podgroups → 404	Pod Groups list (Gang + Basic)
(no such page)	PodGroup details + Conditions
(no such page)	Workloads list + details

Workloads

Pod Groups

Notes for the Reviewer

• Naming/collision: The scheduling Workload class lives in schedulingWorkload.ts (not workload.ts) to avoid a case-insensitive filename clash with the existing Workload.ts union type. Its listRoute is overridden to /scheduling/workloads because the workloads route already belongs to the Workloads overview page. It's registered in ResourceClasses keyed by kind (Workload).
• Gating decision: The sidebar uses PodGroup.isEnabled() (a direct version check, like VPA.isEnabled()) rather than apiDiscovery, because discovery only reports the first version of an API group and scheduling.k8s.io also serves v1 — so discovery would never see the alpha PodGroup.
• i18n: This touches the translation layer. English keys plus translations for all 16 locales are included; please sanity-check language consistency. Untranslated keys follow the repo convention of empty strings.
• Field visibility: Most PodGroup.spec fields (priority, disruptionMode, topology, resourceClaims) sit behind their own feature gates, so they're rendered only when present (hide when absent) rather than showing empty rows.

Summary by CodeRabbit

• New Features
  • Added alpha Scheduling navigation with Pod Groups and Workloads.
  • Added list and detail views for Pod Groups and scheduling Workloads.
  • Pod details now link to their associated Pod Group.
  • Added scheduling status, policies, templates, workload references, and related metadata.
  • Global Search now includes Pod Groups, Workloads, and Vertical Pod Autoscalers.
• Localization
  • Added scheduling terminology and interface translations across supported languages.
• Tests
  • Expanded coverage for resource behavior and new list views.

[kannon92]

/cc

[illume]

Thanks for these changes.

Can you please have a look at the git commits to see if they meet the contribution guidelines? We use a Linux kernel style of git commits. See the contributing guide for general context, and please see previous git commits with git log for examples.

Commits that need attention

• frontend: Add PodGroup and Workload scheduling support to plugin snapshot — Only one file changed inside frontend/; add a sub-area so it's clear what was touched (e.g. frontend: ComponentName: description).
• frontend: Update GlobalSearch storyshot for Pod Groups page — Only one file changed inside frontend/; add a sub-area so it's clear what was touched (e.g. frontend: ComponentName: description).

Commit guidelines

• Use atomic commits focused on a single change.
• Use the title format <area>: <Description of changes> — description must start with a capital letter.
• Keep the title under 72 characters (soft requirement).
• Explain the intention and why the change is needed.
• Make commit titles meaningful and describe what changed.
• Do not add code that a later commit rewrites; squash or reorder commits instead.
• Do not include Fixes #NN in commit messages.

Good examples:

• frontend: HomeButton: Fix so it navigates to home
• backend: config: Add enable-dynamic-clusters flag

[Copilot]

Pull request overview

Adds first-class UI support for Kubernetes v1.36 workload-aware scheduling (alpha) by introducing built-in resource support for scheduling.k8s.io/v1alpha2 PodGroup and Workload, wiring them into routing, navigation, and the Pod details page.

Changes:

• Introduces new k8s resource classes (PodGroup, scheduling Workload) and registers them in ResourceClasses (incl. plugin snapshot update).
• Adds list/details pages + routes for PodGroups and scheduling Workloads, plus a Pod → PodGroup link in Pod details.
• Adds a gated “Scheduling (alpha)” sidebar section and updates i18n strings across all supported locales (plus updated storyshots/snapshots).

Reviewed changes

Copilot reviewed 51 out of 51 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
frontend/src/plugin/snapshots/pluginLib.snapshot	Updates plugin API snapshot for new exported k8s modules/classes.
frontend/src/lib/router/index.tsx	Adds routes for PodGroups and scheduling Workloads.
frontend/src/lib/k8s/schedulingWorkload.ts	Adds scheduling.k8s.io Workload KubeObject class (custom listRoute).
frontend/src/lib/k8s/podGroup.ts	Adds PodGroup KubeObject class + helpers and feature-gate availability check.
frontend/src/lib/k8s/podGroup.test.ts	Adds unit tests for PodGroup class helpers/getters.
frontend/src/lib/k8s/pod.ts	Extends Pod spec typing with schedulingGroup.podGroupName.
frontend/src/lib/k8s/index.ts	Registers new resource classes and re-exports new modules.
frontend/src/lib/k8s/index.test.ts	Extends ResourceClasses namespace coverage assertions for new resources.
frontend/src/i18n/locales/zh/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/zh/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/zh-tw/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/zh-tw/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ur/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ur/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ta/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ta/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ru/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ru/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/pt/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/pt/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ko/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ko/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ja/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ja/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/it/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/it/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/hi/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/hi/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/he/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/he/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/fr/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/fr/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/es/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/es/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/en/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/en/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/de/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/de/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/bn/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/bn/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/i18n/locales/ar/translation.json	Adds new translation keys used by PodGroup/Workload UIs.
frontend/src/i18n/locales/ar/glossary.json	Adds glossary entries for new sidebar/routes/resources.
frontend/src/components/Sidebar/useSidebarItems.tsx	Adds query-gated “Scheduling (alpha)” sidebar section.
frontend/src/components/schedulingWorkload/List.tsx	Adds scheduling Workload list view.
frontend/src/components/schedulingWorkload/List.test.tsx	Adds unit tests for scheduling Workload list columns/formatting.
frontend/src/components/schedulingWorkload/Details.tsx	Adds scheduling Workload details view + templates table.
frontend/src/components/podGroup/List.tsx	Adds PodGroup list view with scheduling status rendering.
frontend/src/components/podGroup/List.test.tsx	Adds unit tests for PodGroup list column definitions and status rendering.
frontend/src/components/podGroup/Details.tsx	Adds PodGroup details view with links and extra fields.
frontend/src/components/pod/Details.tsx	Adds Pod → PodGroup row linking to the PodGroup details page.
frontend/src/components/globalSearch/snapshots/GlobalSearchContent.FoundSomeResults.stories.storyshot	Updates storyshot snapshot due to new navigation/search results.

[kannon92]

/wg workload-aware-scheduling

[Anjali-Chauhan1]

@illume and @kannon92, I have addressed all the review comments and copilot comments , please have a another look whenever you get a chance....

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Anjali-Chauhan1
Once this PR has been reviewed and has the lgtm label, please assign yolossn for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kannon92]

AI-assisted review finding (disclosed): This review comment was identified with assistance from an AI coding agent and verified against the Kubernetes scheduling.k8s.io API types.

High — v1alpha3 PodGroup workload references are not parsed

The PR negotiates between scheduling.k8s.io/v1alpha3 and v1alpha2 in frontend/src/lib/k8s/podGroup.ts, but the model and details view only support the v1alpha2 shape:

• v1alpha2: spec.podGroupTemplateRef.workload.workloadName and podGroupTemplateName
• v1alpha3: spec.workloadRef.workloadName and templateName

Because PodGroup.workloadName only reads podGroupTemplateRef, on v1alpha3 clusters the Workload link and Pod Group Template Name will be missing from the list/details views. The current tests also only cover the v1alpha2 shape.

Please normalize both API shapes (for example with workloadName and podGroupTemplateName getters) and add regression tests for v1alpha3 as well as v1alpha2. The details view should consume those normalized getters.

[Copilot]

Pull request overview

Copilot reviewed 52 out of 52 changed files in this pull request and generated 2 comments.

[illume]

Thanks for working on this.

Would you mind addressing the open Copilot review comments? Please mark each comment as resolved after addressing it.

[Anjali-Chauhan1]

AI-assisted review finding (disclosed): This review comment was identified with assistance from an AI coding agent and verified against the Kubernetes scheduling.k8s.io API types.

High — v1alpha3 PodGroup workload references are not parsed

The PR negotiates between scheduling.k8s.io/v1alpha3 and v1alpha2 in frontend/src/lib/k8s/podGroup.ts, but the model and details view only support the v1alpha2 shape:

• v1alpha2: spec.podGroupTemplateRef.workload.workloadName and podGroupTemplateName
• v1alpha3: spec.workloadRef.workloadName and templateName

Because PodGroup.workloadName only reads podGroupTemplateRef, on v1alpha3 clusters the Workload link and Pod Group Template Name will be missing from the list/details views. The current tests also only cover the v1alpha2 shape.

Please normalize both API shapes (for example with workloadName and podGroupTemplateName getters) and add regression tests for v1alpha3 as well as v1alpha2. The details view should consume those normalized getters.

Thanks @kannon92 . I'd only handled the v1alpha2 shape, so on 1.37 the Workload link and template name wouldn't show up.
I checked both API versions first: v1alpha3 uses spec.workloadRef, while v1alpha2 (release-1.36) uses spec.podGroupTemplateRef.workload. v1alpha2 isn't on master anymore either, which matches what you saw. I updated workloadName to support both shapes, added a podGroupTemplateName getter, and switched the details view to use those getters instead of reading spec directly. The list already used workloadName, so it works there too. Also added tests covering both shapes, plus cases where both are present (v1alpha3 wins) and where neither is present.

[Copilot]

Pull request overview

Copilot reviewed 71 out of 71 changed files in this pull request and generated 1 comment.

Suppressed comments (4)

frontend/src/lib/k8s/index.ts:118

• Registering Workload by kind makes Advanced Search misroute other APIs with the same kind. useKubeLists currently selects ResourceClasses[it.kind] without checking it.apiVersion, so selecting a Kueue kueue.x-k8s.io/... Workload now queries scheduling.k8s.io/.../workloads instead. Update that lookup to require an API-version/group match before using the built-in class, otherwise use the discovered dynamic class.
  frontend/src/lib/k8s/podGroup.ts:97
• The PR notes state that feature-gated resourceClaims are rendered when present, but the PodGroup details view never reads this field. Users with DRAWorkloadResourceClaims enabled therefore cannot inspect any claim name or referenced ResourceClaim/ResourceClaimTemplate. Add a conditional details section or table for these claims (and corresponding tests/translations), or correct the stated scope.
  frontend/src/lib/k8s/schedulingWorkload.ts:83
• The PR history contains a sequence of corrective commits over the same scheduling implementation (API negotiation, required cluster parameter, v1alpha2/v1alpha3 shape fixes, status handling, then v1beta1 support). Please squash/reorder these follow-ups into coherent commits so reviewers can evaluate the final version-support change without reconstructing intermediate regressions.
  frontend/src/lib/k8s/index.ts:88
• This kind-only registration also captures third-party PodGroup resources in Advanced Search. For example, Volcano serves scheduling.volcano.sh/v1beta1 with kind PodGroup, but useKubeLists will now instantiate this class and query scheduling.k8s.io instead of the discovered API. Match both kind and API version/group before choosing a built-in class.

[Copilot]

Pull request overview

Copilot reviewed 71 out of 71 changed files in this pull request and generated 1 comment.

Suppressed comments (2)

frontend/src/components/Sidebar/useSidebarItems.tsx:87

• This acceptance-critical sidebar gate is not covered by useSidebarItems.test.tsx: the existing tests never mock PodGroup.isEnabled() or verify that the Scheduling section is shown for a supporting selected cluster and hidden otherwise. Please add both cases (and preferably the multi-cluster some(Boolean) case) so regressions in this asynchronous gate do not silently remove or expose the navigation.

  const { data: schedulingWorkloadsEnabled = false } = useQuery({
    queryKey: ['schedulingWorkloadsEnabled', ...selectedClusters],
    queryFn: async () => {
      const enabledPerCluster = await Promise.all(
        selectedClusters.map(cluster => PodGroup.isEnabled(cluster))

frontend/src/lib/k8s/podGroup.ts:159

• The PR history has multiple corrective commits that substantially revise this same version-negotiation work (Negotiate..., Fix v1alpha2/v1alpha3..., Support v1beta1..., and Normalize... plus its comment-only follow-up). Please squash/reorder these into coherent feature and test commits so the final API-version design can be reviewed without following intermediate broken states.

[kannon92]

It would be cool to present this integration in wg-was meeting in the future. (I felt like I said this somewhere).

[Anjali-Chauhan1]

It would be cool to present this integration in wg-was meeting in the future. (I felt like I said this somewhere).

Yes, I'd like that. Once this merges, I'll put together a short demo of the pod group and workload views.

[Copilot]

Pull request overview

Copilot reviewed 71 out of 71 changed files in this pull request and generated no new comments.

Suppressed comments (3)

frontend/src/components/Sidebar/useSidebarItems.tsx:87

• This query implements the PR's required sidebar gating, but useSidebarItems.test.tsx has no coverage for it. Add tests that mock PodGroup.isEnabled() and verify the section appears when any selected cluster serves the API and remains absent when none do; otherwise a regression could expose dead navigation on unsupported clusters.

  const { data: schedulingWorkloadsEnabled = false } = useQuery({
    queryKey: ['schedulingWorkloadsEnabled', ...selectedClusters],
    queryFn: async () => {
      const enabledPerCluster = await Promise.all(
        selectedClusters.map(cluster => PodGroup.isEnabled(cluster))

frontend/src/lib/k8s/podGroup.ts:103

• The PR notes say resourceClaims is rendered when present, but the PodGroup details view never reads this field, so users cannot see either direct claims or claim templates. Please add a conditional details row/section for these entries, or update the PR description if displaying them is intentionally out of scope.
  frontend/src/lib/k8s/podGroup.ts:160
• The PR history contains multiple corrective follow-ups that substantially revise the initial implementation (API-version negotiation, cross-version field/condition handling, and template model fixes). Please squash or reorder these into coherent logical commits so reviewers do not need to reconstruct the final behavior across corrective commits.