OpenShift Garbage Collection versus Docker Garbage Collection

Solution In Progress - Updated -

Environment

  • OpenShift Container Platform
  • Docker Container Runtime

Issue

  • In some cases, a cluster may have docker gc enabled, but not the kubelet (OCP) gc enabled. The opposite may also be true. In some cases, both may be enabled.
  • What is the difference between Garbage Collectors, and should both of them be enabled simultaneously?

Resolution

  • OpenShift Garbage Collection is a kubelet function that is set and maintained on each node, in the node-config.yaml file. If the garbage collection block is not present in every node-config.yaml file, it isn't technically "enabled." There are lots of cases where garbage collection may not be enabled, either because of a bug or config drift. OpenShift's built-in GC is meant to be run once per second automatically. If you want to know more about Garbage Collection in Kubernetes and OpenShift and how to tune it, please see the official documentation. This is the supported route.

  • Alternatively, Docker Garbage collection is a script that, when paired with a config file, removes both layers and manifests from the container runtime that are otherwise not in use. Since Docker v2.4.0, it is built into the runtime. When an image is deleted from the registry API, this makes it eligible for Docker's garbage collection. However, it must be run manually:

# bin/registry garbage-collect [--dry-run] /path/to/config.yml

# cat /path/to/config.yaml

version: 0.1
storage:
  filesystem:
    rootdirectory: /registry/data

For more information regarding the Docker gc, please see their documentation.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments