Ceph CSI drivers for Kubernetes on external Ceph storage

How Ceph-CSI gives Kubernetes persistent volumes from an external Ceph cluster

If your Ceph cluster is run by cephadm or by another team, and your Kubernetes clusters need persistent volumes from it, Ceph-CSI is the supported method, and the Ceph-CSI-Operator is the recommended way to deploy it for new work. Ceph-CSI is the container storage interface plugin set that the Ceph project maintains. It runs inside each Kubernetes cluster and talks to the Ceph cluster over the network using CephX credentials, so the storage cluster stays outside Kubernetes and keeps its own lifecycle. The operator is the path the Ceph documentation now prefers, and the Helm charts and raw manifests it still describes are being phased out, so a new build should not start from them.

Ceph-CSI provides four drivers, and each one answers a different workload need. The RBD driver (rbd.csi.ceph.com) provides block volumes for databases and other single-writer workloads. The CephFS driver (cephfs.csi.ceph.com) provides shared POSIX file systems that several pods can mount. The NFS driver (nfs.csi.ceph.com) exposes CephFS through NFS for clients that cannot use CephFS directly. The NVMe-oF driver (nvmeof.csi.ceph.com) provides block volumes over NVMe over Fabrics. Before you pick drivers, confirm with your Ceph release notes that the driver version you plan to run supports your Ceph release and your Kubernetes minor version, since both move on their own schedules.

The first decision is which drivers you need, because each one adds CephX users, pools or file systems on the Ceph side and its own provisioner and node components on the Kubernetes side. Ask your Ceph administrator which pools and file systems will be dedicated to each cluster, and confirm the driver list against the Ceph-CSI deployment documentation before you write any manifests. Plan the review of deprecated Helm or manifest installs now if you already run them, because moving an existing install to the operator is a migration task of its own.

Choosing between the Ceph-CSI-Operator, Helm and Rook

If you are building a new Kubernetes integration against a Ceph cluster that is managed outside Kubernetes, the Ceph-CSI-Operator is the route the Ceph documentation recommends for new deployments. You install the operator, then describe how Kubernetes reaches your cluster through a ClientProfile, and your StorageClasses refer to that profile by name. This keeps the driver lifecycle in one place and avoids starting on a method the project is moving away from.

Recommended method: The Ceph-CSI deployment docs name the operator as the recommended method for new deployments.
Driver coverage: Confirm which drivers you need (RBD, CephFS, NFS or NVMe-oF) and that your chosen operator release provides them.
ClientProfile naming: The clusterID in each StorageClass must match the ClientProfile name when you use the operator.
CephX users: Plan one CephX user per Kubernetes cluster so access can be scoped and revoked separately.
Upgrade ownership: Decide who tracks Ceph-CSI releases against your Kubernetes minor version.

Before you commit, confirm with your Ceph administrator and the current Ceph-CSI documentation that the operator release you plan to use supports your Ceph release and your Kubernetes version.

If Ceph-CSI is already running from Helm charts or raw manifests, those installs still work, but the Ceph documentation states that both methods are being phased out. Your plan should move the driver to the operator on a schedule you control rather than waiting for the install to break. The migration is mainly about changing how the driver is deployed and how StorageClasses identify the cluster, not about moving data.

Phase-out status: Helm charts and raw manifests are being phased out, so they are a migration item, not a steady state.
Identifier change: Helm and manifest deployments conventionally use the cluster fsid for clusterID, while the operator uses the ClientProfile name, so StorageClasses need review.
Existing volumes: Check that PersistentVolumes already provisioned keep working through the cutover and that reclaim policies are understood.
Test cluster first: Rehearse the change on a non-production cluster with the same StorageClass set.
Rollback path: Write down how you return to the previous install if provisioning fails during the change.

Confirm the exact migration steps and any StorageClass changes against the current Ceph-CSI deployment documentation before scheduling a production window.

What you need before installing Ceph-CSI

