labelsfilter: ignore StatefulSet-related labels by default for CID creation

[tosi3k]

Beforehand, every single Pod owned by a StatefulSet object had its own CiliumIdentity because each such Pod had their own unique set of label values (more about these labels can be found here and here).

In large clusters with many StatefulSet-owned Pods it is problematic, especially when the churn of such objects is high, resulting in a high churn of such CIDs that doesn't scale well. In addition, it essentially limited the number of such Pods to the theoretical number of CIDs in a cluster which is 2^16 ~ 65k.

Ignore StatefulSet-specific labels by default for CID creation. This includes the two following labels:
* statefulset.kubernetes.io/pod-name
* apps.kubernetes.io/pod-index

[maintainer-s-little-helper]

Commit 0a9a0bb2a26cb3e2f13e43702fe6bae44be7a541 does not match "(?m)^Signed-off-by:".

Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin

[tosi3k]

@nathanjsweet @lambdanis PTAL

[lambdanis]

Docs ok, overall the change looks reasonable to me.

[lambdanis]

@tosi3k CI is unhappy with the long commit message (https://github.com/cilium/cilium/actions/runs/6187912035/job/16803422512?pr=28003):

{[1/2] labelsfilter: ignore StatefulSet-specific labels by default for CID creation}

Error: ERROR:CUSTOM: Please avoid long commit subjects (max: 75, found: 76)

Could you please reword it?

[tosi3k]

@tosi3k CI is unhappy with the long commit message (https://github.com/cilium/cilium/actions/runs/6187912035/job/16803422512?pr=28003):

{[1/2] labelsfilter: ignore StatefulSet-specific labels by default for CID creation}

Error: ERROR:CUSTOM: Please avoid long commit subjects (max: 75, found: 76)

Could you please reword it?

Done; thanks for pointing this out.

[lambdanis]

/test

[joestringer]

Hi @tosi3k, it looks like this PR introduced upgrade impact for users upgrading to Cilium v1.15 because users may have policies that rely on some of the labels that are now ignored. This issue/comment goes into detail about the issues behind this and some suggestions about how to improve: #32213 (comment) . I'll note that while the release-note/minor labeling for this PR does cause a release note to be generated for users, it is easy to miss; for something that requires direct user attention, we would typically document the change for users under Documentation/operations/upgrade.rst. Or, better than that, if we can encode checks into the preflight daemonset then users may find out and take action before they even upgrade, thereby minimizing the impact.