⚠️ 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:
$ 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.
| Parameter | Description | Default |
|---|---|---|
cron.schedule |
cron schedule | 0 0 * * * (daily at 12:00AM UTC) |
cron.log |
cron log name | /var/logs/cron.log |
env.gracePeriodSeconds |
grace period in seconds before gc occurs | 0 |
env.dockerAPIVersion |
Docker API Version for docker-gc client | Not set |
exclude.images |
images to be excluded | Not set |
exclude.containers |
containers to be excluded | Not set |
serviceAccount |
service account to attach to daemonset | Not set |
imagePullSecrets |
Specify image pull secrets | Not set |
tolerations |
Daemonset tolerations | Not set |
nodeSelector |
Node labels for daemonset pod assignment | Not set |
resources |
Resources for the container in the daemonset | Not 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).