Ceph-CSI sits between a Kubernetes cluster and a Ceph cluster that your team operates outside Kubernetes. The items below connect the two sides: the Kubernetes version, the Ceph release, the network path, the CephX identities and the cluster permissions. Confirm each one before you choose a deployment method.

Supported Kubernetes version

Start from the Kubernetes releases page, which lists the minor versions the project still maintains and their end-of-life dates. Then check the Ceph-CSI compatibility matrix for the driver release you plan to deploy, because a driver can lag behind the newest Kubernetes minor version. Ask your Kubernetes distribution vendor which Kubernetes version it supports and whether it changes the CSI node plugin's host requirements. Record the chosen version, since every later upgrade step depends on it.

Healthy Ceph cluster on a supported release

Run the Ceph health check on the external cluster before you create any StorageClass. Choose a supported release line, such as Squid (19.2.x) or Tentacle (20.2.x), and confirm the current point release and its end-of-life date on the Ceph releases page. A cluster in a warning state will surface as provisioning failures that look like CSI bugs. Confirm that the pools you plan to use already exist and that the cluster can place data in them.

Network path to the Ceph monitors

Every worker node that mounts a volume must reach the Ceph monitors and the OSDs that hold the data. Confirm routing and firewall rules from the node network to the monitor addresses, and check the messenger port your monitors listen on. Pod networks are usually separate from the storage network, so test from a node itself, not only from a pod. Ask your network team to confirm MTU and any NAT between the two networks, since both can cause hangs that appear only under load.

One CephX user per Kubernetes cluster

Create a dedicated CephX client for each Kubernetes cluster and each driver type, such as one identity for RBD and another for CephFS. Scope its capabilities to the pools and filesystems that cluster may use, so a compromised node cannot reach other tenants' data. Record the key outside the cluster manifests and plan how it will be rotated. Reusing the admin key is the shortcut to avoid, because it removes any way to limit or audit what Kubernetes can do.

RBAC for the driver components

The CSI controller and node plugins need Kubernetes permissions to create and attach volumes, read Secrets that hold CephX keys, and manage snapshots if you use them. Review the ClusterRole and ServiceAccount objects the chosen deployment method creates, and confirm that cluster-wide Secret access is limited to the namespaces that need it. Ask who approves changes to the driver RBAC, because these permissions reach storage for every workload in the cluster.

Pod Security settings for node plugins

The node plugin mounts host paths and runs privileged so it can map RBD devices and mount CephFS on the host. Check which Pod Security Standards level your target namespace enforces, and confirm that the driver namespace is exempt or set to a level that allows these privileges. Apply the exception to that namespace only, so workloads elsewhere keep the restricted profile. Document the exemption in your security baseline so auditors can see why it exists.

Configuring Ceph-CSI on an external cluster, step by step

This sequence connects one or more Kubernetes clusters to a Ceph cluster that you manage outside Kubernetes, so workloads can request RBD and CephFS volumes through StorageClasses. Each step ends with a check that tells you whether the connection works before you move on.

