Is your feature request related to a problem? Please describe.
Pixie already exposes Kubernetes pod labels as metadata (via px.pod_id_to_pod_labels), which is useful for grouping and filtering telemetry. However, a lot of operationally important information lives in pod annotations rather than labels, for example team/ownership tags, GitOps/CI metadata, config checksums, and information injected by deployment tooling. Today there is no way to surface pod annotations in Pixie data, so users can't slice or enrich telemetry by that metadata.
Unlike labels, annotations are frequently large and noisy (e.g. kubectl.kubernetes.io/last-applied-configuration can hold an entire object spec). Capturing every annotation on every pod would be expensive and would bloat the metadata stream, so annotations need to be captured selectively rather than wholesale.
Describe the solution you'd like
Provide pod annotations (as a JSON string) alongside the existing pod metadata, analogous to how pod labels are provided today:
- Add an
annotations field to the pod metadata / PodUpdate proto.
- Capture annotations in the metadata service's pod update processor and store them in the metadata state.
- Expose them to PxL via a new UDF, e.g.
px.pod_id_to_pod_annotations(df.pod_id).
- Because annotations can be large/noisy, gate collection behind an allowlist of annotation keys. Only keys in the allowlist are captured; an empty/unset allowlist captures nothing (safe default). Configure this via a
pod_annotation_allowlist flag / PL_POD_ANNOTATION_ALLOWLIST env var so operators opt into exactly the keys they care about.
Describe alternatives you've considered
- Capturing all annotations unconditionally (like labels): REJECTED, because annotations commonly contain large blobs, which would significantly increase metadata volume and noise.
- Overloading pod labels: not viable, since labels and annotations are distinct Kubernetes concepts and the useful data often only exists as annotations.
Additional context
- This closely follows the existing pod-labels design. For reference on how pod labels were added to Pixie's metadata, see the PR "Add capability to get pod labels" (#468).
- A description of how to add to Pixie's metadata can be found in the discussion on "Provide pod labels with metadata" (#449).
Is your feature request related to a problem? Please describe.
Pixie already exposes Kubernetes pod labels as metadata (via
px.pod_id_to_pod_labels), which is useful for grouping and filtering telemetry. However, a lot of operationally important information lives in pod annotations rather than labels, for example team/ownership tags, GitOps/CI metadata, config checksums, and information injected by deployment tooling. Today there is no way to surface pod annotations in Pixie data, so users can't slice or enrich telemetry by that metadata.Unlike labels, annotations are frequently large and noisy (e.g.
kubectl.kubernetes.io/last-applied-configurationcan hold an entire object spec). Capturing every annotation on every pod would be expensive and would bloat the metadata stream, so annotations need to be captured selectively rather than wholesale.Describe the solution you'd like
Provide pod annotations (as a JSON string) alongside the existing pod metadata, analogous to how pod labels are provided today:
annotationsfield to the pod metadata /PodUpdateproto.px.pod_id_to_pod_annotations(df.pod_id).pod_annotation_allowlistflag /PL_POD_ANNOTATION_ALLOWLISTenv var so operators opt into exactly the keys they care about.Describe alternatives you've considered
Additional context