- Design Choices
- Chart configuration examples
- Enable the sub-chart
- Configure the initContainer
- Configuring the Ingress
- Configuring the image
- Security Context
- Service Type and Port
- Upstream items
Design choices related to the upstream chart can be found in the project’s README.
GitLab chose to alter that chart in order to simplify configuration of the secrets,
and to remove all use of secrets in environment variables. GitLab added
to control the population of secrets into the
config.json, and a chart-wide
This chart makes use of only one secret:
global.minio.credentials.secret: A global secret containing the
secretkeyvalues that will be used for authentication to the bucket(s).
We will describe all the major sections of the configuration below. When configuring from the parent chart, these values will be:
minio: init: ingress: enabled: tls: enabled: secretName: annotations: proxyReadTimeout: proxyBodySize: proxyBuffering: tolerations: persistence: # Upstream volumeName: matchLabels: matchExpressions: serviceType: # Upstream servicePort: # Upstream defaultBuckets: minioConfig: # Upstream
The table below contains all the possible charts configurations that can be supplied
helm install command using the
|MinIO default buckets|
|MinIO image pull policy|
|MinIO image tag|
|MinIO browser flag|
|MinIO mc image|
|MinIO mc image tag|
|MinIO configuration file mount path|
|MinIO persistence access mode|
|MinIO enable persistence flag|
|MinIO label-expression matches to bind|
|MinIO label-value matches to bind|
|MinIO persistence volume size|
|MinIO storageClassName for provisioning|
|MinIO persistence volume mount path|
|MinIO existing persistent volume name|
|Secrets for the image repository|
|MinIO number of replicas|
|MinIO minimum CPU requested|
|MinIO minimum memory requested|
|Group ID to start the pod with|
|User ID to start the pod with|
|MinIO service port|
|MinIO service type|
|Toleration labels for pod assignment|
pullSecrets allows you to authenticate to a private registry to pull images for a pod.
Additional details about private registries and their authentication methods can be found in the Kubernetes documentation.
Below is an example use of
image: my.minio.repository imageTag: latest imagePullPolicy: Always pullSecrets: - name: my-secret-name - name: my-secondary-secret-name
tolerations allow you schedule pods on tainted worker nodes
Below is an example use of
tolerations: - key: "node_label" operator: "Equal" value: "true" effect: "NoSchedule" - key: "node_label" operator: "Equal" value: "true" effect: "NoExecute"
They way we’ve chosen to implement compartmentalized sub-charts includes the ability
to disable the components that you may not want in a given deployment. For this reason,
the first setting you should decide on is
By default, MinIO is enabled out of the box, but is not recommended for production use.
When you are ready to disable it, run
--set global.minio.enabled: false.
While rarely altered, the
initContainer behaviors can be changed via the following items:
init: image: repository: tag: pullPolicy: IfNotPresent script:
The initContainer image settings are just as with a normal image configuration.
By default, chart-local values are left empty, and the global settings
global.busybox.image.tag will be used to
populate initContainer image. If chart-local values are specified, they get
used instead of the global setting’s values.
The initContainer is passed the following items:
- The secret containing authentication items mounted in
- The ConfigMap containing the
configurecontaining a script to be executed with
sh, mounted in
/miniothat will be passed to the daemon’s container.
The initContainer is expected to populate
/minio/config.json with a completed configuration,
/config/configure script. When the
minio-config container has completed
that task, the
/minio directory will be passed to the
minio container, and used
to provide the
config.json to the MinIO server.
These settings control the MinIO Ingress.
|String||This field is an exact match to the standard |
|Boolean||Setting that controls whether to create Ingress objects for services that support them. When |
|Boolean||When set to |
|String||The name of the Kubernetes TLS Secret that contains a valid certificate and key for the MinIO URL. When not set, the |
imagePullPolicy defaults are
This chart provisions a
PersistentVolumeClaim and mounts a corresponding persistent
volume to default location
/export. You’ll need physical storage available in the
Kubernetes cluster for this to work. If you’d rather use
GitLab has added a few items:
persistence: volumeName: matchLabels: matchExpressions:
|Map||Accepts a Map of label names and label values to match against when choosing a volume to bind. This is used in the |
|Array||Accepts an array of label condition objects to match against when choosing a volume to bind. This is used in the |
defaultBuckets provides a mechanism to automatically create buckets on the MinIO
pod at installation. This property contains an array of items, each with up to three
defaultBuckets: - name: public policy: public purge: true - name: private - name: public-read policy: download
|String||The name of the bucket that is created. The provided value should conform to AWS bucket naming rules, meaning that it should be compliant with DNS and contain only the characters a-z, 0-9, and – (hyphen) in strings between 3 and 63 characters in length. The |
|The value of |
These options allow control over which
group is used to start the pod.
For in-depth information about security context, please refer to the official Kubernetes documentation.
These are documented upstream, and the key summary is:
## Expose the MinIO service to be accessed from outside the cluster (LoadBalancer service). ## or access it from within the cluster (ClusterIP service). Set the service type and the port to serve it. ## ref: http://kubernetes.io/docs/user-guide/services/ ## serviceType: LoadBalancer servicePort: 9000
The chart does not expect to be of the
type: NodePort, so do not set it as such.
The upstream documentation for the following also applies completely to this chart:
Further explanation of the
minioConfig settings can be found in the
MinIO notify documentation.
This includes details on publishing notifications when Bucket Objects are accessed or changed.