Create dedicated pools and CephX users
On the Ceph side, a storage administrator creates separate pools for each Kubernetes cluster, one for RBD block volumes and, if needed, a filesystem with its own data and metadata pools for CephFS. Create a CephX user per Kubernetes cluster with capabilities limited to those pools, so one cluster cannot reach another cluster's volumes. Record the monitor addresses, the user key and the cluster fsid. Confirm the pools exist and the cluster reports HEALTH_OK with ceph health before continuing, and keep the key out of shell history and version control.
Confirm the Kubernetes and Ceph versions
Before installing anything, check the Ceph-CSI release that matches your Kubernetes minor version and your Ceph release, using the Ceph-CSI deployment documentation. Kubernetes maintains only its three most recent minor releases, so plan the driver version against a supported Kubernetes line. Confirm that the Kubernetes nodes can reach the Ceph monitor addresses on the messenger ports and that any firewall or network policy allows the traffic. The output is a written version pairing and a successful connection test from a node, such as a monitor reachability check.
Install the Ceph-CSI operator
A Kubernetes administrator installs the Ceph-CSI-Operator, which the Ceph documentation names as the recommended method for new deployments. Helm charts and raw manifests are being phased out, so avoid starting a new installation with them. The operator runs in its own namespace and provides the controllers for the RBD, CephFS, NFS and NVMe-oF drivers. Confirm the operator pod is running and its custom resource definitions are registered with kubectl get pods and kubectl get crds before you create any client configuration.
Create the ClientProfile with the cluster identifier
Create a ClientProfile resource that holds the Ceph monitor addresses and the cluster identifier that StorageClasses will reference. With the operator, the clusterID in a StorageClass must match the ClientProfile name exactly. Store the CephX user key in a Kubernetes Secret with restricted access, and apply least-privilege RBAC so that only the driver components can read it. The check is that the ClientProfile reports a ready status and that the driver can list pools from the Ceph cluster. If you use a Helm or manifest install, the conventional clusterID is the cluster fsid, so note which pattern your deployment follows.
Deploy the RBD and CephFS drivers
Enable the RBD driver for block volumes and the CephFS driver for shared filesystem volumes, each in the namespace and with the node plugin privileges the operator expects. Keep the RBD and CephFS users separate so that a compromise of one storage path does not expose the other. Review the node plugin permissions and the pod security settings against your cluster policy, since the node components need host-level access to map devices and mount filesystems. The check is that the provisioner and node plugin pods are running on every node that will host workloads, with no restart loops in their logs.
Define StorageClasses that reference the clusterID
Create one StorageClass per driver and pool, setting the provisioner to rbd.csi.ceph.com or cephfs.csi.ceph.com, the clusterID to the ClientProfile name, and the pool to the dedicated pool created in the first step. Add the secret references and the reclaim and expansion settings your team has agreed on. Use separate StorageClasses for different performance tiers or failure domains, so developers select storage by intent rather than by pool name. Confirm the StorageClasses exist with kubectl get storageclass and that each one points to the correct clusterID.
Create a test PVC and mount it
Create a test PersistentVolumeClaim against each StorageClass, then start a test pod that mounts the claim and writes a file. Use a throwaway namespace so that the test can be removed cleanly. The claim should move to Bound, and the pod should reach Running with the volume mounted at the expected path. On the Ceph side, confirm that the image or subvolume appeared in the dedicated pool with the rbd or ceph fs tools. Remove the test resources afterward and record the results as the acceptance evidence for this cluster.

Mapping clusterID, ClientProfile, fsid and CephX users

This table maps each identifier that links a Kubernetes StorageClass to an external Ceph cluster, showing where it is set and what it must match. Read it row by row when you build the first StorageClass, because a single mismatched value is a common reason provisioning fails.

Identifier	Where it is set	What it must match
StorageClass clusterID	clusterID parameter in each StorageClass that uses an RBD, CephFS or NFS driver	The ClientProfile name when the Ceph-CSI-Operator is used; the cluster fsid in Helm or manifest deployments
ClientProfile name	Ceph-CSI-Operator resource for each external cluster	The clusterID referenced by StorageClasses; it is the value to copy into the StorageClass
Cluster fsid	Output of the cluster's fsid on a Ceph admin node	The clusterID in Helm or manifest deployments, conventionally; confirm the convention for your Ceph-CSI version
Monitor addresses	Monitor endpoints listed in the cluster configuration the driver reads	The current monitor addresses of the external cluster; stale addresses after host changes cause mount and provisioning errors
CephX user and caps	Client key created on the Ceph cluster for the Kubernetes driver	Capabilities scoped to the pools or filesystem each driver serves; a missing cap typically surfaces as a permission error at provisioning
Target pool or filesystem	pool parameter for RBD classes, fsName for CephFS classes	A pool or filesystem that exists on the cluster identified by the clusterID and is covered by the CephX user caps
Secret references	provisioner and node secret names in StorageClasses	The CephX user and key stored in the referenced Kubernetes Secret for the same cluster
Multiple clusters	One ClientProfile or clusterID per external cluster	A unique identifier per cluster, with separate CephX users so one cluster's credentials do not reach another

