The Helm charts hardcode pod-template labels (only app.name) and expose no way to add custom labels to the pod template. services.<svc>.labels is applied to the workload object's metadata (via plane.labelsAndAnnotations), not to spec.template.metadata.labels, and there is no global podLabels / commonLabels value. Please add a configurable pod-label hook.
Current behavior
In every workload template the pod labels are fixed. e.g. templates/workloads/redis.stateful.yaml:
spec:
template:
metadata:
labels:
app.name: {{ .Release.Namespace }}-{{ .Release.Name }}-redis # only this
spec:
{{- include "plane.podScheduling" .Values.services.redis }} # nodeSelector/tolerations/affinity only
plane.podScheduling adds only nodeSelector/tolerations/affinity. plane.labelsAndAnnotations .Values.services.<svc> lands on the
StatefulSet/Deployment metadata, not the pod template. So there is no supported way to add a label that ends up on the pods.
Why it matters (real-world)
On Cilium-based clusters (e.g. CloudFleet CFKE), a pod's security identity is derived from its pod labels. We hit a documented Cilium edge case where ~1 in 256 identities collides with a bad node-to-node underlay interaction and black-holes the return path of cross-node connections (the SYN is delivered and allowed, the SYN-ACK never returns; same-node traffic is fine, no policy drop is logged). Our plane-redis pod drew a colliding identity, which broke every cross-node consumer (api, worker, live, silo).
The vendor's prescribed fix is to add any extra pod-template label so the pod draws a fresh, non-colliding identity. That is impossible to do durably through the chart today — we can only kubectl patch the StatefulSet by hand, which is undone/at-risk on the next helm upgrade.
Beyond this specific case, configurable pod labels are routinely needed for:
- NetworkPolicy/Cilium policy targeting, pod (anti-)affinity and topology spread,
- service-mesh sidecar injection toggles, cost-allocation/ownership labels, and
- log/metric pipeline selectors.
Proposed change
Add an optional per-service podLabels (map) merged into spec.template.metadata.labels for every workload, ideally plus a global commonLabels / podAnnotations. Example:
# global, applied to all pod templates
commonLabels:
team: platform
services:
redis:
local_setup: true
podLabels:
example.com/identity-salt: "v1" # our use case
Rendered:
spec:
template:
metadata:
labels:
app.name: {{ .Release.Namespace }}-{{ .Release.Name }}-redis
{{- with .Values.commonLabels }}{{ toYaml . | nindent 8 }}{{- end }}
{{- with .Values.services.redis.podLabels }}{{ toYaml . | nindent 8 }}{{- end }}
(Must not override the chart's app.name selector label.)
Environment
- Chart:
plane-enterprise 2.6.0 (also current 2.6.1), appVersion v2.6.2/v2.6.3
- Deployment: Kubernetes (Helm), CNI: Cilium
Workaround (today)
kubectl -n <ns> patch statefulset plane-redis-wl --type=merge \
-p '{"spec":{"template":{"metadata":{"labels":{"example.com/identity-salt":"v1"}}}}}'
Survives until a helm upgrade re-renders the workload; needs re-applying after chart upgrades — hence the request to make it a first-class chart value.
The Helm charts hardcode pod-template labels (only
app.name) and expose no way to add custom labels to the pod template.services.<svc>.labelsis applied to the workload object's metadata (viaplane.labelsAndAnnotations), not tospec.template.metadata.labels, and there is no globalpodLabels/commonLabelsvalue. Please add a configurable pod-label hook.Current behavior
In every workload template the pod labels are fixed. e.g.
templates/workloads/redis.stateful.yaml:plane.podSchedulingadds onlynodeSelector/tolerations/affinity.plane.labelsAndAnnotations .Values.services.<svc>lands on theStatefulSet/Deployment metadata, not the pod template. So there is no supported way to add a label that ends up on the pods.
Why it matters (real-world)
On Cilium-based clusters (e.g. CloudFleet CFKE), a pod's security identity is derived from its pod labels. We hit a documented Cilium edge case where ~1 in 256 identities collides with a bad node-to-node underlay interaction and black-holes the return path of cross-node connections (the SYN is delivered and allowed, the SYN-ACK never returns; same-node traffic is fine, no policy drop is logged). Our
plane-redispod drew a colliding identity, which broke every cross-node consumer (api,worker,live,silo).The vendor's prescribed fix is to add any extra pod-template label so the pod draws a fresh, non-colliding identity. That is impossible to do durably through the chart today — we can only
kubectl patchthe StatefulSet by hand, which is undone/at-risk on the nexthelm upgrade.Beyond this specific case, configurable pod labels are routinely needed for:
Proposed change
Add an optional per-service
podLabels(map) merged intospec.template.metadata.labelsfor every workload, ideally plus a globalcommonLabels/podAnnotations. Example:Rendered:
(Must not override the chart's
app.nameselector label.)Environment
plane-enterprise2.6.0 (also current 2.6.1), appVersion v2.6.2/v2.6.3Workaround (today)
Survives until a
helm upgradere-renders the workload; needs re-applying after chart upgrades — hence the request to make it a first-class chart value.