Merge pull request #46304 from carlory/remove-rbd

update rbd volume

Author: k8s-ci-robot

content/en/docs/concepts/storage/persistent-volumes.md

@@ -529,8 +529,6 @@ please install corresponding CSI drivers.
   (**migration on by default** starting v1.23)
 * [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume
   (**deprecated** starting v1.25)
-* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
-  (**deprecated** starting v1.28, no migration plan, support will be removed in a future release)
 * [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
   (**migration on by default** starting v1.25)
 
@@ -546,6 +544,8 @@ Older versions of Kubernetes also supported the following in-tree PersistentVolu
   (**not available** starting v1.25)
 * `storageos` - StorageOS volume.
   (**not available** starting v1.25)
+* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume 
+  (**not available** starting v1.31)
 
 ## Persistent Volumes
 

content/en/docs/concepts/storage/volumes.md

@@ -745,66 +745,16 @@ To enable the feature, set `CSIMigrationPortworx=true` in kube-controller-manage
 A projected volume maps several existing volume sources into the same
 directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/).
 
-### rbd
-{{< feature-state for_k8s_version="v1.28" state="deprecated" >}}
-
-{{< note >}}
-The Kubernetes project suggests that you use the [Ceph CSI](https://github.com/ceph/ceph-csi)
-third party storage driver instead, in RBD mode.
-{{< /note >}}
-
-An `rbd` volume allows a
-[Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) volume to mount
-into your Pod. Unlike `emptyDir`, which is erased when a pod is removed, the
-contents of an `rbd` volume are preserved and the volume is unmounted. This
-means that a RBD volume can be pre-populated with data, and that data can be
-shared between pods.
+### rbd (removed) {#rbd}
 
-{{< note >}}
-You must have a Ceph installation running before you can use RBD.
-{{< /note >}}
-
-A feature of RBD is that it can be mounted as read-only by multiple consumers
-simultaneously. This means that you can pre-populate a volume with your dataset
-and then serve it in parallel from as many pods as you need. Unfortunately,
-RBD volumes can only be mounted by a single consumer in read-write mode.
-Simultaneous writers are not allowed.
-
-See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd)
-for more details.
-
-#### RBD CSI migration {#rbd-csi-migration}
-
-{{< feature-state for_k8s_version="v1.28" state="deprecated" >}}
+<!-- maintenance note: OK to remove all mention of rbd once the v1.30 release of
+Kubernetes has gone out of support -->
 
-The `CSIMigration` feature for `RBD`, when enabled, redirects all plugin
-operations from the existing in-tree plugin to the `rbd.csi.ceph.com` {{<
-glossary_tooltip text="CSI" term_id="csi" >}} driver. In order to use this
-feature, the
-[Ceph CSI driver](https://github.com/ceph/ceph-csi)
-must be installed on the cluster and the `CSIMigrationRBD`
-[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-must be enabled. (Note that the `csiMigrationRBD` flag has been removed and
-replaced with `CSIMigrationRBD` in release v1.24)
+Kubernetes {{< skew currentVersion >}} does not include a `rbd` volume type.
 
-{{< note >}}
+The [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) in-tree storage driver and its csi migration support were deprecated in the Kubernetes v1.28 release
+and then removed entirely in the v1.31 release.
 
-As a Kubernetes cluster operator that administers storage, here are the
-prerequisites that you must complete before you attempt migration to the
-RBD CSI driver:
-
-* You must install the Ceph CSI driver (`rbd.csi.ceph.com`), v3.5.0 or above,
-  into your Kubernetes cluster.
-* considering the `clusterID` field is a required parameter for CSI driver for
-  its operations, but in-tree StorageClass has `monitors` field as a required
-  parameter, a Kubernetes storage admin has to create a clusterID based on the
-  monitors hash ( ex:`#echo -n
-  '<monitors_string>' | md5sum`) in the CSI config map and keep the monitors
-  under this clusterID configuration.
-* Also, if the value of `adminId` in the in-tree Storageclass is different from
- `admin`, the `adminSecretName` mentioned in the in-tree Storageclass has to be
-  patched with the base64 value of the `adminId` parameter value, otherwise this
-  step can be skipped. {{< /note >}}
 
 ### secret