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

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions