Rook 中的 Bucket 通知 - 第二部分

2022 年 3 月 30 日 ylifshit

为什么？ ¶

上次我们看到了如何在 minikube 上与 Knative 结合使用 bucket 通知。大部分过程“就像 YAML 一样简单”——大部分，但并非全部...

为了设置解决方案的 bucket 通知部分，需要一些手动步骤。但是，如承诺的那样，Rook1.8 中的一组新的 CR 来拯救我们了！

现在整个过程都可以只使用 YAML 来完成。

“活动部件” ¶

我们将使用与上一篇帖子中相同的基础设施组件（有一些改进）：minikube、Knative 和 Rook

minikube ¶

在使用 minikube 1.25 时，无需手动附加 Rook 所需的额外磁盘（应在这种情况下使用 kvm2 驱动程序）。因此，我们将运行

minikube start --driver=kvm2 --cpus=8 --extra-disks=1

备注
有关 Rook 与 minikube 的更多详细信息请在此处查看
Knative 需要 k8s v1.21，因此，如果使用旧版本，则应将 --kubernetes-version=v1.21.0 添加到上述命令

Knative ¶

让我们使用最新的 Knative 1.2 运算符来安装 eventing 和 serving 部分，如此处所述

安装 Knative 运算符

kubectl apply -f https://github.com/knative/operator/releases/download/knative-v1.2.0/operator.yaml

然后安装“serving”组件

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: knative-serving
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
EOF

网络层（使用 Kourier）；

cat << EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingress:
    kourier:
      enabled: true
  config:
    network:
      ingress-class: "kourier.ingress.networking.knative.dev"
EOF

“Ceph Source”现在作为 Knative 的一部分打包（太棒了！），因此无需从源代码安装它。我们将使用“Ceph Source”安装“eventing”组件

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: knative-eventing
---
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  source:
    ceph:
      enabled: true
EOF

Rook ¶

部署 Rook 运算符（也可以查看快速入门指南）

kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/crds.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/common.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/operator.yaml

现在是“测试”（单节点）Ceph 集群

kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/cluster-test.yaml

并确保 OSD 和 MON 正在运行

kubectl -n rook-ceph get pod

最后，是“测试”（单节点）对象存储

kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/object-test.yaml

真正像 YAML 一样简单 ¶

让我们从 YAML 设置一切

Knative 中的 Ceph Source ¶

创建 Ceph Source CR 和服务（这将用作 bucket 通知主题的端点）

kubectl apply -f https://raw.githubusercontent.com/knative-sandbox/eventing-ceph/release-1.2/samples/ceph-source.yaml

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: my-ceph-source-svc
spec:
  selector:
    eventing.knative.dev/sourceName: my-ceph-source
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8888
EOF

事件的接收器（sink）将是一个通用的事件显示 pod

kubectl apply -f https://raw.githubusercontent.com/knative-sandbox/eventing-ceph/release-1.2/samples/event-display.yaml

请注意，“event-display”pod 将启动但会因没有要处理的事件而终止。

Rook 中的对象 Bucket Claim (OBC) ¶

基于 OBC 配置文档和通知配置文档。让我们创建一个存储类，并创建一个预配置了通知的 bucket

kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/storageclass-bucket-delete.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/object-bucket-claim-notification.yaml

Bucket 通知 ¶

现在我们应该创建 bucket 通知主题，指向我们在 Knative 中配置的 Ceph Source 服务（基于此示例）

cat << EOF | kubectl apply -f -
apiVersion: ceph.rook.io/v1
kind: CephBucketTopic
metadata:
  name: my-topic
  # the topic should be created in the app namespace
spec:
  objectStoreName: my-store
  objectStoreNamespace: rook-ceph
  persistent: false
  endpoint:
    http:
      uri: http://my-ceph-source-svc.default.svc.cluster.local
EOF

以及将 OBC 绑定到主题的通知（基于此示例）

