gitlab使用minio实现分布式存储

1、分布式优势

1.minio分布式介绍

分布式模式下的MinIO使您可以将多个驱动器(甚至在不同的计算机上)合并到一个对象存储服务器中。由于驱动器分布在多个节点上,因此分布式MinIO可以承受多个节点故障,但仍可以确保完整的数据保护。

分布式模式下的MinIO可以帮助您通过单个对象存储部署来设置高可用性存储系统。借助分布式MinIO,无论存储设备在网络中的位置如何,您都可以最佳地使用存储设备。

2.数据保护

分布式MinIO 使用擦除代码提供针对多个节点/驱动器故障和位腐烂的保护。由于分布式MinIO所需的最小磁盘为4(与擦除编码所需的最小磁盘相同),因此在启动分布式MinIO时,擦除代码会自动启动。

3.高可用性

如果托管磁盘的服务器脱机,则独立的MinIO服务器将关闭。相反,只要n / 2个或更多磁盘在线,具有n个磁盘的分布式MinIO设置将使您的数据安全。不过,您至少需要(n / 2 + 1)个法定磁盘来创建新对象。

例如,即使最多有8台服务器处于脱机状态,一个16节点的分布式MinIO设置(每个节点具有16个磁盘)仍可继续提供文件。但是,您至少需要在线9台服务器才能创建新对象。

4.限度

与独立模式下的MinIO一样,分布式MinIO的每个租户限制为最少2个,最多32个服务器。这些服务器上的磁盘数量没有限制。如果您需要多租户设置,则可以轻松启动由协调工具(如Kubernetes,Docker Swarm等)管理的多个MinIO实例。

请注意,使用分布式MinIO,只要遵守限制,就可以处理节点和驱动器的数量。例如,您可以有2个节点,每个节点4个驱动器,4个节点每个4个驱动器,8个节点每个2个驱动器,32个服务器每个64个驱动器,依此类推。

5.一致性保证

MinIO遵循严格的读后写和列表后读 /一致性模型的所有输入输出都在分布式和独立模式操作。

2、使用Helm Chart部署MinIO

前提条件:

1.一个k8s集群

2.具备helm环境

1.部署minio

创建minio需要的pv

#vim  pv1.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-pv1
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
  -  ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /helm/minio/pv1

在此使用的是hostpath,在worker节点创建相应的目录。

image-20191212211059077.png

2.安装minio

#先拉到本地在安装
helm  pull  stable/minio
tar  -zxvf  minio-3.0.4.tgz
helm  install  minio  ./minio

#或者直接安装
helm  install  minio  stable/minio

image-20191212211624813.png

查看pod

image-20191212212110685.png

3.登录访问minio

默认参数:

1576157102(1)_看图王_看图王.png

访问web界面

image-20191212213046502.png

image-20191212213103278.png

access Key和secret Key都是默认的,上图配置中

image-20191212213237181.png

3、gitlab和minio进行关联

kubectl get deploy minio -oyaml    查看关联Key

image-20191212213506646.png

在gitlab的yaml文件中添加

kubectl edit deploy gitlab-gitlab-ce

- name: MINIO_ACCESS_KEY
 valueFrom:
  secretKeyRef:
   key: accesskey
   name: minio
- name: MINIO_SECRET_KEY
 valueFrom:
  secretKeyRef:
   key: secretkey
   name: minio

image-20191212213738745.png

查看到状态正常

image-20191212214106629.png

登录gotlab创建一个文件

image-20191212222659865.png

删除原来的pod

image-20191212223057279.png

gitlab的pod启动时间有点长,等启动完成访问界面可以看到

image-20191212223514760.png

猜你喜欢

转载自blog.51cto.com/14268033/2458435