feat(helm): add standard Kubernetes labels to deployments and services by keyuchen21 · Pull Request #810 · vllm-project/production-stack

keyuchen21 · 2026-01-30T20:02:33Z

Summary

Add app.kubernetes.io/* labels to enable proper recognition by Kubernetes tools like Lens
Labels added to engine deployments, services, and scaled objects
Labels added to router deployment and service

Changes

Added chart.engineStandardLabels and chart.routerStandardLabels helpers in _helpers.tpl
Applied standard labels to all relevant resources in:
- deployment-vllm-multi.yaml
- deployment-router.yaml
- service-vllm.yaml
- service-router.yaml
- scaledobject-vllm.yaml

Test plan

helm template renders all resources correctly
helm lint passes with no errors
Existing custom labels preserved (model, helm-release-name)

Closes #671

gemini-code-assist · 2026-01-30T20:02:52Z

Summary of Changes

Hello @keyuchen21, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the discoverability and integration of Kubernetes resources managed by the Helm chart for the VLLM production stack. By introducing and applying standard app.kubernetes.io/* labels to deployments, services, and scaled objects, it improves compatibility with Kubernetes ecosystem tools, such as Lens, allowing for better visualization and management of the deployed components. This change centralizes label definitions through new Helm helpers and ensures existing custom labels remain intact.

Highlights

Standard Kubernetes Labels: Added standard Kubernetes app.kubernetes.io/* labels to various resources within the Helm charts to improve discoverability and integration with Kubernetes tools.
New Helm Helpers: Introduced two new Helm helpers, chart.engineStandardLabels and chart.routerStandardLabels, in _helpers.tpl to centralize the definition and application of these standard labels.
Resource Application: Applied the newly defined standard labels to engine deployments, services, and scaled objects, as well as router deployments and services.
Label Preservation: Ensured that existing custom labels (e.g., model, helm-release-name) are preserved and coexist with the new standard labels.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

Add app.kubernetes.io/* labels to enable proper recognition by Kubernetes tools like Lens. Labels added to: - Engine deployments, services, and scaled objects - Router deployment and service Closes vllm-project#671 Signed-off-by: Keyu_Chen <54015474+km5ar@users.noreply.github.com>

gemini-code-assist

Code Review

This pull request introduces standard Kubernetes labels to deployments and services, which is a great enhancement for better integration with Kubernetes tooling like Lens. The implementation is clean, using Helm helper templates to define and apply the labels consistently.

I've found one critical issue in the service selector for vLLM engines that would prevent traffic from reaching the pods. I've also provided a suggestion to improve the reusability of the chart by avoiding a hardcoded value in the new label definitions. Once the critical issue is addressed, this will be a valuable addition to the chart.

gemini-code-assist · 2026-01-30T20:04:39Z

helm/templates/service-vllm.yaml

  selector:
    model: "{{ $modelSpec.name }}"
    helm-release-name: "{{ $.Release.Name }}"
+  {{- include "chart.engineStandardLabels" (dict "releaseName" $.Release.Name "modelName" $modelSpec.name) | nindent 4 }}


The service selector is missing the labels from chart.engineLabels. The corresponding pods in deployment-vllm-multi.yaml include these labels (from servingEngineSpec.labels in values.yaml). Without them in the selector, this service will not select any pods, breaking traffic routing to the vLLM engines. The deployment-vllm-multi.yaml's own selector correctly includes these labels, and the service selector should match it.

{{- include "chart.engineLabels" $ | nindent 4 }} {{- include "chart.engineStandardLabels" (dict "releaseName" $.Release.Name "modelName" $modelSpec.name) | nindent 4 }}

gemini-code-assist · 2026-01-30T20:04:40Z

helm/templates/_helpers.tpl

+app.kubernetes.io/name: {{ .modelName }}
+app.kubernetes.io/instance: {{ .releaseName }}
+app.kubernetes.io/component: serving-engine
+app.kubernetes.io/part-of: vllm-production-stack


The app.kubernetes.io/part-of label is hardcoded to vllm-production-stack. For better reusability and to follow Helm best practices, it's recommended to derive this from the chart's metadata, for example, using {{ .Chart.Name }}. This would make the chart more self-contained and easier to use in different contexts.

To implement this, you would need to pass the chart name to this helper from all its call sites, e.g., (dict "chartName" .Chart.Name ...).

app.kubernetes.io/part-of: {{ .chartName }}

gemini-code-assist · 2026-01-30T20:04:40Z

helm/templates/_helpers.tpl

+app.kubernetes.io/name: router
+app.kubernetes.io/instance: {{ .releaseName }}
+app.kubernetes.io/component: router
+app.kubernetes.io/part-of: vllm-production-stack


Similar to the engineStandardLabels, the app.kubernetes.io/part-of label is hardcoded here. It should be made dynamic, for instance by using {{ .Chart.Name }} for better chart reusability. This would require passing the chart name to this helper from all its call sites.

app.kubernetes.io/part-of: {{ .chartName }}

- Add missing chart.engineLabels to service-vllm.yaml selector (critical fix) - Make app.kubernetes.io/part-of dynamic using .Chart.Name instead of hardcoded value for better reusability Signed-off-by: Keyu_Chen <54015474+km5ar@users.noreply.github.com>

ruizhang0101

LGTM :)

ruizhang0101

Hi Can you

ruizhang0101 · 2026-02-07T00:58:12Z

helm/templates/deployment-router.yaml

  namespace: {{ .Release.Namespace }}
  labels:
  {{- include "chart.routerLabels" . | nindent 4 }}
+  {{- include "chart.routerStandardLabels" (dict "releaseName" .Release.Name "chartName" .Chart.Name) | nindent 4 }}


Hi, Can you put the standard labels ahead of custom labels so that the custom labels can override the standard label if they have the same keys? same with other places defining standard labels

Good point!!!!, just updated it.

…r labels Place standard Kubernetes labels ahead of custom labels so that custom labels can override standard labels when they share the same keys. Also add standard labels to cache server deployment and service for consistency. Signed-off-by: Keyu Chen <54015474+keyuchen21@users.noreply.github.com>

keyuchen21 force-pushed the feat/standard-k8s-labels branch from ff46a5a to 7dca228 Compare January 30, 2026 20:04

gemini-code-assist bot reviewed Jan 30, 2026

View reviewed changes

keyuchen21 and others added 2 commits January 30, 2026 15:12

Merge branch 'main' into feat/standard-k8s-labels

0b6f594

ruizhang0101 approved these changes Feb 3, 2026

View reviewed changes

ruizhang0101 and others added 4 commits February 3, 2026 13:59

Merge branch 'main' into feat/standard-k8s-labels

4dbfe85

Merge branch 'main' into feat/standard-k8s-labels

ec8c56f

Merge branch 'main' into feat/standard-k8s-labels

7fc1216

Merge branch 'main' into feat/standard-k8s-labels

ddafc33

ruizhang0101 requested changes Feb 7, 2026

View reviewed changes

keyuchen21 force-pushed the feat/standard-k8s-labels branch from 1e6fd5c to fa0d980 Compare February 7, 2026 15:54

keyuchen21 requested a review from ruizhang0101 February 7, 2026 17:02

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(helm): add standard Kubernetes labels to deployments and services#810

feat(helm): add standard Kubernetes labels to deployments and services#810
keyuchen21 wants to merge 8 commits intovllm-project:mainfrom
keyuchen21:feat/standard-k8s-labels

keyuchen21 commented Jan 30, 2026

Uh oh!

gemini-code-assist bot commented Jan 30, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Jan 30, 2026

Uh oh!

gemini-code-assist bot Jan 30, 2026

Uh oh!

gemini-code-assist bot Jan 30, 2026

Uh oh!

ruizhang0101 left a comment

Uh oh!

ruizhang0101 left a comment

Uh oh!

ruizhang0101 Feb 7, 2026

Uh oh!

keyuchen21 Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

keyuchen21 commented Jan 30, 2026

Summary

Changes

Test plan

Uh oh!

gemini-code-assist bot commented Jan 30, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

ruizhang0101 left a comment

Choose a reason for hiding this comment

Uh oh!

ruizhang0101 left a comment

Choose a reason for hiding this comment

Uh oh!

ruizhang0101 Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

keyuchen21 Feb 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants