Using MinIO for Object storage

This chart is based on stable/minio version 0.4.3, and inherits most settings from there.

Design Choices

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 initContainers to control the population of secrets into the config.json, and a chart-wide enabled flag.

This chart makes use of only one secret:

• global.minio.credentials.secret: A global secret containing the accesskey and secretkey values that will be used for authentication to the bucket(s).

Configuration

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:
    apiVersion:
    tls:
      enabled:
      secretName:
    annotations:
    configureCertmanager:
    proxyReadTimeout:
    proxyBodySize:
    proxyBuffering:
  tolerations:
  persistence:  # Upstream
    volumeName:
    matchLabels:
    matchExpressions:
    annotations:
  serviceType:  # Upstream
  servicePort:  # Upstream
  defaultBuckets:
  minioConfig:  # Upstream

Installation command line options

The table below contains all the possible charts configurations that can be supplied to the helm install command using the --set flags:

Chart configuration examples

pullSecrets

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 pullSecrets:

image: my.minio.repository
imageTag: latest
imagePullPolicy: Always
pullSecrets:
- name: my-secret-name
- name: my-secondary-secret-name

serviceAccount

This section controls if the default ServiceAccount access token should be mounted in pods.

tolerations

tolerations allow you schedule pods on tainted worker nodes

Below is an example use of tolerations:

tolerations:
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
- key: "node_label"
  operator: "Equal"
  value: "true"
  effect: "NoExecute"

Enable the sub-chart

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 enabled:.

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.

Configure the initContainer

While rarely altered, the initContainer behaviors can be changed via the following items:

init:
  image:
    repository:
    tag:
    pullPolicy: IfNotPresent
  script:

initContainer image

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.gitlabBase.image.repository and the image tag associated with the current global.gitlabVersion will be used to populate the initContainer image. The global configuration can be overridden by chart-local values (e.g. minio.init.image.tag).

initContainer script

The initContainer is passed the following items:

• The secret containing authentication items mounted in /config, usually accesskey and secretkey.
• The ConfigMap containing the config.json template, and configure containing a script to be executed with sh, mounted in /config.
• An emptyDir mounted at /minio that will be passed to the daemon’s container.

The initContainer is expected to populate /minio/config.json with a completed configuration, using /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.

Configuring the Ingress

These settings control the MinIO Ingress.

Configuring the image

The image, imageTag and imagePullPolicy defaults are documented upstream.

Persistence

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 emptyDir, disable PersistentVolumeClaim by: persistence.enabled: false.

The behaviors for persistence are documented upstream.

GitLab has added a few items:

persistence:
  volumeName:
  matchLabels:
  matchExpressions:

defaultBuckets

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 properties: name, policy, and purge.

defaultBuckets:
  - name: public
    policy: public
    purge: true
  - name: private
  - name: public-read
    policy: download

Security Context

These options allow control over which user and/or group is used to start the pod.

For in-depth information about security context, please refer to the official Kubernetes documentation.

Service Type and Port

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.

Upstream items

The upstream documentation for the following also applies completely to this chart:

• resources
• nodeSelector
• minioConfig

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.