Skip to content

configurable pod-template labels (podLabels) per workload #250

Description

@dfrkp

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions