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
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-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这种块存储性能更好的存储