This is a cache of https://docs.okd.io/latest/registry/index.html. It is a snapshot of the page at 2025-04-19T18:40:08.952+0000.
Registry overview | Registry | OKD 4
  1. Documentation
×

OpenShift image registry overview

OKD can build images from your source code, deploy them, and manage their lifecycle. It provides an internal, integrated container image registry that can be deployed in your OKD environment to locally manage images. This overview contains reference information and links for registries commonly used with OKD, with a focus on the OpenShift image registry.

Glossary of common terms for OpenShift image registry

This glossary defines the common terms that are used in the registry content.

container

Lightweight and executable images that consist of software and all its dependencies. Because containers virtualize the operating system, you can run containers in a data center, a public or private cloud, or your local host.

image repository

An image repository is a collection of related container images and tags identifying images.

mirror registry

The mirror registry is a registry that holds the mirror of OKD images.

namespace

A namespace isolates groups of resources within a single cluster.

pod

The pod is the smallest logical unit in Kubernetes. A pod is comprised of one or more containers to run in a worker node.

private registry

A registry is a server that implements the container image registry API. A private registry is a registry that requires authentication to allow users access its contents.

public registry

A registry is a server that implements the container image registry API. A public registry is a registry that serves its contently publicly.

Quay.io

A public Red Hat Quay Container Registry instance provided and maintained by Red Hat, which serves most of the container images and Operators to OKD clusters.

OpenShift image registry

OpenShift image registry is the registry provided by OKD to manage images.

registry authentication

To push and pull images to and from private image repositories, the registry needs to authenticate its users with credentials.

route

Exposes a service to allow for network access to pods from users and applications outside the OKD instance.

scale down

To decrease the number of replicas.

scale up

To increase the number of replicas.

service

A service exposes a running application on a set of pods.

Integrated OpenShift image registry

OKD provides a built-in container image registry that runs as a standard workload on the cluster. The registry is configured and managed by an infrastructure Operator. It provides an out-of-the-box solution for users to manage the images that run their workloads, and runs on top of the existing cluster infrastructure. This registry can be scaled up or down like any other cluster workload and does not require specific infrastructure provisioning. In addition, it is integrated into the cluster user authentication and authorization system, which means that access to create and retrieve images is controlled by defining user permissions on the image resources.

The registry is typically used as a publication target for images built on the cluster, as well as being a source of images for workloads running on the cluster. When a new image is pushed to the registry, the cluster is notified of the new image and other components can react to and consume the updated image.

Image data is stored in two locations. The actual image data is stored in a configurable storage location, such as cloud storage or a filesystem volume. The image metadata, which is exposed by the standard cluster APIs and is used to perform access control, is stored as standard API resources, specifically images and image streams.

Additional resources

Automatically pruning images

Images from the OpenShift image registry that are no longer required by the system due to age, status, or exceed limits are automatically pruned. Cluster administrators can configure the Pruning Custom Resource, or suspend it.

Prerequisites

  • You have access to an OKD cluster using an account with cluster administrator permissions.

  • Install the oc CLI.

Procedure

  • Verify that the object named imagepruners.imageregistry.operator.openshift.io/cluster contains the following spec and status fields:

spec:
  schedule: 0 0 * * * (1)
  suspend: false (2)
  keepTagRevisions: 3 (3)
  keepYoungerThanDuration: 60m (4)
  keepYoungerThan: 3600000000000 (5)
  resources: {} (6)
  affinity: {} (7)
  nodeSelector: {} (8)
  tolerations: [] (9)
  successfulJobsHistoryLimit: 3 (10)
  failedJobsHistoryLimit: 3 (11)
status:
  observedGeneration: 2 (12)
  conditions: (13)
  - type: Available
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Ready
    message: "Periodic image pruner has been created."
  - type: Scheduled
    status: "True"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Scheduled
    message: "Image pruner job has been scheduled."
  - type: Failed
    staus: "False"
    lastTransitionTime: 2019-10-09T03:13:45
    reason: Succeeded
    message: "Most recent image pruning job succeeded."
