feat(labels): add gateway.selectorLabels with component label

[camjay]

⚠️ Upgrade note: This changes the gateway Service selector. See "Upgrade impact" below before merging.

Adds a gateway.selectorLabels helper with app.kubernetes.io/component: gateway, matching the existing dataservice.selectorLabels pattern. Applied to pod labels and Service selectors (both mutable).

Deployment matchLabels left unchanged to avoid requiring Deployment recreation. Users who want the component label in matchLabels can opt in via .Values.selectorLabels.

Upgrade impact

The gateway Service selector gains app.kubernetes.io/component: gateway. Old pods (from the previous chart version) don't have this label in their metadata. During a rolling update:

1. New Service selector requires component: gateway
2. Old pods lack this label → Service stops routing to them
3. New pods aren't ready yet → brief traffic interruption

Mitigations:

• Set strategy.rollingUpdate.maxSurge: 100% so new pods start before old ones terminate
• Or do a blue-green deploy: scale up new pods, verify health, then scale down old

Subsequent upgrades are unaffected — all pods will have the label.

This trade-off mirrors what already happened with dataservice.selectorLabels, which includes app.kubernetes.io/component in both Service selectors and Deployment matchLabels. The gateway version is intentionally less disruptive (Service only, not matchLabels).

See also #173 which adds CI to validate chart templates on PRs.

[Copilot]

Pull request overview

This PR updates the portkey-gateway Helm chart labeling helpers so the gateway Service selector (and gateway pod labels) include app.kubernetes.io/component: gateway, aligning with the existing dataservice selector-label pattern while avoiding changes to the Deployment’s immutable matchLabels.

Changes:

• Add a new gateway.selectorLabels helper that composes portkeyenterprise.selectorLabels and a fixed app.kubernetes.io/component: gateway label.
• Update gateway Services to use gateway.selectorLabels instead of portkeyenterprise.selectorLabels.
• Update gateway.labels to include gateway.selectorLabels so gateway pods receive the new component label.

Reviewed changes

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

File	Description
charts/portkey-gateway/templates/gateway/service.yaml	Switch Service selectors (including MCP Service) to gateway.selectorLabels so Services select gateway pods via the component label.
charts/portkey-gateway/templates/_helpers.tpl	Introduce gateway.selectorLabels and wire it into gateway.labels so pod labels match the updated Service selectors.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sk-portkey]

@camjay

Thanks for the PR and the thorough write-up on upgrade impact — it's clear you've thought this through carefully.

That said, I'm going to hold off on merging this as-is. The core concern is that this changes the Service selector for all existing installs, which means every upgrade hits a traffic interruption regardless of whether the user needs the tighter selector. The mitigations (maxSurge, blue-green) put the burden on operators to work around a change they didn't ask for.

The existing .Values.selectorLabels hook already lets users add app.kubernetes.io/component: gateway today if they need selector precision — no chart change required.

If there's appetite for a more ergonomic path, I'd be open to a PR that adds a gateway.deployment.selectorLabels values key (mirroring what dataservice does), but defaulting to empty so existing installs are unaffected. That way users can opt in when they're ready rather than having it forced on upgrade.

Appreciate the contribution — happy to discuss if you see a use case that .Values.selectorLabels doesn't cover.