1、placement调度概述

rook借助kubernetes的默认调度机制，Ceph组件以pods的形式调度运⾏在kubernetes节点中，然⽽每 个节点因⻆⾊的不同，其机器的配置也有所不同，⽐如mds对CPU计算要求较⾼，磁盘次之，相反osd节 点则对磁盘和内存要求较⾼，CPU次之，因此在规划的时候需要根据觉得的不同⽽分配节点。
最终效果：根据规划来分配⻆⾊

rook提供了多种调度策略
nodeAffinity 节点亲和⼒调度，根据labels选择合适的调度节点
podAffinity pods亲和⼒调度，将pods调度到具有相同性质类型的节点上
podAntiAffinity pods反亲和调度，将pods调度到与某些pods相反的节点
topologySpreadConstraints 拓扑选择调度 tolerations 污点容忍调度，允许调度到某些具有“污点”的节点上
更多调度的细节可以看我写的https://www.yuque.com/junmoxiao-pwkpf/zpmbo6/damqdb文档

rook⽀持的调度对象
mon
mgr
osd
cleanup

2、清理重建rook集群

参考文档https://www.rook.io/docs/rook/v1.5/ceph-teardown.html

2.1、删除资源对象

[root@node-1 ceph]# kubectl delete -f operator.yaml
[root@node-1 ceph]# kubectl delete -f cluster.yaml
[root@node-1 ceph]# kubectl delete -f common.yaml
[root@node-1 ceph]# kubectl delete -f crds.yaml

2.2、删除源数据

rm -rf /var/lib/rook/

2.3、 清理磁盘信息，登陆到每个节点上，将vgs和pv删除

[root@master1 ceph]# vgremove ceph-67c4bdad-5f65-44eb-8e20-6cf7728b5e5e
[root@master1 ceph]# pvremove /dev/vdb

2.4、 删除ceph-rook命名空间

参考文档https://www.codeleading.com/article/5578440677/
由于⼀些资源对象为能删除，导致ceph-rook这个命名空间⽆法删除，解决⽅法可以找到 cephclusters.ceph.rook.io⾃定义资源中的finalizers删除

3、定制Rook集群

背景：⽣产环境有⼀些专⻔的节点⽤于mon、mgr，存储节点节点使⽤单独的节点承担,利⽤调度机制实现

亲和性调度可以分成软策略和硬策略两种方式:

  • 软策略就是如果现在没有满足调度要求的节点的话，Pod 就会忽略这条规则，继续完成调度过程，说白了就是满足条件最好了，没有的话也无所谓
  • 硬策略就比较强硬了，如果没有满足条件的节点的话，就不断重试直到满足条件为止，简单说就是你必须满足我的要求，不然就不干了

对于亲和性和反亲和性都有这两种规则可以设置： preferredDuringSchedulingIgnoredDuringExecution 和requiredDuringSchedulingIgnoredDuringExecution，前面的就是软策略，后面的就是硬策略。

3.1、定制mon调度参数

spec:
placement:
mon:
nodeAffinity: #节点亲和性
requiredDuringSchedulingIgnoredDuringExecution: #硬策略
nodeSelectorTerms:
- matchExpressions:
- key: ceph-mon
operator: In #label 的值在某个列表中
values:
- enabled
image.png
#设置磁盘的参数，调整为false，⽅便后⾯定制
image.png
给节点打上标签/需要给三个节点分别打上标签~在rook配置文件中有反
亲和性，每个节点上只能存在一个mon节点。
[root@master1 ceph]# kubectl label node master2 ceph-mon=enabled
node/master2 labeled
[root@master1 ceph]# kubectl label node node1 ceph-mon=enabled
node/node1 labeled
[root@master1 ceph]# kubectl label node node2 ceph-mon=enabled
node/node2 labeled
可以都调度到了指定的节点上面
rook-ceph-mon-a-796d8bf4bc-z8wq4 1/1 Running 0 31s 10.244.3.55 node2
rook-ceph-mon-b-fd75dcfff-jtzml 1/1 Running 0 19s 10.244.1.31 master2
rook-ceph-mon-c-5b6b864b58-kp48d 1/1 Running 0 6s 10.244.2.34 node1

3.2 定制mgr调度参数

给node-1和node-2打上ceph-mgr=enabled的标签
[root@master1 ceph]# vim cluster.yaml
[root@master1 ceph]# kubectl label node node1 ceph-mgr=enabled
node/node1 labeled
[root@master1 ceph]# kubectl label node node2 ceph-mgr=enabled
node/node2 labeled

