教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载ceph-helm 项目以 Helm Chart 的形式把 Ceph 的 MON、MGR、OSD、MDS、RGW 等组件封装为 Kubernetes 原生资源让我们可以在已有的 Kubernetes 集群上以声明式方式托管部署一套完整的 Ceph 分布式存储集群。本文以《Kubernetes Handbook》中的《用 Helm 托管安装 Ceph 集群并提供后端存储》一文为骨架完整还原从 Helm 初始化、Chart 构建、节点打标签、helm install 到创建 PVC 挂载 RBD 的全流程并结合仓库中 Ceph 基础概念、使用 Ceph 做持久化存储 与 rbd-provisioner 方案 等配套文档讲透 RBD 动态供给的底层原理与常见排错路径。读完本文你将能够在自己的 Kubernetes 环境里复现一套由 StorageClass 驱动、可动态分配持久卷的 Ceph RBD 存储后端。背景为什么要在 Kubernetes 里托管部署 CephCeph 是一个开源的分布式对象、块和文件存储系统诞生于 2003 年是塞奇・韦伊博士论文的成果2006 年在 LGPL 2.1 许可证下发布已与 Linux 内核 KVM 深度集成。它针对当前工作负载与基础设施对对象Object、块Block、文件File三种数据访问方式的不同需求而设计具有可扩展性且没有单点故障可以在通用硬件上运行于生产环境。Ceph 的核心是 RADOSReliable Autonomic Distributed Object Store可靠的自动分布式对象存储集群由两类节点构成Ceph 存储设备节点每个节点运行一个或多个 Ceph OSD 守护进程每个磁盘设备对应一个 OSD。OSD 是 Linux 守护进程处理与其分配磁盘HDD 或 SSD相关的所有操作通过访问本地文件系统常用 XFS、btrfs、ext4来存储数据和元数据每个 OSD 还需要一个日志用于对 RADOS 对象进行原子更新日志可放在独立磁盘上通常是 SSD 以提升性能。Ceph Monitor 节点运行单个 Ceph Monitor 守护进程维护集群映射的主副本。推荐使用三个或更多 Monitor它们通过法定数量quorum维护集群映射需要大多数 Monitor 确认仲裁因此建议奇数个——例如 3 个或 4 个 Monitor 可防止单个故障5 个可防止两个故障。在此基础上Ceph 向上提供三类服务对象存储通过 Ceph 对象网关守护进程 radosgw 提供与 Amazon S3 RESTful API 子集、OpenStack Swift API 子集兼容的接口块存储Ceph RBD实现为对象存储顶部的薄层数据分布在集群多个 OSD 上利用 RADOS 的快照、复制和一致性能力通过 Linux 内核模块或 librbd 库与 RADOS 通信KVM 虚拟机也可通过 librbd 访问 Ceph 卷文件系统CephFS符合 POSIX 的文件系统需要至少一个 Ceph 元数据服务器MDS处理文件操作MDS 利用 RADOS 对象存储文件系统数据与属性可水平扩展。ceph-helm正是把上述 MON、MGR、OSD、MDS、RGW 等守护进程以容器形式托管到 Kubernetes 的部署方案monitor 与 OSD 以 DaemonSet 形式调度到打了对应标签的节点mgr/mds/rgw 与 rbd-provisioner 以 Deployment 形式运行keyring 生成等一次性任务以 Job 形式执行。部署完成后再借助 StorageClass 动态供给让应用可以直接通过 PVC 申请 RBD 块设备。这与仓库中 Ceph 基础概念 一文其中还列出了 RBD 是少数自带 Internal Provisioner 的卷插件之一形成了先托管部署集群、再动态供给存储的完整链路。部署前提与当前限制ceph-helm 项目可让你在 Kubernetes 环境以托管方式部署 Ceph。本文档假定Kubernetes 环境已经可用Helm 客户端与集群网络可达且节点上具备供 OSD 使用的裸设备或可被 zap 的设备。使用 ceph-helm 时有以下三条已知限制规划拓扑时需要提前规避Public 网络和 Cluster 网络必须是同一个网络即无法在 ceph-overrides.yaml 中配置两个隔离网段如果 storageclass 用户标识不是 admin则必须在 Ceph 集群中手动创建用户并在 Kubernetes 中创建其 secretceph-mgr 只能运行 1 个 replica。此外文档写作时Helm v2 时代helm init会在集群中部署 Tiller 服务端且 ceph-helm 默认使用本地 Helm repo 存放 Charts如果你的环境使用 Helm v3已移除 Tiller 与helm serve请将上述步骤替换为helm repo add/helm install的等价操作其后的 Chart 配置与 Kubernetes 资源编排逻辑依然适用。第一步安装并初始化 Helm首先按照 Helm 官方说明安装 Helm 客户端。Helm 通过从本地读取 Kubernetes 配置文件默认~/.kube/config来查找 Kubernetes 集群因此要确保Kubernetes 配置文件已下载到本地且 Helm 客户端可以访问该配置Kubernetes 集群必须配置并运行 Tiller 服务器且本地 Helm 客户端与 Tiller 网络可达。要在本地运行 Tiller 并将 Helm 连接到它运行如下命令此命令会在 Kubernetes 集群部署一个 tiller 实例$ helm initceph-helm 项目默认使用本地的 Helm repo 来存储 Charts。要启动本地 Helm repo 服务器请运行$ helm serve $ helm repo add local http://localhost:8879/chartshelm serve在后台启动一个监听 8879 端口的本地 Chart 仓库服务helm repo add local将其注册为名为local的仓库源供后续helm install从本地仓库拉取 Chart。第二步添加 ceph-helm Charts 到本地 repo从 ceph-helm 项目克隆仓库并构建 Ceph Chart$ git clone https://github.com/ceph/ceph-helm $ cd ceph-helm/ceph $ makemake会根据 ceph-helm 仓库内的 Chart 模板与依赖生成可安装的 Chart 包并放入本地仓库目录使其可以通过local/ceph这个引用被 Helm 检索到。第三步编写 ceph-overrides.yaml 配置 Ceph 集群创建一个包含 Ceph 配置的ceph-overrides.yaml文件。这个文件可以存在于任何地方本文档默认此文件在用户的 home 目录中$ cat ~/ceph-overrides.yamlnetwork: public: 172.21.0.0/20 cluster: 172.21.0.0/20 osd_devices: - name: dev-sdd device: /dev/sdd zap: 1 - name: dev-sde device: /dev/sde zap: 1 storageclass: name: ceph-rbd pool: rbd user_id: k8s各配置项含义如下配置段键说明networkpublicCeph 公共网络网段客户端与 MON/OSD 通信networkclusterCeph 集群内部网络网段OSD 间复制/心跳受当前限制必须与 public 相同osd_devicesnameOSD 设备在 Kubernetes 标签中的名称标识会生成ceph-osd-device-name标签osd_devicesdevice节点上的真实块设备路径如/dev/sddosd_deviceszap置为1表示部署时清空zap该设备并重建分区storageclassname部署后创建的 StorageClass 名称如ceph-rbdstorageclasspoolRBD 镜像所在存储池如rbdstorageclassuser_id使用该 StorageClass 动态创建卷所用的 Ceph 客户端用户名注意如果未设置日志journal设备它将与 device 设备同位置即 journal 与数据共用同一块磁盘。另外ceph-helm/ceph/ceph/values.yaml文件包含所有可配置的选项覆盖全部组件mon/osd/mgr/mds/rgw的镜像、资源、网络、存储池与 StorageClass 参数可作为配置参考的完整字典。第四步创建 Ceph 集群的 namespace默认情况下ceph-helm 组件在 Kubernetes 的cephnamespace 中运行。如果要自定义请自定义 namespace 的名称使用默认 namespace 请运行$ kubectl create namespace ceph第五步配置 RBAC 权限Kubernetes ≥ v1.6 使 RBAC 成为默认的 admission controller。ceph-helm 要为每个组件提供 RBAC 角色和权限$ kubectl create -f ~/ceph-helm/ceph/rbac.yamlrbac.yaml文件假定 Ceph 集群将部署在ceph命名空间中因此它会为 ceph 命名空间内的各 ServiceAccountmon、osd、mgr 等绑定对应的 Role/ClusterRole 与权限使各组件 Pod 具备访问 ConfigMap、Secret、DaemonSet、Endpoints 等资源的权限。第六步给 Kubelet 节点打标签需要设置以下标签才能将 Ceph 组件调度到对应节点并完成部署ceph-monenabled ceph-mgrenabled ceph-osdenabled ceph-osd-device-nameenabledceph-osd-device-标签是基于ceph-overrides.yaml中定义的osd_devicesname 值创建的。从上面的示例配置dev-sdd、dev-sde出发将得到两个标签ceph-osd-device-dev-sddenabled和ceph-osd-device-dev-sdeenabled。每个 Ceph Monitor 节点运行 MON 与 MGR 守护进程的节点$ kubectl label node nodename ceph-monenabled ceph-mgrenabled每个 OSD 节点提供块设备运行 OSD 的节点标签中的设备名要与 overrides 一一对应$ kubectl label node nodename ceph-osdenabled ceph-osd-device-dev-sddenabled ceph-osd-device-dev-sdeenabledDaemonSet 通过 nodeSelector 精确匹配这些标签ceph-monDaemonSet 匹配ceph-monenabled每个ceph-osd-dev-*DaemonSet 同时匹配ceph-osdenabled与对应的ceph-osd-device-nameenabled。第七步执行 helm install 部署 Ceph运行 helm install 命令来部署 Ceph$ helm install --nameceph local/ceph --namespaceceph -f ~/ceph-overrides.yaml NAME: ceph LAST DEPLOYED: Wed Oct 18 22:25:06 2017 NAMESPACE: ceph STATUS: DEPLOYED RESOURCES: v1/Secret NAME TYPE DATA AGE ceph-keystone-user-rgw Opaque 7 1s v1/ConfigMap NAME DATA AGE ceph-bin-clients 2 1s ceph-bin 24 1s ceph-etc 1 1s ceph-templates 5 1s v1/Service NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE ceph-mon None none 6789/TCP 1s ceph-rgw 10.101.219.239 none 8088/TCP 1s v1beta1/DaemonSet NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE-SELECTOR AGE ceph-mon 3 3 0 3 0 ceph-monenabled 1s ceph-osd-dev-sde 3 3 0 3 0 ceph-osd-device-dev-sdeenabled,ceph-osdenabled 1s ceph-osd-dev-sdd 3 3 0 3 0 ceph-osd-device-dev-sddenabled,ceph-osdenabled 1s v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE ceph-mds 1 1 1 0 1s ceph-mgr 1 1 1 0 1s ceph-mon-check 1 1 1 0 1s ceph-rbd-provisioner 2 2 2 0 1s ceph-rgw 1 1 1 0 1s v1/Job NAME DESIRED SUCCESSFUL AGE ceph-mgr-keyring-generator 1 0 1s ceph-mds-keyring-generator 1 0 1s ceph-osd-keyring-generator 1 0 1s ceph-rgw-keyring-generator 1 0 1s ceph-mon-keyring-generator 1 0 1s ceph-namespace-client-key-generator 1 0 1s ceph-storage-keys-generator 1 0 1s v1/StorageClass NAME TYPE ceph-rbd ceph.com/rbdhelm install 的输出显示了将要部署的不同类型的资源其分工如下Secret如ceph-keystone-user-rgw存放 RGW 所需的凭据ConfigMapceph-bin/ceph-bin-clients存放各组件启动脚本ceph-etc存放 ceph.conf 等配置ceph-templates存放渲染用的模板文件Serviceceph-mon是无头服务CLUSTER-IP 为 None对外暴露 6789/TCP 供客户端发现 Monitorceph-rgw暴露 8088/TCP 提供对象存储网关入口DaemonSetceph-mon与每个ceph-osd-dev-*对应 overrides 中的每块设备按标签调度到对应节点保证每类守护进程覆盖所有目标节点Deploymentceph-mgr、ceph-mds、ceph-rgw分别运行管理器、元数据服务器与对象网关ceph-rbd-provisioner以 2 副本对外提供 RBD 动态供给ceph-mon-check负责监控 MON 状态Jobceph-mon/osd/mds/rgw-keyring-generator等一次性任务负责生成各组件 keyringceph-namespace-client-key-generator与ceph-storage-keys-generator生成 StorageClass 动态供给所需的客户端密钥StorageClass名为ceph-rbd、类型为ceph.com/rbd的存储类供后续 PVC 动态申请使用。其中ceph.com/rbd类型的 StorageClass 将由ceph-rbd-provisionerPod 负责实现动态供给创建 PVC 时自动在 Ceph 池中创建 RBD 镜像并生成对应 PV。第一次挂载时RBD 设备将被格式化format所有 RBD 设备默认使用 ext4 文件系统ceph.com/rbd不支持 fsType 选项。默认情况下RBD 将使用镜像格式 2format 2和镜像分层layering特性。可以在 values 文件中覆盖以下 storageclass 的默认值storageclass: name: ceph-rbd pool: rbd user_id: k8s user_secret_name: pvc-ceph-client-key image_format: 2 image_features: layering参数含义name为 StorageClass 名称pool为 RBD 池名user_id为客户端用户名user_secret_name为存放该用户 keyring 的 Secret 名称image_format为 RBD 镜像格式2 为 Luminous 及以后的推荐格式image_features为启用的镜像特性layering支持分层克隆。第八步验证 Ceph 集群状态使用下面的命令检查所有 Pod 是否正常运行这可能需要几分钟时间$ kubectl -n ceph get pods NAME READY STATUS RESTARTS AGE ceph-mds-3804776627-976z9 0/1 Pending 0 1m ceph-mgr-3367933990-b368c 1/1 Running 0 1m ceph-mon-check-1818208419-0vkb7 1/1 Running 0 1m ceph-mon-cppdk 3/3 Running 0 1m ceph-mon-t4stn 3/3 Running 0 1m ceph-mon-vqzl0 3/3 Running 0 1m ceph-osd-dev-sdd-6dphp 1/1 Running 0 1m ceph-osd-dev-sdd-6w7ng 1/1 Running 0 1m ceph-osd-dev-sdd-l80vv 1/1 Running 0 1m ceph-osd-dev-sde-6dq6w 1/1 Running 0 1m ceph-osd-dev-sde-kqt0r 1/1 Running 0 1m ceph-osd-dev-sde-lp2pf 1/1 Running 0 1m ceph-rbd-provisioner-2099367036-4prvt 1/1 Running 0 1m ceph-rbd-provisioner-2099367036-h9kw7 1/1 Running 0 1m ceph-rgw-3375847861-4wr74 0/1 Pending 0 1m注意因为我们没有用ceph-rgwenabled或ceph-mdsenabled给节点打标签Ceph 对象存储特性需要 ceph-rgwCephFS 特性需要 ceph-mds因此 MDS 和 RGW Pod 都处于 Pending 状态。也就是说如果不打算启用对象存储或文件系统Pending 是符合预期的如需启用给节点补上对应标签即可触发调度。一旦其他 Pod 都在运行状态请用如下命令从某个 MON 节点检查 Ceph 的集群状态$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- ceph -s cluster: id: e8f9da03-c2d2-4ad3-b807-2a13d0775504 health: HEALTH_OK services: mon: 3 daemons, quorum mira115,mira110,mira109 mgr: mira109(active) osd: 6 osds: 6 up, 6 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 bytes usage: 644 MB used, 5555 GB / 5556 GB avail pgs:该输出印证了三节点 Monitor 形成 quorum与每块设备一个 OSD的设计示例环境中有 3 个 MON 形成法定集群6 个 OSD两个节点 × 每节点两块设备全部 up 且 inMGR 处于 active 状态集群健康状态为 HEALTH_OK。此时集群尚无任何存储池与数据接下来就可以创建 RBD 池并向应用提供持久卷了。第九步为应用配置 RBD 持久卷1. 为 k8s 用户创建 keyring 并转换为 base64为~/ceph-overrides.yaml中定义的k8s用户创建一个密钥环并将其转换为 base64$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- bash # ceph auth get-or-create-key client.k8s mon allow r osd allow rwx poolrbd | base64 QVFCLzdPaFoxeUxCRVJBQUVEVGdHcE9YU3BYMVBSdURHUEU0T0E9PQo # exit该命令在 Ceph 中创建或读取已有客户端用户client.k8s授权其在mon上拥有只读权限、在osd上拥有对rbd池的 rwx 权限并将 key 编码为 base64 字符串供 Kubernetes Secret 使用。注意这正是文档开头当前限制第二条的落地动作因为 StorageClass 的user_id是k8s而非默认的admin必须手动创建用户并下发 secret。2. 更新用户 secret编辑cephnamespace 中已存在的用户 secret$ kubectl -n ceph edit secrets/pvc-ceph-client-key将 base64 值复制到key位置的值并保存apiVersion: v1 data: key: QVFCLzdPaFoxeUxCRVJBQUVEVGdHcE9YU3BYMVBSdURHUEU0T0E9PQo kind: Secret metadata: creationTimestamp: 2017-10-19T17:34:04Z name: pvc-ceph-client-key namespace: ceph resourceVersion: 8665522 selfLink: /api/v1/namespaces/ceph/secrets/pvc-ceph-client-key uid: b4085944-b4f3-11e7-add7-002590347682 type: kubernetes.io/rbd该 Secret 的类型为kubernetes.io/rbddata.key即上面生成的 base64 key。这里的编辑已有 secret路径依赖于 ceph-helm 在安装时通过ceph-storage-keys-generator等 Job 预置的pvc-ceph-client-key如果你希望手动从零创建可以参照仓库中 manifests/mariadb-cluster/ceph-secret.yaml 的写法type: kubernetes.io/rbddata.keykey 来自 etc/ceph/ceph.client.admin.keyring 这类 keyring 文件——例如grep key /etc/ceph/ceph.client.admin.keyring | awk {printf %s, $NF} | base64。3. 将 secret 复制到应用所在 namespace下面的示例创建一个在defaultnamespace 中使用 RBD 的 Pod。首先把用户 secret 从cephnamespace 复制到defaultnamespace$ kubectl -n ceph get secrets/pvc-ceph-client-key -o json | jq .metadata.namespace default | kubectl create -f - secret pvc-ceph-client-key created $ kubectl get secrets NAME TYPE DATA AGE default-token-r43wl kubernetes.io/service-account-token 3 61d pvc-ceph-client-key kubernetes.io/rbd 1 20sSecret 默认仅在其所在的 namespace 内可见而使用 RBD 卷的 Pod 运行在defaultnamespace因此必须将认证凭据复制到该 namespace。这与仓库 rbd-provisioner 文档 中的实践一致client.admin与业务用户的 secret 可放在系统 namespace但其他 namespace 若要使用动态供给需在相应 namespace 内创建保存业务用户 key 的 secret。4. 创建并初始化 RBD 池$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- ceph osd pool create rbd 256 pool rbd created $ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd pool init rbdceph osd pool create rbd 256创建名为rbd、PG 数为 256 的存储池rbd pool init rbd对池执行 RBD 初始化写入 RBD 应用相关的元数据使其可以承载 RBD 镜像。重要Kubernetes 使用 RBD 内核模块将 RBD 映射到主机Luminous 需要 CRUSH_TUNABLES 5Jewel。这些可调参数的最小内核版本是 4.5。如果您的内核不支持这些可调参数请运行ceph osd crush tunables hammer降级 CRUSH 可调项。重要由于 RBD 映射到主机系统上主机需要能够解析由 kube-dns 服务管理的ceph-mon.ceph.svc.cluster.local名称。要获得 kube-dns 服务的 IP 地址运行kubectl -n kube-system get svc/kube-dns。5. 创建 PVC创建一个 PVC$ cat pvc-rbd.yamlkind: PersistentVolumeClaim apiVersion: v1 metadata: name: ceph-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi storageClassName: ceph-rbd$ kubectl create -f pvc-rbd.yaml persistentvolumeclaim ceph-pvc created $ kubectl get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES STORAGECLASS AGE ceph-pvc Bound pvc-1c2ada50-b456-11e7-add7-002590347682 20Gi RWO ceph-rbd 3sPVC 声明了 20Gi 存储、访问模式 ReadWriteOnceRWO并通过storageClassName: ceph-rbd指向前面部署出的 StorageClass。ceph-rbd-provisioner监听到该 PVC 后自动在rbd池创建镜像并生成 PV因此 PVC 在数秒内即为 Bound 状态——这正是动态供给相对静态 PV 的核心优势无需预先创建固定大小的 PV。仓库中 使用 Ceph 做持久化存储 一文对此有同样描述1.4 以后使用 StorageClass 时无需预先创建固定大小的 PV直接创建 PVC 即可分配使用。6. 检查集群上是否已创建 RBD 镜像$ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd ls kubernetes-dynamic-pvc-1c2e9442-b456-11e7-9bd2-2a4159ce3915 $ kubectl -n ceph exec -ti ceph-mon-cppdk -c ceph-mon -- rbd info kubernetes-dynamic-pvc-1c2e9442-b456-11e7-9bd2-2a4159ce3915 rbd image kubernetes-dynamic-pvc-1c2e9442-b456-11e7-9bd2-2a4159ce3915: size 20480 MB in 5120 objects order 22 (4096 kB objects) block_name_prefix: rbd_data.10762ae8944a format: 2 features: layering flags: create_timestamp: Wed Oct 18 22:45:59 2017镜像名以kubernetes-dynamic-pvc-为前缀命名与仓库 rbd-provisioner 文档 中rbd ls --pool rbd的验证输出一致。size 20480 MB与 PVC 申请的 20Gi 对应format: 2、features: layering印证了默认的镜像格式 2 与分层特性配置。注意此时rbd ls需要指定--pool rbd或按上面的方式从 MON 容器执行默认池即为rbd。7. 创建使用此 PVC 的 Pod$ cat pod-with-rbd.yamlkind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: busybox image: busybox command: - sleep - 3600 volumeMounts: - mountPath: /mnt/rbd name: vol1 volumes: - name: vol1 persistentVolumeClaim: claimName: ceph-pvc$ kubectl create -f pod-with-rbd.yaml pod mypod created检查 Pod$ kubectl get pods NAME READY STATUS RESTARTS AGE mypod 1/1 Running 0 17s $ kubectl exec mypod -- mount | grep rbd /dev/rbd0 on /mnt/rbd type ext4 (rw,relatime,stripe1024,dataordered)Pod 通过persistentVolumeClaim.claimName引用ceph-pvcKubernetes 调度到某节点后由 kubelet 使用 RBD 内核模块将 RBD 镜像映射为/dev/rbd0并挂载到容器/mnt/rbd。挂载输出中type ext4证实了RBD 设备默认使用 ext4 文件系统的行为stripe1024是 RBD 条带化参数。同样验证 RBD 是否可用也可以参考仓库 rbd-provisioner 文档 的 busybox 用例kubectl exec -it ceph-pod1 mount | grep rbd与df | grep rbd。第十步查看 Ceph 集群日志可以通过kubectl logs [-f]命令访问 OSD 和 Monitor 日志。Monitors 有多个日志记录流每个流都可以从ceph-monPod 中的容器访问。在ceph-monPod 中有 3 个容器运行容器名对应物理机日志说明ceph-monceph-mon.hostname.logMON 守护进程本身的运行日志cluster-audit-log-tailerceph.audit.log审计日志谁在何时执行了哪些命令cluster-log-tailerceph.log或ceph -w集群整体运行日志/告警流每个容器都可以通过--container或-c选项访问。例如要访问集群日志cluster-log-tailer可以运行$ kubectl -n ceph logs ceph-mon-cppdk -c cluster-log-tailer常见问题与排错动态供给失败executable file not found in $PATH仓库 使用 Ceph 做持久化存储 记录了最常见的失败场景如果 kube-controller-manager 主机上没有安装ceph-common创建 PVC 时会报Failed to provision volume with StorageClass ceph-web: failed to create rbd image: executable file not found in $PATH查看kube-controller-manager日志如journalctl -xe -u kube-controller-manager可以看到rbd_util.go中failed to create rbd image与rbd.go中rbd: create volume failed的错误。原因是创建 RBD 镜像依赖宿主机上的rbd命令行工具而 kube-controller-manager 所在节点未安装ceph-common软件包或在 kube-controller-manager 以容器方式运行时镜像内未打包 ceph-common。解决办法是在相关节点安装 ceph 客户端yum install -y ceph-commonkube-controller-manager 容器化场景的替代方案在 rbd-provisioner 文档 中可以看到部分用户使用 kubeadm 部署集群或将 kube-controller-manager 以容器方式运行PV/PVC 使用没问题但 dynamic provisioning 会报同样的failed to create rbd image错误——因为 gcr.io 提供的 kube-controller-manager 容器镜像未打包 ceph-common缺少rbd命令。Kubernetes 官方通过 external-storage 项目中的 External Provisioner 解决此类问题部署 rbd-provisioner 后将 StorageClass 的provisioner从kubernetes.io/rbd改为ceph.com/rbdRBD 的创建请求便由 rbd-provisioner 处理不再依赖 controller-manager 主机上的rbd二进制。这与 ceph-helm 部署出的ceph-rbdStorageClass 使用的ceph.com/rbdprovisioner 完全一致。从仓库 使用 Ceph 做持久化存储 中的 StorageClass 示例manifests/mariadb-cluster/ceph-class.yaml可以看到完整的参数组合apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-web provisioner: kubernetes.io/rbd parameters: monitors: 172.28.7.98,172.28.7.99,172.28.7.100 adminId: admin adminSecretName: ceph-secret adminSecretNamespace: galera pool: rbd #此处默认是rbd池生产上建议自己创建存储池隔离 userId: admin userSecretName: ceph-secret关键参数monitors为 Ceph Monitor 地址列表逗号分隔adminId/adminSecretName/adminSecretNamespace为用于创建镜像的管理员凭据pool为存储池默认rbd生产上建议自建存储池隔离userId/userSecretName为挂载时使用的业务用户凭据。当使用 ceph-helm 托管部署时monitors通常填写ceph-mon.ceph.svc.cluster.local或各 MON 节点的实际地址pool、user_id、user_secret_name则来自ceph-overrides.yaml的storageclass段。内核与 CRUSH 可调项不匹配若节点内核版本低于 4.5无法支持 Luminous 所需的 CRUSH_TUNABLES 5Jewel时需在 Ceph 侧执行ceph osd crush tunables hammer否则 RBD 映射或读写可能出现异常见第九步的重要提示。RBD 挂载依赖 DNSRBD 由 kubelet 在宿主机上通过内核模块映射宿主机必须能解析ceph-mon.ceph.svc.cluster.localkube-dns 管理的集群内域名否则 kubelet 无法定位 Monitor。必要时在宿主机 /etc/hosts 或 DNS 中补充对应解析或让 StorageClass 的monitors直接使用可达的 IP 地址。小结从本文的完整流程可以看到一条清晰的链路Helm 初始化 → ceph-helm 构建 Chart → overrides 声明网络/OSD/StorageClass → 打标签控制调度 → helm install 一键拉起全部 Ceph 组件 → 创建池与客户端 keyring → PVC 动态申请 RBD → Pod 挂载使用。部署后你可以用kubectl -n ceph exec -ti ceph-mon-pod -c ceph-mon -- ceph -s持续观测集群健康、MON 仲裁与 OSD 状态通过pvc-ceph-client-key类型的 secret 与ceph-rbdStorageClass让集群内任意 namespace 的应用动态申请 RBD 块存储按需为节点补打ceph-rgwenabled、ceph-mdsenabled标签进一步启用对象存储RGW与 CephFS 文件系统能力。更进一步将 Ceph 作为 Kubernetes 持久化后端的完整实践可参考仓库中的 使用 Ceph 做持久化存储创建 MySQL 集群外部已有 Ceph kubernetes.io/rbd动态供给 Galera 多主 MySQL 的完整 YAML其配置清单在 manifests/mariadb-cluster 目录下含 ceph-class.yaml、ceph-secret.yaml 等而针对 controller-manager 容器化环境的替代供给方式可阅读 rbd-provisioner 文档。无论采用哪种部署形态本文的关键结论都适用RBD 是 Kubernetes 生态中成熟、自带供给能力的块存储后端前提是正确安装 ceph 客户端、准备匹配的内核与 DNS 环境并妥善管理好kubernetes.io/rbd类型的认证 Secret。赞分享教程云原生容器编排【免费下载链接】kubernetes-handbookKubernetes 架构与生态从云原生到 AI 原生基础设施的构建指南项目地址https://gitcode.com/gh_mirrors/ku/kubernetes-handbook点击查看免费下载相关推荐Kubernetes Handbook使用 rbd-provisioner 为 Ceph RBD 提供动态持久化存储Dynamic Provisioning实战指南Kubernetes Handbook使用 rbd provisioner 为 Ceph RBD 提供动态持久化存储Dynamic Provisioning教程云原生容器编排Rook Helm Charts 部署指南用 Helm 一键编排 Kubernetes 上的 Ceph 存储Rook Helm Charts 部署指南用 Helm 一键编排 Kubernetes 上的 Ceph 存储 导读 Rook 官方为 Ceph 存储配置提供了云原生存储容器编排运维Rook Ceph Cluster Helm Chart 实战指南用 Helm 编排与配置 Ceph 存储集群Rook Ceph Cluster Helm Chart 实战指南用 Helm 编排与配置 Ceph 存储集群 本指南系统讲解 Rook 官方提供的 rook云原生存储容器编排运维创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考