Why each Kubernetes cluster should get its own CephX user

Give each Kubernetes cluster, and ideally each tenant inside a shared cluster, its own CephX user, with capabilities limited to the RBD pools, CephFS filesystem and NFS resources that cluster actually provisions. A shared admin key is the common shortcut, and it means one compromised cluster can read, write or delete volumes belonging to every other cluster on the same Ceph system. Separate users also make the audit trail readable: when storage activity looks wrong, you can tie it to one cluster instead of guessing. Before writing caps, list the pools each StorageClass will use, including any separate pool for metadata or for erasure-coded data, and confirm the exact capability syntax for RBD, CephFS and NFS against the current Ceph-CSI deployment documentation. Caps that are too broad are hard to narrow later without an outage.

Plan key rotation as a routine task, not an incident response. Each CephX user has a key that the CSI provisioner and node plugins read from a Kubernetes Secret, so rotating a key means creating or updating that Secret, restarting or rolling the affected CSI pods, and confirming that new volume operations and mounts succeed before the old key is removed. Record which Secret, which CephX user and which clusterID each StorageClass depends on, so a rotation does not silently break provisioning in one cluster. Revoking a user is more disruptive than rotating a key. Existing mapped RBD images and mounted CephFS clients may keep working until the session ends or the client is remounted, so the revocation procedure should include a check of active sessions and a plan for the workloads still using those volumes. Test this on a non-production cluster first, and confirm the revocation behavior for your Ceph release with your storage team.

Hardening the Ceph-CSI integration

A Ceph-CSI integration gives every pod that can claim a volume a path into the storage cluster, so its security depends on a few connected choices. The cards below cover CephX identities, transport encryption, who may point a StorageClass at a cluster, how Secrets are protected, and how the driver namespace is confined.

Least-privilege CephX caps

Create a separate CephX user for each Kubernetes cluster and each pool, and grant only the capabilities the driver needs for that pool. Avoid reusing the admin key in StorageClasses or Secrets. Before go-live, confirm with your Ceph administrator that the user cannot read or write pools belonging to other workloads, and record which user backs which StorageClass so a revocation can be scoped without breaking other clusters.

Separate keys per cluster

Give each Kubernetes cluster, and ideally each environment such as test and production, its own CephX identity and its own copy of the credentials. A shared key means a compromise in a lower-trust cluster exposes production volumes. Plan a rotation procedure that replaces one cluster's key at a time, and confirm that your Ceph team can disable a single identity without affecting the others.

Encryption in transit with msgr2

Ceph's messenger v2 protocol listens on port 3300 and offers a secure mode that encrypts all traffic after authentication with AES-GCM and adds integrity checks. Confirm that the mon addresses used by the driver use the v2 endpoint and that secure mode is enabled on the Ceph side, then verify the negotiated mode from a worker node. Storage traffic between nodes and the cluster should also sit on a segment your network team controls.

Controlling StorageClass creation

A StorageClass that names a clusterID decides which Ceph cluster and pool a workload writes to, so creating one is a privileged action. Restrict create, update and patch rights on StorageClass objects to the platform team through RBAC, and review every class that references an external cluster during change approval. Ask whether your admission tooling can reject classes that point at clusters outside an approved list.

Secrets at rest and in list access

Kubernetes stores Secrets unencrypted in etcd by default, and the CephX key used by the driver is one of them. Configure encryption at rest for the API server, restrict list and watch access to the driver namespace, and consider an external store through the Secrets Store CSI Driver so the key never sits in etcd. Anyone who can list Secrets in that namespace can read the Ceph key, so check this with kubectl auth can-i for each group.

