Knative 和 Rook 在 minikube 上实现 Bucket 通知！

2021 年 5 月 15 日 ylifshit

为什么？ ¶

Bucket 通知是一种强大的集成功能，具有一些有趣的应用，但就像任何需要设置的集成一样，它有很多需要设置的活动部件。我认为尝试从头开始创建一个这样的设置，作为一个在我的笔记本电脑上运行的小型演示，可能是找出该过程中痛点的最佳方法。

在此设置中，Ceph 连同 RADOS Gateway (RGW) 将在 minikube Kubernetes 集群内运行，使用 Rook。Knative 将在同一个集群中运行。> 所有内容均使用以下内容进行测试：> * Fedora32 > * minikube: v1.13.0 > * knative: v0.22 > * rook: v1.6.0

> 关于本指南的重要说明：Kubernetes 中的所有内容都是动态的（并非说是一个“不断变化的目标”……），这意味着以下命令可能在编写本指南后不久就会过时或错误 :-) 因此，在将其复制并粘贴到您的 shell 中之前，请检查官方文档（通常在命令之前链接）。

活动部件 ¶

让我们看看尽管需要做很多事情，但设置是否简单。

minikube ¶

minikube 并不是运行 Ceph、rook 等的显而易见的选择。但是，至少根据这篇博文

"在开始 OCP 4 部署之前，请注意，它需要 6 个 EC2 实例和 6 个 EIP。因此，请向 AWS 支持发送请求，并为您的帐户增加 EIP 的限制。".

这排除了“在我的笔记本电脑上运行的小型演示”的方法 - 因此，我选择了 minikube 路径

首先我们安装 minikube（请查看此页面）

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-latest.x86_64.rpm
sudo rpm -ivh minikube-latest.x86_64.rpm

现在我们可以运行 minikube 并验证它是否正常（请注意，我们假设我们已经安装了：KVM、virsh 等）

minikube start --cpus 8

> 请注意，您需要 8 个 CPU，因为有很多东西在运行，并且有些东西对可用的 CPU 有限制。

如果这工作正常，我们可以检查 minikube 是否有可以由 Ceph 使用的额外磁盘

minikube ssh lsblk

可能不会，所以我们需要添加它

UUID=$(uuidgen)
IMAGE=/var/lib/libvirt/images/minikube-$UUID
sudo qemu-img create -f raw $IMAGE 30G
sudo virsh attach-disk minikube $IMAGE vdb --cache none --persistent

现在我们应该重新启动 minikube

minikube stop
minikube start

并查看是否添加了磁盘

minikube ssh lsblk

最后，我们应该使用 minikube 内部运行的 docker 守护程序（我更喜欢在我的主机上使用 podman :-)

eval $(minikube docker-env)

Knative ¶

按照此处的说明，我们首先安装 Knaive “serving”

kubectl apply -f https://github.com/knative/serving/releases/download/v0.22.0/serving-crds.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/v0.22.0/serving-core.yaml

然后 Kourier

kubectl apply -f https://github.com/knative/net-kourier/releases/download/v0.22.0/kourier.yaml

然后配置 knative “serving” 以使用 Kourier

kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress.class":"kourier.ingress.networking.knative.dev"}}'

最后 Knative “eventing”

kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/eventing-crds.yaml
kubectl apply -f https://github.com/knative/eventing/releases/download/v0.22.0/eventing-core.yaml

“Ceph Source” 是使用 “ko” 工具并根据这些说明构建和部署的

git clone https://github.com/knative-sandbox/eventing-ceph.git
cd eventing-ceph/
ko apply -f config

Rook ¶

通常，Ceph 需要多个节点，因此在 rook ceph 文档和 rook 对象存储文档中，我们应该查找允许单个节点的“测试”设置

git clone --single-branch --branch v1.6.0 https://github.com/rook/rook.git
cd rook/cluster/examples/kubernetes/ceph
kubectl apply -f crds.yaml -f common.yaml -f operator.yaml
kubectl apply -f cluster-test.yaml
kubectl apply -f object-test.yaml

下一步将是安装“toolbox”，这是我们需要获取拥有我们创建的 bucket 的用户的凭据

kubectl apply -f toolbox.yaml

就像一个 YAML 文件一样简单 ¶

