my-rook-config/Documentation/kubernetes.md

Rook on Kubernetes

• Quickstart
• Design

Quickstart

WARNING: Only Kubernetes v1.6.0 or higher is supported by Rook at this time (while Rook is in alpha it will track the latest release to use the latest features)

This example shows how to build a simple, multi-tier web application on Kubernetes using persistent volumes enabled by Rook.

Prerequisites

To make sure you have a Kubernetes cluster that is ready for Rook, you can follow these quick instructions, including:

• The kubelet requires access to modprobe and rbd on host

Note that we are striving for even more smooth integration with Kubernetes in the future such that Rook will work out of the box with any Kubernetes cluster.

Deploy Rook

With your Kubernetes cluster running, Rook can be setup and deployed by simply creating the rook-operator deployment and creating a rook cluster.

cd demo/kubernetes
kubectl create -f rook-operator.yaml

# verify the rook-operator pod is in the `Running` state before proceeding
kubectl get pod

Now that the rook-operator pod is running, we can create the Rook cluster. See the documentation on configuring the cluster.

kubectl create -f rook-cluster.yaml

Use kubectl to list pods in the rook namespace. You should be able to see the following pods once they are all running:

$ kubectl -n rook get pod
NAME                        READY     STATUS    RESTARTS   AGE
mon0                        1/1       Running   0          1m
mon1                        1/1       Running   0          1m
mon2                        1/1       Running   0          1m
osd-3n85p                   1/1       Running   0          1m
osd-6jmph                   1/1       Running   0          1m
rook-api-1709486253-gvdnc   1/1       Running   0          1m

Storage

For a walkthrough of the three types of storage exposed by Rook, see the guides for:

• Block: Create block storage to be consumed by a pod
• Shared File System: Create a file system to be shared across multiple pods
• Object: Create an object store that is accessible inside or outside the Kubernetes cluster

Tools

Rook Client

The rook client tool allows you to configure Block, File System, and Object storage. You can start a client pod that is automatically configured to connect to your storage cluster with the following:

kubectl create -f rook-client.yml

# Check when the pod is in the Running state
kubectl -n rook get pod rook-client

# Connect to the client pod 
kubectl -n rook exec rook-client -it sh

# Verify the rook client can talk to the cluster
rook node ls

Now you can use the rook tool as required in the File System and Object walkthroughs, or a simplified walkthrough of block, file and object storage.

Advanced Configuration and Troubleshooting

We have created a toolbox container that contains the full suite of Ceph clients for debugging and troubleshooting your Rook cluster. Please see the toolbox readme for setup and usage information. Also see our advanced configuration document for helpful maintenance and tuning examples.

Monitoring

Each Rook cluster has some built in metrics collectors/exporters for monitoring with Prometheus. To learn how to set up monitoring for your Rook cluster, you can follow the steps in the monitoring guide.

Teardown

To clean up all the artifacts created by the demo, first cleanup the resources from the block, file, and object walkthroughs (unmount volumes, delete volume claims, etc), then run the following:

kubectl delete -f rook-operator.yaml
kubectl delete -n rook cluster rook
kubectl delete -n rook serviceaccount rook-api
kubectl delete clusterrole rook-api
kubectl delete clusterrolebinding rook-api
kubectl delete thirdpartyresources cluster.rook.io pool.rook.io
kubectl delete secret rook-rook-user
kubectl delete namespace rook

If you modified the demo settings, additional cleanup is up to you for devices, host paths, etc.

Design

With Rook running in the Kubernetes cluster, Kubernetes applications can mount block devices and filesystems managed by Rook, or can use the S3/Swift API for object storage. The Rook operator automates configuration of the Ceph storage components and monitors the cluster to ensure the storage remains available and healthy. There is also a REST API service for configuring the Rook storage and a command line tool called rook.

The Rook operator is a simple container that has all that is needed to bootstrap and monitor the storage cluster. The operator will start and monitor ceph monitor pods and a daemonset for the OSDs, which provides basic RADOS storage as well as a deployment for a RESTful API service. When requested through the api service, object storage (S3/Swift) is enabled by starting a deployment for RGW, while a shared file system is enabled with a deployment for MDS.

The operator will monitor the storage daemons to ensure the cluster is healthy. Ceph mons will be started or failed over when necessary, and other adjustments are made as the cluster grows or shrinks. The operator will also watch for desired state changes requested by the api service and apply the changes.

The Rook daemons (Mons, OSDs, RGW, and MDS) are compiled to a single binary rookd, and included in a minimal container. rookd uses an embedded version of Ceph for storing all data -- there are no changes to the data path. Rook does not attempt to maintain full fidelity with Ceph. Many of the Ceph concepts like placement groups and crush maps are hidden so you don't have to worry about them. Instead Rook creates a much simplified UX for admins that is in terms of physical resources, pools, volumes, filesystems, and buckets.

Rook is implemented in golang. Ceph is implemented in C++ where the data path is highly optimized. We believe this combination offers the best of both worlds.

See Design wiki for more details.