Pod Security Standards for the driver

The Ceph-CSI node plugin runs privileged on each worker because it maps RBD devices and mounts CephFS and NFS volumes. Keep it in a dedicated namespace and apply the Pod Security Standards level that the driver actually needs rather than a blanket exemption for the cluster. Check which pods in that namespace are privileged after each upgrade, and align the result with the CIS Kubernetes Benchmark by title.

Testing volumes before workloads depend on them

Before any production workload claims a volume, run a fixed test sequence against each StorageClass you plan to offer, for both the RBD and CephFS drivers. Start with provisioning: create a PersistentVolumeClaim against each StorageClass, confirm it binds and that the backing image or subvolume appears in the expected pool or filesystem on the Ceph side, then delete the claim and confirm the volume is removed as the reclaim policy says it should be. Repeat the cycle a few times, because provisioner and deleter faults often appear only after the first cycle. Record the clusterID and pool or filesystem name used by each StorageClass, so a later mismatch between the ClientProfile name and the cluster fsid can be traced quickly.

Next test the attach and failure paths that production will exercise. Mount a volume in a pod, write a known data pattern, delete the pod, and reattach the volume to a pod on a different node to confirm the data survives and the old attachment releases cleanly. Then restart a worker node that hosts a mounted volume and confirm the pod reschedules and the volume mounts again without manual cleanup of stale attachments. In a non-production environment, stop one Ceph monitor on purpose and watch whether existing mounts keep working, whether new provisioning requests succeed or stall, and how quickly the cluster recovers when the monitor returns. Keep the monitor test in a lab that mirrors your quorum layout, since the outcome depends on how many monitors you run.

Finish with a volume expansion check, but only where the release supports it. Confirm in the Ceph-CSI documentation for your exact driver version whether the StorageClass allows volume expansion and whether the RBD and CephFS drivers support online resize for your filesystem type. Expand a test PVC, confirm the new size reaches the pod, and verify the filesystem reports the larger capacity. Do not assume parity between drivers, and do not assume that the Kubernetes version in use will behave the same as the one in the lab. Write the results into your acceptance record with the driver, Ceph, and Kubernetes versions tested, so the test can be repeated at each upgrade.

Common Ceph-CSI failures and their causes

This table pairs each common Ceph-CSI failure with its usual cause and the fix to try first. Read it from the symptom column when a PVC or pod is stuck, then check the cause against your cluster before changing configuration. Most failures trace back to identifiers, credentials or network paths that were set up once and drifted.

Symptom	Likely cause	Fix
PVC stays Pending	The StorageClass clusterID does not match the ClientProfile name when using the Ceph-CSI-Operator	Compare the StorageClass clusterID with the ClientProfile name and correct whichever value is wrong, then recreate the claim if needed
PVC stays Pending with a Helm or manifest install	The clusterID does not match the cluster fsid that the chart or manifests were configured with	Confirm the cluster fsid on the Ceph side and set the clusterID in the StorageClass and CSI config to that value
Authentication errors in provisioner logs	The CephX key in the Kubernetes secret is wrong, or the user lacks the caps needed for the pool or filesystem	Recreate the CephX user with caps scoped to the target pool or filesystem and update the secret to match the new key
Volume creation works but mounting fails	Worker nodes cannot reach the monitor addresses on the Ceph public network	Verify routing and firewall rules from every worker to the monitor ports, and confirm the monitor addresses in the CSI config are current
Node plugin pods crash or mounts hang	Required kernel modules or client packages, such as the RBD module or CephFS client tools, are missing on the worker nodes	Install the matching client packages and load the required kernel modules on each node, then confirm they persist across reboots
Driver fights with Rook-managed resources	A Ceph-CSI Helm chart or manual manifests were deployed into a cluster where Rook already manages Ceph-CSI	Remove the hand-deployed CSI resources and let Rook manage the driver, since the Ceph docs advise against manual deployment in Rook clusters
Pods fail after a Kubernetes upgrade	The CSI driver version is outside the supported range for the new Kubernetes minor version	Check the Ceph-CSI compatibility notes for your Kubernetes version and upgrade the driver before or alongside the control plane
Volumes from one cluster appear in another	Several Kubernetes clusters share one CephX user or one clusterID mapping	Create a separate CephX user per Kubernetes cluster with caps limited to its own pools and filesystems

