欢迎来到即将发布的 MinIO 文档版本! 此页面上的内容正在积极开发中 可能随时更改。 如果找不到您要找的内容,请查看我们的 历史文档。 感谢您的耐心等待。 我们期待您贡献自己强大的力量,帮助更多的中国技术开发者![翻译]

Deploy a MinIO Tenant using the MinIO Plugin

This procedure documents deploying a MinIO Tenant using the MinIO Kubernetes Plugin kubectl minio.

Kubernetes administrators who require more specific customization of Tenants prior to deployment can use this tutorial to create a validated yaml resource file for further modification.

The following procedure creates a MinIO tenant using the kubectl minio plugin. This procedure assumes the MinIO Operator is installed on the Kubernetes cluster. See Deploy MinIO Operator on Kubernetes for complete documentation on deploying the MinIO Operator.

Prerequisites

MinIO Operator v4.1.1

The MinIO Kubernetes plugin requires the MinIO Kubernetes Operator. This procedure assumes the latest stable Operator version v4.1.1.

See Deploy MinIO Operator on Kubernetes for complete documentation on deploying the MinIO Operator.

Kubernetes Version 1.19.0

Starting with v4.0.0, the MinIO Operator and MinIO Kubernetes Plugin require Kubernetes 1.19.0 and later. The Kubernetes infrastructure and the kubectl CLI tool must have the same version of 1.19.0+.

Prior to v4.0.0, the MinIO Operator and Plugin required Kubernetes 1.17.0. You must upgrade your Kubernetes infrastructure to 1.19.0 or later to use the MiNIO Operator or Plugin v4.0.0 or later.

Kubernetes krew

This procedure uses the Kubernetes krew plugin manager for installing the MinIO Kubernetes Plugin.

See the krew installation documentation for specific instructions on installation.

Procedure

1) Install the MinIO Plugin

Optional

Run the following command to install the MinIO Kubernetes Plugin v4.1.1 using krew:

kubectl krew update
kubectl krew install minio

You can access the plugin using the kubectl minio command.

You can skip this step if the MinIO Plugin is installed on the host machine. Use kubectl minio --help to check whether the plugin is already installed.

2) Configure the Persistent Volumes

MinIO automatically generates one Persistent Volume Claim (PVC) for each volume in the cluster. The cluster must have an equal number of Persistent Volumes (PV). MinIO strongly recommends using locally-attached storage to maximize performance and throughput.

The following steps create the necessary StorageClass and local Persistent Volumes (PV) resources such that each MinIO Pod and their associated storage are local to the same Node.

You can skip this step if the cluster already has local PV resources and a StorageClass configured for use by the MinIO Tenant.

a. Create a StorageClass for the MinIO local Volumes

The following YAML describes a StorageClass with the appropriate fields for use with the local PV:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

The StorageClass must have volumeBindingMode set to WaitForFirstConsumer to ensure correct binding of each pod’s Persistent Volume Claims (PVC) to the Node’s local PV.

b. Create the Required Persistent Volumes

The following YAML describes a PV local volume:

apiVersion: v1
kind: PersistentVolume
metadata:
   name: PV-NAME
spec:
   capacity:
      storage: 1Ti
   volumeMode: Filesystem
   accessModes:
   - ReadWriteOnce
   persistentVolumeReclaimPolicy: Retain
   storage-class: local-storage
   local:
      path: /mnt/disks/ssd1
   nodeAffinity:
      required:
         nodeSelectorTerms:
         - matchExpressions:
            - key: kubernetes.io/hostname
               operator: In
               values:
               - NODE-NAME

Field

Description

metadata:
   name:

Set to a name that supports easy visual identification of the PV and its associated physical host. For example, for a PV on host minio-1, consider specifying minio-1-pv-1.

nodeAffinity:
  required:
    nodeSelectorTerms:
    - key:
        values:

Set to the name of the node on which the physical disk is installed.

