Project: Rook (Runtime / Cloud Native Storage)
File: example-configurations.md

title: Example Configurations Configuration for Rook and Ceph can be configured in multiple ways to provide block devices, shared filesystem volumes or object storage in a kubernetes namespace. While several examples are provided to simplify storage setup, settings are available to optimize various production environments. See the folder for all the rook/ceph setup example spec files. The first step to deploy Rook is to create the CRDs and other common resources. The configuration for these resources will be the same for most deployments. The and sets these resources up. ```console kubectl create -f crds.yaml -f common.yaml ``` The examples all assume the operator and all Ceph daemons will be started in the same namespace. If deploying the operator in a separate namespace, see the comments throughout `common.yaml`. After the common resources are created, the next step is to create the Operator deployment. Several spec file examples are provided in : : The most common settings for production deployments `kubectl create -f operator.yaml` : Includes all of the operator settings for running a basic Rook cluster in an OpenShift environment. You will also want to review the to confirm the settings. `oc create -f operator-openshift.yaml` Settings for the operator are configured through environment variables on the operator deployment. The individual settings are documented in . Now that the operator is running, create the Ceph storage cluster with the CephCluster CR. This CR contains the most critical settings that will influence how the operator configures the storage. It is important to understand the various ways to configure the cluster. These examples represent several different ways to configure the storage. : Common settings for a production storage cluster. Requires at least three worker nodes. : Settings for a test cluster where redundancy is not configured. Requires only a single node. : Common settings for backing the Ceph Mons and OSDs by PVs. Useful when running in cloud environments or where local PVs have been created for Ceph to consume. : Connect to an with minimal access to monitor the health of the cluster and connect to the storage. : Connect to an with the admin key of the external cluster to enable remote creation of pools and configure services such as an or a . : Create a cluster in "stretched" mode, with five mons stretched across three zones, and the OSDs across two zones. See the . See the topic for more details and more examples for the settings. Now we are ready to setup Block, Shared Filesystem or Object storage in the Rook cluster. These storage types are respectively created with the CephBlockPool, CephFilesystem and CephObjectStore CRs. Ceph provides raw block device volumes to pods. Each example below sets up a storage class which can then be used to provision a block device in application

The storage class is defined with a Ceph pool which defines the level of data redundancy in Ceph: : This example illustrates replication of 3 for production scenarios and requires at least three worker nodes. Data is replicated on three different kubernetes worker nodes. Intermittent or long-lasting single node failures will not result in data unavailability or loss. : Configures erasure coding for data durability rather than replication. Ceph's erasure coding is more efficient than replication so you can get high reliability without the 3x replication cost of the preceding example (but at the cost of higher computational encoding and decoding costs on the worker nodes). Erasure coding requires at least three worker nodes. See the documentation. : Replication of 1 for test scenarios. Requires only a single node. Do not use this for production applications. A single node failure can result in full data loss. The block storage classes are found in the examples directory: `csi/rbd`: the CSI driver examples for block devices See the topic for more block storage settings. Ceph filesystem (CephFS) allows the user to mount a shared posix-compliant folder into one or more application pods. This storage is similar to NFS shared storage or CIFS shared folders, as explained . Shared Filesystem storage contains configurable pools for different scenarios: : Replication of 3 for production scenarios. Requires at least three worker nodes. : Erasure coding for production scenarios. Requires at least three worker nodes. : Replication of 1 for test scenarios. Requires only a single node. Dynamic provisioning is possible with the CSI driver. The storage class for shared filesystems is found in the directory. See the topic for more details on the settings. Ceph supports storing blobs of data called objects that support HTTP(s)-type get/put/post and delete semantics. This storage is similar to AWS S3 storage, for example. Object storage contains multiple pools that can be configured for different scenarios: : Replication of 3 for production scenarios. Requires at least three worker nodes. : Replication of 3 with rgw in a port range valid for OpenShift. Requires at least three worker nodes. : Erasure coding rather than replication for production scenarios. Requires at least three worker nodes. : Replication of 1 for test scenarios. Requires only a single node. See the topic for more details on the settings. : Creates a simple object storage user and generates credentials for the S3 API The Ceph operator also runs an object store bucket provisioner which can grant access to existing buckets or dynamically provision new buckets. Creates a request for a new bucket by referencing a StorageClass which saves the bucket when the initiating OBC is deleted. Creates a request for a new bucket by referencing a StorageClass which deletes the bucket when the initiating OBC is deleted. Creates a new StorageClass which defines the Ceph Object Store and retains the bucket after the initiating OBC is deleted. Creates a new StorageClass which defines the Ceph Object Store and deletes the bucket after the initiating OBC is deleted.