Back to Charts

⚠️ Repo Archive Notice

stable/spotify-docker-gc/README.md

latest3.9 KB
Original Source

⚠️ Repo Archive Notice

As of Nov 13, 2020, charts in this repo will no longer be updated. For more information, see the Helm Charts Deprecation and Archive Notice, and Update.

Spotify's Docker-GC Helm Chart

This chart wraps the spotify/docker-gc Docker image in the form of a DaemonSet, so that Docker resource garbage collection occurs on all nodes of a given Kubernetes cluster.

DEPRECATION NOTICE

This chart is deprecated and no longer supported.

Chart Details

This chart will do the following:

  • Deploy one pod running the spotify/docker-gc container to each node in a Kubernetes cluster, configured with the values provided.

Installing the Chart

To install the chart with the release name my-release:

bash
$ helm install --name my-release stable/spotify-docker-gc

Configuration

The following table lists the configurable parameters of the Spotify Docker GC chart and their default values.

See the spotify/docker-gc GitHub repository for more settings which may be added to this chart as needed.

ParameterDescriptionDefault
cron.schedulecron schedule0 0 * * * (daily at 12:00AM UTC)
cron.logcron log name/var/logs/cron.log
env.gracePeriodSecondsgrace period in seconds before gc occurs0
env.dockerAPIVersionDocker API Version for docker-gc clientNot set
exclude.imagesimages to be excludedNot set
exclude.containerscontainers to be excludedNot set
serviceAccountservice account to attach to daemonsetNot set
imagePullSecretsSpecify image pull secretsNot set
tolerationsDaemonset tolerationsNot set
nodeSelectorNode labels for daemonset pod assignmentNot set
resourcesResources for the container in the daemonsetNot set

Design/Evolution

The initial approach for wrapping spotify/docker-gc in a Helm chart was to use a CronJob. However, as of this writing, there is no native support for DaemonSet-like behavior -- that is, ensuring Jobs spawned by a given CronJob run on all nodes in a Kubernetes cluster. Once this feature has been implemented and the CronJob resource itself stabilizes (it is currently in alpha), conversion to this resource would be prudent and will simplify the template/logic.

With regard to the DaemonSet resource, do note that only in Kubernetes version >= 1.6 are pods automatically redeployed via Rolling Update when the DaemonSet itself is changed (e.g., via a helm upgrade).