spec:
   storage-class:

Set to the StorageClass created for supporting the MinIO local volumes.

spec:
   local:
      path:

Set to the full file path of the locally-attached disk. You can specify a directory on the disk to isolate MinIO-specific data. The specified disk or directory must be empty for MinIO to start.

Create one PV for each volume in the MinIO tenant. For example, given a Kubernetes cluster with 4 Nodes with 4 locally attached drives each, create a total of 16 local PVs.

c. Validate the Created PV

Issue the kubectl get PV command to validate the created PVs:

kubectl get PV

3) Create a Namespace for the MinIO Tenant

Use the kubectl create namespace command to create a namespace for the MinIO Tenant:

kubectl create namespace minio-tenant-1

MinIO supports exactly one Tenant per namespace.

4) Create the MinIO Tenant

Use the kubectl minio tenant create command to create the MinIO Tenant. The command always uses the latest stable Docker image of the MinIO Server and MinIO Console.

The following example creates a 4-node MinIO deployment with a total capacity of 16Ti across 16 drives.

kubectl minio tenant create minio-tenant-1   \
  --servers                 4                \
  --volumes                 16               \
  --capacity                16Ti             \
  --storage-class           local-storage    \
  --namespace               minio-tenant-1

The following table explains each argument specified to the command:

Argument

Description

minio-tenant-1

The name of the MinIO Tenant which the command creates.

--servers

The number of minio servers to deploy across the Kubernetes cluster.

--volumes

The number of volumes in the cluster. kubectl minio determines the number of volumes per server by dividing volumes by servers.

--capacity

The total capacity of the cluster. kubectl minio determines the capacity of each volume by dividing capacity by volumes.

--storage-class

The Kubernetes StorageClass to use when creating each PVC.

--namespace

The Kubernetes namespace in which to deploy the MinIO Tenant.

On success, the command returns the following:

  • The administrative username and password for the Tenant. Store these credentials in a secure location, such as a password protected key manager. MinIO does not show these credentials again.

  • The Service created for connecting to the MinIO Console. The Console supports administrative operations on the Tenant, such as configuring Identity and Access Management (IAM) and bucket configurations.

  • The Service created for connecting to the MinIO Tenant. Applications should use this service for performing operations against the MinIO Tenant.

5) Configure Access to the Service

kubectl minio creates a service for the MinIO Tenant and MinIO Console. The output of kubectl minio tenant create includes the details for both services. You can also use kubectl get svc to retrieve the service name:

kubectl get svc --namespace minio-tenant-1

The command returns output similar to the following:

NAME                     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
minio                    ClusterIP   10.109.88.X     <none>        443/TCP             137m
minio-tenant-1-console   ClusterIP   10.97.87.X      <none>        9090/TCP,9443/TCP   129m
minio-tenant-1-hl        ClusterIP   None            <none>        9000/TCP            137m
  • The minio service corresponds to the MinIO Tenant service. Applications should use this service for performing operations against the MinIO Tenant.

  • The minio-tenant-1-console service corresponds to the MinIO Console. Administrators should use this service for accessing the MinIO Console and performing administrative operations on the MinIO Tenant.

  • The minio-tenant-1-hl corresponds to a headless service used to facilitate communication between Pods in the Tenant.

By default each service is visible only within the Kubernetes cluster. Applications deployed inside the cluster can access the services using the CLUSTER-IP. For applications external to the Kubernetes cluster, you must configure the appropriate network rules to expose access to the service. Kubernetes provides multiple options for configuring external access to services. See the Kubernetes documentation on Publishing Services (ServiceTypes) and Ingress for more complete information on configuring external access to services.

You can temporarily expose each service using the kubectl port-forward utility. Run the following examples to forward traffic from the local host running kubectl to the services running inside the Kubernetes cluster.

kubectl port-forward service/minio 443:443
kubectl port-forward service/minio-tenant-1-console 9443:9443