因此，设置系统并不太糟糕，现在让我们看看具体的配置是否像编辑 YAML 文件一样简单。

Knative 中的 Ceph Source ¶

设置 Knative 后，我们可以创建“ceph source”服务，稍后将配置 RGW 中的通知端点

kubectl apply -f samples/ceph-source-svc.yaml

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

kubectl apply -f samples/event-display.yaml

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

最重要的是，我们应该创建“ceph source”资源（CRD）

kubectl apply -f samples/ceph-source.yaml

> 如上所述，这些说明仅在 minikube 上进行了测试，可能不适用于其他 Kubernetes 发行版（例如 OpenShift）。

Rook 中的 OBC ¶

要创建 bucket，请遵循此文档。首先，必须创建存储类

kubectl apply -f storageclass-bucket-delete.yaml

然后是对象 bucket 声明 (OBC)。但是，修改了 OBC YAML 样本，以包含显式的 bucket 名称，以便 object-bucket-claim-delete.yaml 是

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: ceph-delete-bucket
spec:
  bucketName: fish
  storageClassName: rook-ceph-delete-bucket

进行此修改的主要原因是，当使用 AWS CLI 设置 bucket 通知时，我们必须知道用户的实际 bucket 名称，因此显式设置它会更容易。

我们可以使用 toolbox pod 来确保创建了 bucket

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- radosgw-admin bucket list

Bucket 通知 ¶

bucket 通知首先需要一个安装了 AWS CLI 的 pod。请注意，s3cmd 对我们来说是不够的，因为创建通知的“topic”是 SNS API 的一部分，而不是 S3。此外，此 pod 将具有我们支持的一些扩展。

此 pod 的 YAML 将是

apiVersion: v1
kind: Pod 
metadata:
  name: aws-cli-runner
  namespace: rook-ceph
spec:
  containers:
    - name: aws-cli
      image: quay.io/ylifshit/aws-cli

现在我们需要使用上一节中的 toolbox 来查看哪个用户拥有由 OBC 创建的 bucket。获取用户列表

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- radosgw-admin user list
[
    "rook-ceph-internal-s3-user-checker-f234b0db-612f-48ec-870f-40a359f189b0",
    "dashboard-admin",
    "ceph-user-902n5sk8"
]

并获取 ceph-user-902n5sk8 用户的凭据

kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- radosgw-admin user info --uid ceph-user-902n5sk8

在 AWS CLI pod 启动并运行后，我们可以使用它来使用 AWS CLI

kubectl -n rook-ceph exec -it aws-cli-runner -- bash

首先，我们应该根据访问密钥和密钥配置 AWS CLI。运行 aws configure 并确保将 Default region name 设置为 my-store。

在创建 topic 之前，我们需要执行以下配置（实际上是为了解决 bug）

aws configure set default.sns.signature_version s3

现在我们可以创建一个 topic，该 topic 指向 Knative “ceph source” 服务

 aws --endpoint-url http://rook-ceph-rgw-my-store:80 sns create-topic --name=fishtopic --attributes='{"push-endpoint": "http://my-ceph-source-svc.default.svc.cluster.local"}'

和一个 notification，该 notification 将 topic 与 bucket 绑定

aws --endpoint-url http://rook-ceph-rgw-my-store:80 s3api put-bucket-notification-configuration --bucket fish --notification-configuration='{"TopicConfigurations": [{"Id": "notif1", "TopicArn": "arn:aws:sns:default::fishtopic", "Events": []}]}'

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

echo "hello world" &gt; hello.txt
aws --endpoint-url http://rook-ceph-rgw-my-store:80 s3 cp hello.txt s3://fish

我们现在应该在“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 knative-eventing-source-name=my-ceph-source -c receive-adapter --tail=100

并使用 RGW

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

最后的拼图 ¶

配置确实很简单，直到我们遇到“bucket 通知”部分。在那里我们必须

手动调用带有 JSON 编码参数的 AWS CLI 命令
弄清楚用户的凭据
获取 bucket 名称（如果我们使用 OBC 中的生成 bucket 名称）
更不用说我们需要另一个“toolbox” pod 来运行 AWS CLI 命令……

来救援，我们有一个 bucket 通知 CRD 设计 - 一旦实现代码，它将是最后的拼图！