minio作为K8S后端存储

docker部署minio mkdir -p /minio/data docker run -d \ -p 9000:9000 \ -p 9001:9001 \ --name minio \ -v /minio/data:/data \ -e "MINIO_ROOT_USER=jbk" \ -e "MINIO_ROOT_PASSWORD=jbjbjb123" \ quay.io/minio/minio server /data --console-address ":9001" 直接安装csi-s3 artifacthub.io/packages/helm/k8s-csi-s3/csi-s3 helm repo add kubeblocks apecloud.github.io/helm-charts helm pull kubeblocks/csi-s3 kubectl create ns csi-s3 helm install -n csi-s3 csi-s3 csi-s3-0.31.4.tgz \ --set secret.accessKey="tw8iFXwkBlrUmNKLp6ei" \ --set secret.secretKey="GBQW7xObmwcTDo4Yz5b2OH4u73i6sEPGBhnvxvSl" \ --set secret.endpoint="http://172.16.8.104:9000" #你的minio地址 安装完成如下

简单测试 cat <<EOF > demon.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: s3-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 5Gi storageClassName: csi-s3 --- apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - name: nginx image: nginx volumeMounts: - mountPath: /xx/xxx name: s3-storage volumes: - name: s3-storage persistentVolumeClaim: claimName: s3-pvc EOF 部署pods基本都没有什么问题，比如kafka集群，redis集群都OK ,不再过多演示

将 S3 作为 Kubernetes 的后端存储，主要依赖于 CSI（Container Storage Interface）驱动的实现。csi-s3 驱动负责将 S3 对象存储与 Kubernetes 的存储管理系统集成。以下是其实现原理的简要概述： 实现原理 CSI 驱动架构：

CSI 是 Kubernetes 的标准接口，允许不同的存储系统（如 S3）与 Kubernetes 集成。csi-s3 驱动实现了 CSI 的 API，使得 Kubernetes 能够通过标准化的方式与 S3 进行交互。 StorageClass 和 PVC：

用户首先创建一个 StorageClass，指定使用 csi-s3 驱动。然后，用户创建一个 PersistentVolumeClaim（PVC），请求特定的存储容量。Kubernetes 会根据 PVC 的请求，调用 CSI 驱动来动态创建或绑定相应的存储资源。 卷的创建与管理：

当 PVC 被创建时，csi-s3 驱动会处理卷的创建请求。它会与 S3 API 交互，创建一个新的 S3 存储桶或在现有存储桶中创建一个对象。例如，驱动可能会创建一个特定的文件夹或对象，代表 PVC 的存储。 数据读写操作：

当 Pod 需要访问存储时，csi-s3 驱动会将读写请求转换为 S3 API 调用。例如，写入数据时，驱动会将数据上传到 S3 存储桶；读取数据时，驱动会从 S3 存储桶下载数据。 数据一致性和性能：

S3 是基于对象的存储，通常采用最终一致性模型。csi-s3 驱动需要处理数据一致性的问题，确保应用能够正确处理数据的读取和写入。 对于性能，S3 的延迟相对较高，因此不适合所有类型的工作负载，尤其是需要低延迟和高 IO 性能的数据库应用。 卷的删除与回收：

当 PVC 被删除时，csi-s3 驱动会处理卷的删除请求，可能会删除相应的 S3 对象或存储桶，具体取决于 PersistentVolumeReclaimPolicy 的配置（如 Retain、Delete 等）。 关键组件

CSI 适配器：

csi-s3 驱动实现了 CSI 适配器，处理 Kubernetes 发送的存储请求。

S3 API：

驱动使用 AWS S3 API 或兼容 S3 的 API 与对象存储进行交互。

Kubernetes API：

驱动与 Kubernetes API 交互，处理 PVC、PV 和 StorageClass 的生命周期管理。

网络交互 数据写入：

当一个 Pod 需要将数据写入 S3 时，csi-s3 驱动会通过网络向 S3 API 发起 HTTP(S) 请求，将数据上传到指定的 S3 存储桶。这意味着数据需要经过网络传输，从 Pod 的容器到 S3 存储服务。 数据读取：

类似地，当 Pod 需要读取数据时，csi-s3 驱动会通过网络向 S3 API 发起请求，下载所需的数据。这同样需要网络连接。 网络延迟与性能 延迟：由于数据需要通过网络传输，读写操作的延迟通常会比直接使用本地或块存储要高。这对于需要快速响应的应用（如数据库）可能会影响性能。

带宽：网络带宽也会影响数据传输的速度，尤其是在处理大量数据时。

考虑因素 网络可靠性：确保网络连接的可靠性，以避免在读写操作时出现中断或失败。 安全性：使用 HTTPS 加密数据传输，以保护敏感数据在传输过程中的安全。 数据一致性：由于 S3 是基于对象的存储，其一致性模型为最终一致性，需考虑应用如何处理这种一致性。 总结来说，使用 S3 作为 Kubernetes 的后端存储时，所有的数据读写操作都依赖于网络，这对性能和应用设计都有一定影响。 - 注意事项 权限管理：

确保 Kubernetes 集群有足够的权限访问 S3 存储。这通常通过 IAM 角色或 S3 存储桶策略来实现。

性能考虑：

对象存储的性能与块存储不同，适合存储大量非结构化数据，但可能不适合需要高性能的应用。

数据安全性：

考虑数据在传输和存储过程中的安全性，可能需要启用加密和访问控制。

通过以上机制，csi-s3 驱动能够将 S3 对象存储无缝集成到 Kubernetes 中，为应用提供灵活的持久化存储解决方案。

关键点

没有真正的挂载：与传统的块存储不同，S3 是对象存储，实际上并没有将 S3 存储“挂载”到 Pods 上。相反，Pods 通过 csi-s3 驱动与 S3 API 进行交互。

通过 CSI 驱动进行读写：所有的读写操作都通过 csi-s3 驱动进行，这个驱动负责将 Pod 中的操作转换为对 S3 存储桶的 API 调用。

文件系统接口：尽管 Pods 可以使用类似于文件系统的接口（如 /mnt/s3），但底层的实现是通过网络请求与 S3 进行交互，而不是直接访问存储块。

性能考虑：由于 S3 是对象存储，性能和延迟可能会影响应用的表现，特别是对于高 IO 的工作负载

数据一致性：S3 的最终一致性模型可能会影响应用的行为，特别是在并发读写的情况下

因此，虽然在 Kubernetes 中看起来像是将 S3 存储挂载到 Pods，但实际上是通过 CSI 驱动与 S3 API 进行交互的过程。这种方式使得 S3 的对象存储特性能够在 Kubernetes 环境中使用。

个人觉得如果再测试环境中还是比nfs之类的网络文件存储好使，是真正live环境还是推荐使用ceph这种块存储性能更好的存储