修改mgr的调度参数,修改完之后重新apply cluster.yaml配置使其加载到集群中
mgr:
nodeAffinity: #节点亲和性
requiredDuringSchedulingIgnoredDuringExecution: #硬策略
nodeSelectorTerms:
- matchExpressions:
- key: ceph-mgr
operator: In #label 的值在某个列表中
values:
- enabled

3.3 定制osd存储节点

rook默认会使⽤所有节点上的所有满⾜条件的磁盘，并将其加⼊到Ceph集群中作为osd⻆⾊，⽣产环境 中，磁盘有特定的功能和⻆⾊，需要根据磁盘类型来分配，同时，⽣产中扩容会涉及到数据的均衡 （rebalance）操作，因此需要在低峰期或者单次扩容较少的osd，避免扩容对⽣产业务造成影响。
nodes:
- name: “master2”
devices:
- name: “vdb”
config:
storeType: bluestore
journalSizeMB: “4096”
- name: “node1”
devices:
- name: “vdb”
config:
storeType: bluestore
journalSizeMB: “4096”
- name: “node2”
devices:
- name: “vdb”
config:
storeType: bluestore
journalSizeMB: “4096”
修改配置完毕后重新apply cluster.yaml，会根据预先设置内容创建osd。
[root@master1 ceph]# kubectl get pods -n rook-ceph
rook-ceph-osd-0-84f8f7b664-x77v5 1/1 Running 0 6m31s
rook-ceph-osd-1-589587f7db-r2sh8 1/1 Running 0 61s
rook-ceph-osd-2-7b74986b7f-zbtdd 1/1 Running 0 60s
如果有新加的node节点的话，可以在配置文件里面添加。

3.4 定制osd调度参数

结合调度算法，将满⾜条件的节点分配到特定节点上，同时使⽤节点上特定的磁盘

3.4.1、设置osd的调度参数

osd:
nodeAffinity: #节点亲和性
requiredDuringSchedulingIgnoredDuringExecution: #硬策略
nodeSelectorTerms:
- matchExpressions:
- key: ceph-osd
operator: In #label 的值在某个列表中
values:
- enabled

3.4.2、定制osd的磁盘参数

  • name: “node3”
    devices:
    - name: “vdb”
    config:
    storeType: bluestore
    journalSizeMB: “4096”
    重新apply cluster.yaml发现node-5⽆法加⼊到集群中，因为不满⾜调度的参数，添加标签使其满⾜调 度,同理将其他存储节点打上ceph-osd的标签

4、定制资源限制

默认组件没有设置资源分配，当出现资源争抢的时候可能会出现驱逐导致集群雪崩，为了保证Ceph的核⼼组件能分配 到特定的资源，需要设置合理的资源分配
可以看我前面编写的资源配额文档https://www.yuque.com/junmoxiao-pwkpf/zpmbo6/deaavz
mon,内存推荐128G
mds osd,每T磁盘建议需要有4G
resources:
mgr:
limits:
cpu: “8000m”
memory: “128Gi”
requests:
cpu: “8000m”
memory: “128Gi”
mon:
limits:
cpu: “4000m”
memory: “64Gi”
requests:
cpu: “4000m”
memory: “64Gi”
osd:
limits:
cpu: “4000m”
memory: “64Gi”
requests:
cpu: “4000m”
memory: “64Gi”

5、健康检查机制

kubernetes默认提供了健康探测机制，通常包含有三种：
liveness probe（存活探针）

  • kubelet 通过使用 liveness probe 来确定你的应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。

    readiness probe（可读性探针）

  • kubelet 使用 readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从 Service 的 Endpoints 列表中移除出来，这样我们的流量就不会被路由到这个 Pod 里面来了。

    startupProbe（启动探针）
    该探针将推迟所有其他探针，直到 Pod 完成启动为止，使用方法和存活探针

    rook提供了daemonHealth和livenessProbe健康探测机制，⽤于检测守护进程和是否存活（⽤于Ceph 内部检测） 默认关闭
    mon在线健康探测机制
    livenessProbe:
    exec:
    command:
    - env
    - -i
    - sh
    - -c
    - ceph —admin-daemon /run/ceph/ceph-mon.a.asok mon_status
    failureThreshold: 3
    initialDelaySeconds: 10
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1
    mgr存活探测机制
    livenessProbe:
    failureThreshold: 3
    httpGet:
    path: /
    port: 9283
    scheme: HTTP
    initialDelaySeconds: 60
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1
    osd存活探测机制
    livenessProbe:
    exec:
    command:
    - env
    - -i
    - sh
    - -c
    - ceph —admin-daemon /run/ceph/ceph-osd.0.asok status
    failureThreshold: 3
    initialDelaySeconds: 45
    periodSeconds: 10
    successThreshold: 1
    timeoutSeconds: 1