ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Rook Ceph 桶通知 CRD 实战:CephBucketTopic 与 CephBucketNotification 配置指南

Rook Ceph 桶通知 CRD 实战:CephBucketTopic 与 CephBucketNotification 配置指南 云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载导读本文围绕 Rook 提供的 Ceph 对象存储桶通知Bucket NotificationsCRD 展开系统讲解如何通过CephBucketTopic与CephBucketNotification两个自定义资源以声明式方式为 RGW 配置推送通知端点HTTP / AMQP / Kafka与事件订阅规则替代手工向 RGW 发送 HTTP 请求的繁琐流程。读完本文你将掌握 topic 与 notification 的完整字段语义、URI 格式规范、OBC/BAR 标签绑定方式以及 Rook Operator 底层的 SNS/S3 实现原理可直接在 Kubernetes 集群中落地对象写入即触发回调的自动化场景。一、背景为什么需要桶通知 CRDCeph 从 Nautilus 版本起支持桶通知bucket notifications特性当桶上发生新事件如对象创建、删除时RGW 会向指定端点推送消息。按照 Ceph 官方文档通知的目标端点既可以是 HTTP(S) Webhook也可以是 AMQP 或 Kafka 消息代理。在原生 Ceph 环境下配置通知需要向 RGW 发送 HTTP 请求来创建/删除指向端点的 topic或基于 topic 创建/删除桶通知。这种方式依赖外部工具或脚本难以在 Kubernetes 声明式工作流中复用。Rook 的解决方案是将这一过程抽象为两个 CRD由 Operator 负责与 RGW 交互CephBucketTopic描述一个通知主题topic包含端点信息与持久化、鉴权等可选配置CephBucketNotification描述一个具体桶的通知规则绑定某个 topic并可配置事件类型与过滤条件。用户只需提交 CR 定义Rook Operator 便会自动完成 topic 与 notification 的创建、更新和删除同时支持通过 OBC/BAR 标签为动态供应的桶绑定通知。设计文档见 design/ceph/object/ceph-bucket-notification-crd.md完整 API 类型定义位于 pkg/apis/ceph.rook.io/v1/types.go。二、CephBucketTopic定义通知端点2.1 字段总览CephBucketTopic的 CR 结构如下字段注释来自设计文档原文apiVersion: ceph.rook.io/v1 kind: CephBucketTopic metadata: name: # topic 名称 namespace: # topic 所属命名空间 spec: objectStoreName: my-store # (必填) 关联的 CephObjectStore 名称 objectStoreNamespace: rook-ceph # (必填) 关联的 CephObjectStore 命名空间 opaqueData: myemail.com # (可选) 随每个事件发送的不透明数据 persistent: false # (可选) 通知是否持久化默认 false endpoint: # (必填) 必须且只能包含下列选项之一 http: uri: http://my-notification-endpoint:8080 # (必填) 推送通知的端点 URI disableVerifySSL: false # (可选) 客户端是否校验服务器证书默认 false sendCloudEvents: false # (可选) 是否以 CloudEvents 头格式发送默认 false # amqp: # uri: amqp://my-rabbitmq-service:5672/vhost1 # (必填) # disableVerifySSL: true # ackLevel: broker # (可选) none/routable/broker默认 broker # exchange: my-exchange # (必填) 必须存在且能按主题路由消息 # kafka: # uri: kafka://my-kafka-service:9092 # (必填) # disableVerifySSL: true # ackLevel: broker # (可选) none/broker默认 broker # useSSL: false # (可选) 是否使用 SSL 连接 broker默认 false # mechanism: PLAIN # (可选) PLAIN/SCRAM-SHA-512/SCRAM-SHA-256/GSSAPI/OAUTHBEARER默认 PLAIN注意设计文档中的示例字段如opaqueData、persistent、endpoint在最终实现中有所演进——当前仓库要求 topic 必须显式指定objectStoreName与objectStoreNamespaceAPI 校验MinLength1同时 Kafka 端点增加了mechanism与userSecretRef/passwordSecretRef两个认证相关字段。可在 deploy/examples/bucket-topic.yaml 查看可直接运行的完整示例。2.2 端点的 URI 格式规范不同端点类型的 URI 格式由设计文档明确规定与具体消息服务器相关HTTPhttp[s]://fqdn[:port][/resource]AMQPamqp://[user:password]fqdn[:port][/vhost]也支持amqps://Kafkakafka://[user:password]fqdn[:port]2.3 源码级校验规则Operator 在受理CephBucketTopic时会执行严格的 schema 校验实现在 pkg/apis/ceph.rook.io/v1/topic.goValidateHTTPSpecURI 的 scheme 必须为http或httpsValidateAMQPSpecURI 的 scheme 必须为amqp或amqpsValidateKafkaSpecURI 的 scheme 必须为kafkaValidateTopicSpecendpoint下的 HTTP、AMQP、Kafka 三者必须且只能设置一个同时设置多个会报multiple endpoint specs错误一个都不设置则报missing endpoint spec。2.4 字段取值范围与默认值结合 pkg/apis/ceph.rook.io/v1/types.go 中的 kubebuilder 标记各可选字段的约束如下字段取值/默认值说明spec.persistent默认false是否持久化通知消息spec.endpoint.http.disableVerifySSL默认falseHTTP 端点是否跳过证书校验spec.endpoint.http.sendCloudEvents默认false以 CloudEvents 适配 AWS S3 的头格式发送参考 cloudevents/spec 的 aws-s3 adapterspec.endpoint.amqp.ackLevelnone/broker/routable默认brokerAMQP 确认级别注意历史遗留的拼写错误routeable已被标记弃用仍会被 Operator 自动纠正为routable后发送给 RGWspec.endpoint.amqp.exchange必填必须预先存在且能按主题路由消息spec.endpoint.kafka.ackLevelnone/broker默认brokerKafka 确认级别spec.endpoint.kafka.useSSL默认false是否使用 SSL 与 broker 通信spec.endpoint.kafka.mechanismPLAIN默认/SCRAM-SHA-512/SCRAM-SHA-256/GSSAPI/OAUTHBEARERSASL 认证机制spec.endpoint.kafka.userSecretRef/passwordSecretRef可选引用 Kubernetes Secret 中的用户名/密码Operator 会将其注入 URI 的 basic auth 部分其中 Kafka 的userSecretRef/passwordSecretRef是较新的增强当设置任一引用时provisioner 会从指定 Secret 读取凭据并覆盖 URI 中已有的 basic auth 信息见 pkg/operator/ceph/object/topic/provisioner.go并且在日志中会使用uri.Redacted()避免泄露密码。三、CephBucketNotification定义事件订阅3.1 字段总览CephBucketNotification的 CR 结构如下字段注释来自设计文档原文apiVersion: ceph.rook.io/v1 kind: CephBucketNotification metadata: name: my-notification # notification 名称 namespace: # notification 所属命名空间 spec: topic: my-topic # (必填) 引用的 topic 名称即 topic_arn filter: # (可选) 前缀/后缀/正则过滤默认 {} keyFilters: - name: prefix value: hello - name: suffix value: .png - name: regex value: [a-z]*\\.* events: # (可选) 触发通知的事件列表默认全部 - s3:ObjectCreated:Put - s3:ObjectCreated:Copy3.2 过滤条件filter详解设计文档原始示例中 filter 使用stringMatch结构而当前仓库实现已将其扩展为三类过滤规则见 deploy/examples/bucket-notification.yaml 与 API 定义 types.gokeyFilters按对象 key 过滤name取prefix/suffix/regex三选一metadataFilters按对象元数据如x-amz-meta-color的键值对过滤tagFilters按对象标签tag的键值对过滤。语义说明同一条 notification 内的所有过滤条件必须同时满足才会触发通知逻辑与这一点在示例文件的注释中有明确说明。3.3 事件类型eventsevents列表声明哪些事件会触发通知可选值以 Ceph 官方文档radosgw/s3-notification-compatibility的 Event Types 一节为准常见取值如s3:ObjectCreated:Put、s3:ObjectCreated:Copy等。若省略events则默认对全部事件生效。从源码看pkg/operator/ceph/object/notification/provisioner.goevents为空时 Rook 会显式填充s3:ObjectCreated:*与s3:ObjectRemoved:*两个通配事件——这是 AWS S3 SDK 将 Events 视为必填字段的兼容处理。四、通过 OBC/BAR 标签绑定通知桶通知通常由用户为应用消费而创建因此它应与 OBC/BAR 一样创建在应用所在命名空间。通知与动态供应的桶OBC之间的绑定关系通过**标签labels**传递apiVersion: objectbucket.io/v1alpha1 kind: ObjectBucketClaim metadata: name: ceph-bucket labels: bucket-notification: ignored # 无名称被附加仅用于标识 bucket-notification-name-1: name-1 bucket-notification-name-2: name-2 bucket-notification-foo: foo spec: bucketName: mybucket storageClassName: rook-ceph-delete-bucket标签规则要点标签键以bucket-notification-为前缀前缀之后的部分必须与标签值完全一致如bucket-notification-name-1: name-1否则该标签会被忽略并打印警告标签值必须是已在同一命名空间创建的CephBucketNotification的名称因此通知名称必须满足 Kubernetes 的标签语法字母、数字、-、_、.等绑定由 OBC 标签控制器ReconcileOBCLabels负责它会比对 OBC 标签与桶上已存在的通知自动为新增标签创建通知、为已移除标签删除通知差量同步逻辑见 pkg/operator/ceph/object/notification/obc_label_controller.go。五、Operator 底层实现原理5.1 整体架构与控制器Rook 为桶通知功能注册了两个相互协作的 controller见 pkg/operator/ceph/object/notification/controller.goCephBucketNotification controller监听CephBucketNotification资源将其应用到所有带对应标签的 OBC 所关联的桶上OBC 标签 controller监听ObjectBucketClaim资源按标签驱动的模式同步通知的增删。两个控制器均在ROOK_OBC_WATCH_OPERATOR_NAMESPACE相关开关DisableOBCEnvVar未置为true时启用若通过环境变量禁用了 OBC 功能通知控制器也会被跳过。5.2 Topic 的 SNS 实现Topic 的管理本质上是 AWS SNS API 的封装。Rook 通过 aws-sdk-go-v2客户端凭据来自 RGW 的 admin ops 用户GetAdminOPSUserCredentials若对象存储启用了 TLS会读取其 CA 证书并配置 HTTPS 传输调用snsClient.CreateTopic时将 CR 字段映射为 SNS 主题属性push-endpoint、verify-ssldisableVerifySSL取反、use-ssl、amqp-exchange、amqp-ack-level、kafka-ack-level、mechanism、persistent、OpaqueData等provisioner.go#L141-L210创建成功后RGW 返回的Topic ARN会写入CephBucketTopic.status.ARN作为后续 notification 引用的依据删除 topic 时若 ARN 为空从未成功创建或返回 NotFound则直接忽略。CephBucketTopic的 status 结构Phase、ARN、ObservedGeneration、Secrets定义在 types.goGetProvisioned会校验 ARN 必须属于sns服务且包含资源段未完成 provisioning 的 topic 会导致依赖它的 notification 持续 requeue 等待。5.3 Notification 的 S3 实现Notification 的管理基于 AWS S3 的桶通知配置 API见 pkg/operator/ceph/object/notification/provisioner.go通过 RGW admin ops API 获取桶属主用户的凭据构造 S3Agent将CephBucketNotification.spec转换为PutBucketNotificationConfiguration请求events映射为TopicConfiguration.Eventsfilter.keyFilters映射为 S3 的FilterRulename 为prefix/suffix/regexId使用通知名称TopicArn使用关联 topic 的 ARN删除时调用DeleteBucketNotification精确删除指定 Id 的通知同步时则先GetBucketNotificationConfiguration拉取当前全部通知 Id 做差量。5.4 协调Reconcile流程与重试机制CephBucketNotification的 reconcile 流程controller.go#L139-L234大致为获取 notification 资源若已被删除则直接返回通过topic.GetProvisioned检查关联 topic 是否已创建未就绪则 10 秒后 requeue确认 CephCluster 处于 ready 状态IsReadyToReconcile否则等待 requeue列出同一命名空间下带有bucket-notification-name: name标签的所有 OBC逐个取得其 ObjectBucket 与所属对象存储校验 topic 与桶的 objectStore 名称一致validateObjectStoreName不一致直接报错调用 provisioner 为每个桶创建通知。整个流程中所有依赖未就绪的场景topic 未创建、OBC 未建桶、CephCluster 未 ready、通知删除失败都配置了RequeueAfter: 10s的自动重试保证最终一致性。六、端到端使用流程结合上述内容一个完整的对象写入即推送通知场景可以这样落地第 1 步准备接收端点。部署一个 HTTP 服务如my-notification-endpoint:8080用于接收 RGW 推送的事件。第 2 步创建 Topic。提交 deploy/examples/bucket-topic.yaml确认objectStoreName/objectStoreNamespace指向已有的 CephObjectStore并配置合适的endpoint类型kubectl create -f deploy/examples/bucket-topic.yaml kubectl get cephbuckettopic # shortName 为 cephbt kubectl get cephbuckettopic my-topic -o jsonpath{.status.ARN} # 查看 RGW 返回的 ARN第 3 步创建 Notification。提交 deploy/examples/bucket-notification.yaml通过filter控制生效对象范围、通过events控制触发事件注意spec.topic必须与第 2 步的 topic 名称一致kubectl create -f deploy/examples/bucket-notification.yaml kubectl get cephbucketnotification # shortName 为 cephbn第 4 步绑定 OBC。在应用的 ObjectBucketClaim 上添加bucket-notification-通知名: 通知名标签也可通过kubectl label obc ceph-bucket bucket-notification-my-notificationmy-notification动态添加标签控制器会自动完成通知的创建与同步。第 5 步验证。向桶上传/删除匹配过滤条件的对象观察 HTTP 端点是否收到事件推送同时可通过kubectl get cephbucketnotification -o yaml查看.status.phase是否变为 Ready控制器在成功协调后写入ReadyStatus。七、注意事项与限制命名空间约束CephBucketTopic与CephBucketNotification应创建在应用命名空间与 OBC/BAR 同命名空间而CephObjectStore通常位于 Rook 集群命名空间如rook-cephtopic 通过objectStoreNamespace字段跨命名空间引用它标签语法限制通过 OBC 标签绑定通知时通知名称必须满足 Kubernetes 标签值语法不能包含/、等字符依赖顺序notification 依赖 topic 的 ARN、OBC 依赖桶创建完成、两者都依赖 CephCluster ready任何依赖未就绪都会触发自动重试而非直接失败端点可用性topic 的 AMQP exchange 必须预先在消息代理中创建Kafka/AMQP 的 ackLevel 值域因端点类型而异使用超出枚举范围的值会在 CR 校验阶段被拒绝版本前提桶通知依赖 Ceph Nautilus 及以上的 RGW 通知特性且当前实现要求对象存储具备 admin ops 用户凭据Operator 自动获取用于 SNS/S3 管理操作。八、参考资源设计文档design/ceph/object/ceph-bucket-notification-crd.mdAPI 类型定义pkg/apis/ceph.rook.io/v1/types.goTopic 校验逻辑pkg/apis/ceph.rook.io/v1/topic.goTopic provisionerpkg/operator/ceph/object/topic/provisioner.goNotification provisionerpkg/operator/ceph/object/notification/provisioner.goNotification controllerpkg/operator/ceph/object/notification/controller.goOBC 标签控制器pkg/operator/ceph/object/notification/obc_label_controller.go示例清单deploy/examples/bucket-topic.yaml、deploy/examples/bucket-notification.yaml单元测试参考pkg/operator/ceph/object/topic/controller_test.go、pkg/operator/ceph/object/notification/controller_test.go赞分享云原生存储容器编排运维【免费下载链接】rookStorage Orchestration for Kubernetes项目地址https://gitcode.com/gh_mirrors/roo/rook点击查看免费下载相关推荐Rook Ceph 对象存储桶通知Object Bucket Notifications完全指南CephBucketTopic 与 CephBucketNotification 实战Rook Ceph 对象存储桶通知Object Bucket Notifications完全指南CephBucketTopic 与 CephBucketN云原生存储容器编排运维通过 CephCluster CRD 配置 Ceph 配置选项Rook cephConfig 设计解析与实战指南通过 CephCluster CRD 配置 Ceph 配置选项Rook cephConfig 设计解析与实战指南 导读 本文以 Rook 的设计文档 ceph云原生存储容器编排运维Rook CephObjectStore CRD 完全指南在 Kubernetes 上配置 Ceph 对象存储RGWRook CephObjectStore CRD 完全指南在 Kubernetes 上配置 Ceph 对象存储RGW 本篇指南以 Rook 仓库中的 Ce云原生存储容器编排运维创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表