¿Que es MinIO?
MinIO es un servidor de almacenamiento en la nube compatible con Amazon S3, lanzado bajo la licencia Apache v2. Como un almacén de objetos, MinIO puede almacenar datos no estructurados como fotos, videos, archivos de registro, copias de seguridad e imágenes de contenedores.
En esta entrada veremos como instalar MinIO en modo, en futuras entradas veremos implementar MinIO en forma distribuida.
Para empezar la instalación de MinIO bajo Kubernetes primero le tenemos que proporcionar almacenamiento persistente
Antes de nada creamos el namespace en donde irá Minio
kubectl create namespace minio
Creación Storage Class
Storage Class proporciona una forma para que los administradores describan las «clases» de almacenamiento que ofrecen. Las diferentes clases pueden correlacionarse con niveles de calidad de servicio, políticas de respaldo o políticas arbitrarias determinadas por los administradores del clúster.
cat storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: scthindefault
annotations:
storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/vsphere-volume
parameters:
diskformat: thin
datastore: vsanDatastore #En caso de no tener VSCAN agregamos el nombre del datastore
Creamos la storageclass
kubectl create -f storageclass.yaml -n minio
Una vez creado la Storage Class es necesario crear el Persistent Vol Claim,
cat minio-pv-claim.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: minio-pv-claim
annotations:
volume.beta.kubernetes.io/storage-class: scthindefault
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
Creamos la storageclas el Persistent Vol Claim,
kubectl create -f minio-pv-claim.yaml -n minio
Nos descargamos los yaml para la instalación de minio
git clone https://github.com/kubernetes/examples/tree/master/staging/storage/minio
Una vez descargado tenemos que modificar algunos parámetros de minio-standalone-deployment.yaml tales como las KEY y asegurarnos que apunta correctamente al PVC creado anteriormente.
apiVersion: apps/v1
kind: Deployment
metadata:
# This name uniquely identifies the Deployment
name: minio
spec:
selector:
matchLabels:
app: minio # has to match .spec.template.metadata.labels
strategy:
# Specifies the strategy used to replace old Pods by new ones
# Refer: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy
type: Recreate
template:
metadata:
labels:
# This label is used as a selector in Service definition
app: minio
spec:
# Volumes used by this deployment
volumes:
- name: data
# This volume is based on PVC
persistentVolumeClaim:
# Name of the PVC created earlier
claimName: minio-pv-claim
containers:
- name: minio
# Volume mounts for this container
volumeMounts:
# Volume 'data' is mounted to path '/data'
- name: data
mountPath: "/data"
# Pulls the lastest Minio image from Docker Hub
image: minio/minio:RELEASE.2019-10-12T01-39-57Z
args:
- server
- /data
env:
# MinIO access key and secret key
- name: MINIO_ACCESS_KEY
value: "redorbita"
- name: MINIO_SECRET_KEY
value: "PassRedoOrita1234567."
ports:
- containerPort: 9000
# Readiness probe detects situations when MinIO server instance
# is not ready to accept traffic. Kubernetes doesn't forward
# traffic to the pod while readiness checks fail.
readinessProbe:
httpGet:
path: /minio/health/ready
port: 9000
initialDelaySeconds: 120
periodSeconds: 20
# Liveness probe detects situations where MinIO server instance
# is not working properly and needs restart. Kubernetes automatically
# restarts the pods if liveness checks fail.
livenessProbe:
httpGet:
path: /minio/health/live
port: 9000
initialDelaySeconds: 120
periodSeconds: 20
Tras realizar dichas modificaciones procedemos a despegarlos
Kubectl create -f minio-standalone-deployment.yaml -n minio
Kubectl create -f minio-standalone-service.yaml -n minio
:wq!