Document PVLabeler as deprecated

[stephenfin]

What type of PR is this?

/kind documentation
/sig cloud-provider

What this PR does / why we need it:

This has no callers outside of the deprecated PersistentVolumeLabel admission controller, and it does not appear to be intended for implementation by external cloud provider implementations. The CSI topology feature, while not an exact equivalent, fulfils a very similar role. Indicate this.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

I'm unsure if this is correct approach. An alternative approach would be to start supporting this again in external cloud provider. While the CSI topology feature does allow us to restrict PVs to one or more "zones", there's no way to identify the exact zone that it ended up in. For example, the using cloud-provider-openstack with the Cinder CSI driver, we can define allowedTopologies on our StorageClass(es):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: topology-aware-standard
provisioner: cinder.csi.openstack.org
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.cinder.csi.openstack.org/zone
    values:
    - abc
    - xyz
    - mno

This results in nodeAffinity in our PersistentVolume.spec:

kind: PersistentVolume
# ...
spec:
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.cinder.csi.openstack.org/zone
          operator: In
          values:
          - abc
      - matchExpressions:
        - key: topology.cinder.csi.openstack.org/zone
          operator: In
          values:
          - xyz
      - matchExpressions:
        - key: topology.cinder.csi.openstack.org/zone
          operator: In
          values:
          - mno
  persistentVolumeReclaimPolicy: Delete
  storageClassName: topology-aware-standard

With this we can know it landed in one of three zones but we don't know which one. Previously, we've had seen the exact zone it ended up in. We can fetch this information directly from the cloud in question but I wonder if there's value in still having topology.kubernetes.io/zone and topology.kubernetes.io/region labels on PVs?

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

[k8s-ci-robot]

Hi @stephenfin. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mdbooth]

/ok-to-test

[mdbooth]

/triage accepted

[mdbooth]

I'd add an LGTM label, but I'm not familiar with k/k's deprecation process. However, it certainly looks good to me in principal.

[mdbooth]

This has been lingering a bit. I wonder if we could get some eyes on it, perhaps from @andrewsykim or @cheftako?

[dims]

/approve
/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 880cf8773d549bf3f4e8045ebb9920090961e208

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, stephenfin

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/cloud-provider/OWNERS [dims]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment