minio作为K8S后端存储

docker部署minio

mkdir -p /minio/datadocker 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

https://artifacthub.io/packages/helm/k8s-csi-s3/csi-s3
helm repo add kubeblocks https://apecloud.github.io/helm-charts
helm pull kubeblocks/csi-s3
kubectl create ns csi-s3helm 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:- ReadWriteOnceresources:requests:storage: 5GistorageClassName: csi-s3
---
apiVersion: v1
kind: Pod
metadata:name: nginx
spec:containers:- name: nginximage: nginxvolumeMounts:- mountPath: /xx/xxxname: s3-storagevolumes:- name: s3-storagepersistentVolumeClaim: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这种块存储性能更好的存储