程鹏 译 分布式实验室
在Kubernetes v0.3正式版中，Rook将原生态的云存储系统以Kubernetes Application方式与Kubernetes结合；块存储，对象存储以及分布式文件系统已经直接与Kuberenete Application进行了融合。
Rook存储完全自动化地管理着存储集群，这点与传统上的集群管理员的自动管理方式一样，区别在于：
传统意义上的集群管理员都必须掌握安装和监控系统。而Rook存储的运行是完全自动化的；
Rook存储是以通过第三方资源以Kubernetes扩展的形式运行的。
首先，创建一个名为rook-operator.yaml的文件：
启动Rook存储。
kubectl create -f rook-operator.yaml
Rook存储运行起来之后，我们可以开始创建一个存储集群了，创建rook-cluster.yaml文件：
开始创建集群。
kubectl create -f rook-cluster.yaml
就这样，几分钟之后，我们就拥有用于Kubernetes Applications的存储集群了。
Rook存储的目标是确保我们用于正常运行的存储集群，首次运行时，必要的Kubernetes原语都会新建，然后，Rook存储集群将会持续监控所有的存储组件。
声明卷
为了使用Rook块存储，我们Kubernetes Application首先需要创建基于Ceph RBD卷插件的存储类型：rook-storageclass.yaml
你可能已经注意到我们需要在yaml文件中写入monitor节点信息，我们将在下个正式版中简化。Kubernetes的Rook卷插件，虽然这个过程很痛苦。但是现在，我们仍然需要运行以下命令来声明monitor节点信息：
export MONS=$(kubectl -n rook get pod mon0 mon1 mon2 -o json|jq ".items[].status.podIP"|tr -d "\""|sed -e 's/$/:6790/'|paste -s -d, -)
最后，我们可以替换yaml文件中的monitor节点信息，并且创建存储类型：
sed 's#INSERT_HERE#'$MONS'#' rook-storageclass.yaml | kubectl create -f -
现在，我们在Kuberenetes Application中创建一个卷声明，例如：
我们在容器指定部分使用卷声明：
这个例子中的yaml中可以从这里（https://github.com/rook/rook/blob/master/demo/kubernetes/mysql.yaml）获得，以及可以从这里（https://github.com/rook/rook/tree/master/demo/kubernetes#consume-the-storage）获取详细的介绍。
Rook存储集群客户端
连接Rook存储集群的另一个办法是通过使用Rook 客户端容器，该容器提供了简单的直接测试块设备，对象存储以及文件系统的基础环境；然而这并非是说只能这样来运用Rook存储系统，它仅仅提供了用于更加了解Kububernetes卷插件原理的一个实验环境而已。
启动并进入以下pod，然后我们就有使用rook命令来管理存储集群的基础环境。
创建client Pod： rook-client.yaml
运行client pod：
kubectl create -f rook-client.yml
等到pod处于运行状态，然后进入pod：
kubectl exec -it rook-client bash
该工具将自动载入管理API的配置以及管理Rook集群的配置；
查看集群中的节点信息：
rook node ls
查看集群状态：
rook status
创建S3存储：
rook object create
查看所有的使用方法，可以查看readme（https://github.com/rook/rook/blob/master/demo/client/README.md）或者使用help：
rook --help
Kubernetes资源规划
该存储通过创建若干Kubernetes原生资源来自动完成集群初始化，然后监控资源以保证集群的健康状态。
密钥
集群首次运行，cephx admin【这里为什么是ceph admin呢，因为rook cluster仅仅是ceph cluster的封装而已】和monitor密钥将自动生成并保存在Kubernetes密钥对中。
服务
三个Ceph monitor运行以Pods形式集群中运行；这些Pods对保证存储集群的健康是至关重要的。
在集群中至少有三个节点，由于反亲和性在默认情况下是被指定的；所以故障域必须是跨节点的。
在Pods运行之后，集群将在通知Ceph osd之前等待Ceph monitor选举确定；集群将启用一个Go协程来监控monitor pods的健康状态。
服务集合
在标明为存储节点的机器中一对damon set将为Ceph OSDs而运行；因为osd pod运行在各个机器上，存储配置将存储为空目录形式； 默认情况下，数据将存放在该目录下，在未来，我们将赋予存储集群管理员指定节点上使用设备或目录来进行存储的能力；
pod将监控本地OSD的运行状态。
第三方资源
如果管理员需要更改集群的配置，Rook提供了TPR（third party resources ）的方式来指导该如何配置；集群将监控TPR（third party resources ）以及应用该修改在集群中，将来，TPR将拥有兼容s3/swift的ceph RGW，分布式文件系统（mds），管理Ceph用户（这些用户可以使用rbd卷）等等功能。
管理 API
RooK API Deployment用以提供RESTful形式的管理平台以及简化集群周边的管理任务，API则提供了查看集群健康状态以及更新集群配置的功能，最典型的API示例就是rook client tool。
可靠性
假如Rook存储由于某些原因停止运行，存储集群依然会像预期那样继续运行，Ceph Mons、OSDs、MDS和RGW服务与Rook存储没有耦合，最基础的集群监控是通过Kubernetes自身来运行的，如果Rook存储再次运行，更加完善的健康检测系统将会恢复；并且维护第三方资源的健康状态。
周边
Rook存储的目标是使用集群来完成自动存储，维持集群的可靠性，维护数据的安全性；Rook存储现阶段仍旧处于起步阶段；我们期待您的反馈以及为将来的版本做出贡献；查看更多文档以及简单yaml文件，查看rook Githup（https://github.com/rook/rook/tree/master/demo/kubernetes）。