1 schedule: CronJob formatted schedule. This is an optional field, default is daily at midnight.
2 suspend: If set to true, the CronJob running pruning is suspended. This is an optional field, default is false. The initial value on new clusters is false.
3 keepTagRevisions: The number of revisions per tag to keep. This is an optional field, default is 3. The initial value is 3.
4 keepYoungerThanDuration: Retain images younger than this duration. This is an optional field. If a value is not specified, either keepYoungerThan or the default value 60m (60 minutes) is used.
5 keepYoungerThan: Deprecated. The same as keepYoungerThanDuration, but the duration is specified as an integer in nanoseconds. This is an optional field. When keepYoungerThanDuration is set, this field is ignored.
6 resources: Standard pod resource requests and limits. This is an optional field.
7 affinity: Standard pod affinity. This is an optional field.
8 nodeSelector: Standard pod node selector. This is an optional field.
9 tolerations: Standard pod tolerations. This is an optional field.
10 successfulJobsHistoryLimit: The maximum number of successful jobs to retain. Must be >= 1 to ensure metrics are reported. This is an optional field, default is 3. The initial value is 3.
11 failedJobsHistoryLimit: The maximum number of failed jobs to retain. Must be >= 1 to ensure metrics are reported. This is an optional field, default is 3. The initial value is 3.
12 observedGeneration: The generation observed by the Operator.
13 conditions: The standard condition objects with the following types:

  • Available: Indicates if the pruning job has been created. Reasons can be Ready or Error.

  • Scheduled: Indicates if the next pruning job has been scheduled. Reasons can be Scheduled, Suspended, or Error.

  • Failed: Indicates if the most recent pruning job failed.

The Image Registry Operator’s behavior for managing the pruner is orthogonal to the managementState specified on the Image Registry Operator’s ClusterOperator object. If the Image Registry Operator is not in the Managed state, the image pruner can still be configured and managed by the Pruning Custom Resource.

However, the managementState of the Image Registry Operator alters the behavior of the deployed image pruner job:

  • Managed: the --prune-registry flag for the image pruner is set to true.

  • Removed: the --prune-registry flag for the image pruner is set to false, meaning it only prunes image metadata in etcd.

Third-party registries

OKD can create containers using images from third-party registries, but it is unlikely that these registries offer the same image notification support as the integrated OpenShift image registry. In this situation, OKD will fetch tags from the remote registry upon image stream creation. To refresh the fetched tags, run oc import-image <stream>. When new images are detected, the previously described build and deployment reactions occur.

Authentication

OKD can communicate with registries to access private image repositories using credentials supplied by the user. This allows OKD to push and pull images to and from private repositories.

Registry authentication with Podman

Some container image registries require access authorization. Podman is an open source tool for managing containers and container images and interacting with image registries. You can use Podman to authenticate your credentials, pull the registry image, and store local images in a local file system. The following is a generic example of authenticating the registry with Podman.

Procedure

  1. Use the Red Hat Ecosystem Catalog to search for specific container images from the Red Hat Repository and select the required image.

  2. Click Get this image to find the command for your container image.

  3. Log in by running the following command and entering your username and password to authenticate:

    $ podman login registry.redhat.io
 Username:<your_registry_account_username>
 Password:<your_registry_account_password>

  4. Download the image and save it locally by running the following command:

    $ podman pull registry.redhat.io/<repository_name>

Red Hat Quay registries

If you need an enterprise-quality container image registry, Red Hat Quay is available both as a hosted service and as software you can install in your own data center or cloud environment. Advanced features in Red Hat Quay include geo-replication, image scanning, and the ability to roll back images.

Visit the Quay.io site to set up your own hosted Quay registry account. After that, follow the Quay Tutorial to log in to the Quay registry and start managing your images.

You can access your Red Hat Quay registry from OKD like any remote container image registry.

Additional resources

Authentication enabled Red Hat registry

All container images available through the Container images section of the Red Hat Ecosystem Catalog are hosted on an image registry, registry.redhat.io.

The registry, registry.redhat.io, requires authentication for access to images and hosted content on OKD. Following the move to the new registry, the existing registry will be available for a period of time.

OKD pulls images from registry.redhat.io, so you must configure your cluster to use it.

The new registry uses standard OAuth mechanisms for authentication, with the following methods:

  • Authentication token. Tokens, which are generated by administrators, are service accounts that give systems the ability to authenticate against the container image registry. Service accounts are not affected by changes in user accounts, so the token authentication method is reliable and resilient. This is the only supported authentication option for production clusters.

  • Web username and password. This is the standard set of credentials you use to log in to resources such as access.redhat.com. While it is possible to use this authentication method with OKD, it is not supported for production deployments. Restrict this authentication method to stand-alone projects outside OKD.

You can use podman login with your credentials, either username and password or authentication token, to access content on the new registry.

All image streams point to the new registry, which uses the installation pull secret to authenticate.

You must place your credentials in either of the following places:

  • openshift namespace. Your credentials must exist in the openshift namespace so that the image streams in the openshift namespace can import.

  • Your host. Your credentials must exist on your host because Kubernetes uses the credentials from your host when it goes to pull images.

Additional resources