cat << EOF | kubectl apply -f -
apiVersion: ceph.rook.io/v1
kind: CephBucketNotification
metadata:
  name: my-notification
  # the notification should be created in the app namespace
spec:
  topic: my-topic
  events:
    - s3:ObjectCreated:*
EOF

让我们尝试一下 ¶

外部访问 ¶

默认情况下，Rook 将对象存储作为服务暴露给集群中的其他 pod，但我们希望从节点上的 aws CLI 客户端访问它。为此，我们将添加一个新的 NodePort 服务并将其附加到对象存储

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:
  name: rook-ceph-rgw-my-store-external
  namespace: rook-ceph
  labels:
    app: rook-ceph-rgw
    rook_cluster: rook-ceph
    rook_object_store: my-store
spec:
  ports:
  - name: rgw
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: rook-ceph-rgw
    rook_cluster: rook-ceph
    rook_object_store: my-store
  sessionAffinity: None
  type: NodePort
EOF

好吧，实际上我们不想从节点（minikube VM）访问它，我们想从托管该 VM 的机器访问它。Minikube 会在这里帮助我们，并提供我们应该使用的实际主机名

export AWS_URL=$(minikube service --url rook-ceph-rgw-my-store-external -n rook-ceph)

用户凭据 ¶

我们获取用户凭据并将其放入 aws CLI 工具使用的环境变量中

export AWS_ACCESS_KEY_ID=$(kubectl -n default get secret ceph-notification-bucket -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 --decode)
export AWS_SECRET_ACCESS_KEY=$(kubectl -n default get secret ceph-notification-bucket -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 --decode)

然后获取生成的 bucket 名称

export BUCKET_NAME=$(kubectl get objectbucketclaim ceph-notification-bucket -o jsonpath='{.spec.bucketName}')

按下按钮 ¶

最后，我们可以创建一个文件，并将其上传到 Ceph。

echo "hello world" > hello.txt
aws --endpoint-url "$AWS_URL" s3 cp hello.txt s3://"$BUCKET_NAME"

我们现在应该在“event-display”pod 的日志中看到这些事件

kubectl logs -l serving.knative.dev/service=event-display -c display-container --tail=100

此时，“event-display”pod 应该被创建并存在，只要从 RGW 发送通知。

调试 Bucket 通知 ¶

要调试 Ceph Source，请使用

kubectl logs -l eventing.knative.dev/sourceName=my-ceph-source --tail 100

使用 RGW

kubectl logs -l app=rook-ceph-rgw -n rook-ceph --tail 100

以及 Rook 运算符

kubectl logs -l app=rook-ceph-operator -n rook-ceph --tail 100

Ceph 工具箱 pod 也可能对调试有用，因为它包含 radosgw-admin 和其他工具

kubectl apply -f https://raw.githubusercontent.com/rook/rook/release-1.8/deploy/examples/toolbox.yaml

接下来是什么？ ¶

看起来我们完成了？好吧，并非真的。

有几种替代我们上面选择的技术，值得探索。所以，敬请期待！

microshift ¶

microshift 是 minikube 的一个小型替代方案（基于 Openshift）。请注意，microshift 直接在主机上运行，并且需要一个额外的物理磁盘（例如，连接 USB 驱动器）。另请注意，由于 microshift 基于 Openshift 而不是 vanilla k8s，因此安装其他组件的步骤有所不同。

CRC ¶

CodeReady Containers 是另一个基于 VM 的小型 Openshift。

CloudEvents 端点 ¶

在下一个 Rook 版本中，将有可能直接将通知作为 CloudEvents 发送到 Knative 频道，而无需“Ceph Source”适配器

KEDA ¶

KEDA 是另一个无服务器框架。它轻量级（不包含电池），非常适合边缘部署。KEDA 具有“缩放器”，可以轮询外部队列系统并生成服务器less 函数来提取事件。