Questions buyers ask about Ceph-CSI on external Ceph

Can our own platform team set up Ceph-CSI on an external Ceph cluster without a partner?

Yes, a team with Kubernetes and Ceph experience can do it, and the work is mostly configuration rather than new software. The harder part is the surrounding design: which CephX users exist, which pools each cluster may touch, how StorageClasses map to clusters, and how the driver is upgraded alongside Kubernetes. Teams that already run Ceph day to day usually need the least outside help. Teams that are new to one side or the other tend to benefit from a written design review before the first StorageClass goes into production. Confirm internally who will own the driver after the first deployment, because that ownership decision drives most of the long-term effort.

What makes a Ceph-CSI engagement take more or less effort?

The main drivers are the number of Ceph clusters, the number of StorageClasses per cluster, and how tenancy is modeled with CephX. Each cluster adds its own clusterID mapping, monitor list, secrets and RBAC objects. Each additional tenant that needs isolated pools or keys adds a CephX user, a set of capabilities to review and a test to prove the boundary holds. Storage types matter too: RBD, CephFS and NFS have different access modes, snapshot behavior and failure paths. Upgrade cadence adds recurring work, since Kubernetes minor releases and Ceph releases each need a compatibility check. Ask any provider to price these drivers separately so you can see which ones your environment actually triggers.

How long does a typical Ceph-CSI setup take?

The duration depends mainly on how many clusters and storage classes are in scope and how much of the access model must be designed from scratch. A single cluster with one RBD class and a clear CephX user is a much smaller job than several clusters with CephFS, NFS and separate tenant keys. Access to the Ceph and Kubernetes environments, change approvals and test windows often set the pace more than the configuration itself. Ask for a timeline in the written scope that lists each milestone, the environments it touches and the acceptance tests, so that the schedule reflects your change process rather than a generic estimate.

What does our team need to provide for a Ceph-CSI project?

The work needs network and administrative access on both sides of the integration. On the Ceph side, the team needs an account or review path to create CephX users, pools and capability sets, plus confirmation of monitor addresses and the cluster fsid. On the Kubernetes side, it needs access to create the driver, its secrets and StorageClasses in a test cluster first. Network changes are often required so that Kubernetes nodes can reach Ceph monitors and OSDs, and firewall or routing rules should be approved in advance. Plan change windows for the first production StorageClass and for any later driver upgrade, and name a contact who can approve storage-impacting changes during those windows.

When is Rook a better choice than an external Ceph cluster with Ceph-CSI?

Rook is usually the better choice when the Ceph cluster itself should live inside Kubernetes and be managed by Kubernetes operators. The Ceph documentation warns against deploying Ceph-CSI by hand in a Rook cluster, because Rook installs and manages the driver itself. An external cluster with Ceph-CSI fits better when Ceph is run as shared infrastructure by a storage team, serves virtual machines or other platforms beside Kubernetes, or must be operated separately from application clusters. The cephadm documentation also points to Rook as the Kubernetes-native way to deploy Ceph, so the decision is about who operates the storage and where its lifecycle sits.

What happens to the driver when Kubernetes or Ceph is upgraded?

Both upgrades need a compatibility check, and the order matters. For Kubernetes, the version skew policy requires the API server to move one minor version at a time, ahead of the controller manager, scheduler and kubelets, and kubelets may run up to three minor versions behind. The Ceph-CSI driver must be checked against both the Kubernetes and Ceph versions in use before either side moves. Kubernetes minor releases arrive about three times a year, so driver upgrades are a recurring task rather than a one-time one. Ceph releases follow their own schedule and end-of-life dates. Ask for a written upgrade procedure, a test cluster that mirrors production, and a rollback plan for the StorageClass and CephX changes.

