# Updates for Operator 4.5.0 - Add --interactive flag info to kubectl create tenant docs - Adds flag to kubectl minio tenant create doc - Softens wording on bucket limit to be recommended in the MinIO console doc for PR#649 # Updates for Console v0.20.5 - Adds environment variable option to create tenant - Creates Audit Log section to create tenant page and moves some options there # Updates for console v0.21.0 - Adding info about the tiers status column when in the console - Reworking site replication section for new changes to the layout in Console - Skips documenting support for editing raw YAML for encryption page when creating a tenant, as that seems to not be supported any longer # Updates for operator 4.5.4 - Adds --pool flag to kubectl minio tenant create - Adds --pool flag to kubectl minio tenant expand Closes #634 Closes #615 Closes #590 Closes #569
5.4 KiB
kubectl minio tenant expand
minio
Table of Contents
kubectl minio tenant expand
Description
Extends the total capacity of a MinIO Tenant by adding a new Pool. A Pool consists of an independent set of pods running the MinIO Server and MinIO Console. The new pool uses the same MinIO Server and Console Docker images as the existing Tenant pool(s).
Syntax
EXAMPLE
The following example expands a MinIO Tenant with a Pool consisting of 4 MinIO servers with 8 drives each and a total additional capacity of 32Ti:
kubectl minio tenant expand \
minio-tenant-1 \
--servers 4 \
--volumes 8 \
--capacity 32Ti \
--namespace minio-tenant-1 \
--storage-class local-storage
SYNTAX
The command has the following syntax:
kubectl minio tenant expand \
TENANT_NAME \
--capacity \
--servers \
--volumes \
--namespace \
[--output] \
[--pool] \
[--storage-class]
Flags
The command supports the following flags:
TENANT_NAME
The name of the MinIO tenant to expand.
--capacity
- The total capacity of the new MinIO Tenant Pool.
kubectl minio
divides the capacity by the number of~kubectl minio tenant expand --volumes
to determine the -
amount of
resources.requests.storage
to set for each Persistent Volume Claim (PVC
).
If the existing Persistent Volumes (PV
) can satisfy the
requested storage, kubectl minio tenant expand
hangs and waits until the
required storage exists.
--servers
The number of minio
servers to deploy in the new MinIO
Tenant Pool.
Ensure that the specified number of ~kubectl minio tenant expand --servers
does
not exceed the number of available nodes in the Kubernetes
cluster.
--volumes
The number of volumes in the new MinIO Tenant Pool. kubectl minio
generates one
Persistent Volume Claim (PVC
) for each volume.
The number of volumes affects both the requested storage of each
PVC
and the number of PVC
to
associate to each MinIO Pod in the new Pool:
- The command
kubectl minio
divides the~kubectl minio tenant expand --capacity
by the number of volumes to determine the amount ofresources.requests.storage
to set for eachPVC
. kubectl minio
determines the number ofPVC
to associate to eachminio
server by dividing~kubectl minio tenant expand --volumes
by~kubectl minio tenant expand --servers
.
The command generates each PVC
with Pod-specific
selectors, such that each Pod only uses PV
that are
locally-attached to the node running that Pod.
If the specified number of volumes exceeds the number of unbound
PV
available in the cluster, kubectl minio tenant expand
hangs and waits until the
required PV
exist.
--namespace
The namespace in which to create the new MinIO Tenant Pool. The namespace must match that of the MinIO Tenant being extended.
Defaults to minio
.
--output
Outputs the generated YAML
objects to
STDOUT
for further customization.
~kubectl minio tenant expand --output
does
not create the new MinIO Tenant Pool. Use
kubectl apply -f <FILE>
to manually create the MinIO
tenant using the generated file.
--pool
The name to assign to the pool created for this expansion.
--storage-class
The name of the Kubernetes Storage Class <concepts/storage/storage-classes/>
to use when creating Persistent Volume Claims (PVC
) for the
new MinIO Tenant Pool. The specified ~kubectl minio tenant expand --storage-class
must match the storage-class
of the Persistent
Volumes (PVs
) to which the PVCs
should
bind.
MinIO strongly recommends creating a Storage Class that corresponds
to locally-attached volumes on the host machines on which the Tenant
deploys. This ensures each pod can use locally-attached storage for
maximum performance and throughput. See the Deploy MinIO Tenant <minio-k8s-deploy-minio-tenant>
tutorial for guidance on creating Storage Classes for supporting the
MinIO Tenant.