Does the Ceph-CSI driver have a license cost?

Ceph-CSI and Kubernetes are open source, so there is no license fee for either. Ceph is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition. The recurring costs are the staff time to run the clusters, the hardware and network for Ceph, and any support or retainer you choose to buy. Ask a provider to separate one-time design and deployment fees from ongoing support, and to state what each covers, so that you can compare an internal model with an outside one on the same terms.

Keeping Ceph-CSI aligned with Kubernetes and Ceph upgrades

Plan every Kubernetes or Ceph upgrade as a Ceph-CSI compatibility check, because the driver sits between two release trains that move on their own schedules. Kubernetes publishes roughly three minor releases a year on a cycle of about 14 weeks, and the project maintains only the three most recent minor versions. As of September 2026, those were 1.37, 1.36 and 1.35, with 1.35 scheduled to reach end of life on February 28, 2027, per the Kubernetes releases page. Put those dates on your calendar so that a Kubernetes upgrade never becomes an unplanned driver replacement.

The version skew policy sets the order of operations. The kube-apiserver must be upgraded one minor version at a time and before kube-controller-manager, kube-scheduler and kubelets, and kubelets may run up to three minor versions behind the API server. Ceph-CSI runs as pods and sidecars on those nodes, so confirm that the Ceph-CSI release you intend to run supports the Kubernetes minor version you are moving to before you start. Then check the Ceph side: the Ceph release lifecycle decides when your cluster must move, and the Ceph releases page gives the estimated end of life for Squid (October 31, 2026) and Tentacle (June 1, 2027). Confirm these dates against the live page at the time you plan, since they are estimates.

Record the Ceph-CSI image tags, the CSI sidecar versions, the Kubernetes minor version and the Ceph release in one compatibility record, and rerun the RBD and CephFS test PVC cycle (create, snapshot, expand, mount, delete) in a staging cluster after each change. Ask your storage team to confirm the CephX capabilities required by the new driver version, because a driver upgrade can require new client permissions that the existing client.kubernetes keys do not have. Schedule the Ceph and Kubernetes upgrades in separate change windows, so that a failed step can be rolled back on its own.

How DeployOpen works on this

DeployOpen plans and implements Ceph-CSI integrations inside your own infrastructure, starting from a written scope that names the Kubernetes clusters, Ceph cluster and storage classes involved. We build against your existing external Ceph cluster, test each driver path, and document the mappings your platform team needs to operate them.

How we scope

We confirm which Kubernetes clusters need RBD, CephFS or NFS volumes and which Ceph cluster each one will consume.
We record the Kubernetes and Ceph versions in use so the Ceph-CSI release and deployment method can be matched to them.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

How we build

We deploy the Ceph-CSI-Operator where it fits your release, and map each StorageClass clusterID to the ClientProfile name agreed for that cluster.
We create one CephX user per Kubernetes cluster with capabilities limited to the pools and filesystems that cluster needs.
We test provisioning, expansion, snapshots and deletion for each driver path before the StorageClasses are released to application teams.

How we hand over

You receive the written configuration: operator and driver versions, ClientProfile names, clusterID values, CephX users and pool assignments.
We document the upgrade order for Kubernetes and Ceph-CSI, and the checks to run after each step.
We walk your platform and storage teams through restore tests and the runbook for a failed driver or an unreachable Ceph monitor.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Ceph-CSI version reviews when Kubernetes or Ceph releases move, including checks against the supported version list.
We can help you confirm with Rook or your storage team whether a move to Rook-managed Ceph is the better long-term choice for a given cluster.

Ceph CSI drivers for Kubernetes on an external Ceph cluster