Application introduction

The purpose of an image-registry is to serve and store container images. A container image is a basic requirement for running containers within pods. For this reason, it is crucial to have access to a container image registry resource in order to be able to run containerized workloads at all. An image-registry enables fast application startup, scaling and also allows easy application shipping capabilities across different workers within an OpenShift Kubernetes cluster.

Red Hat OpenShift Container Platform (OCP) provides a built-in container image registry which runs as a standard workload on the cluster. This registry is configured and managed by an infrastructure operator. It provides an out of the box solution for users, to manage images that facilitate their workloads.A registry service requires back-end storage to store its repository contents. This back-end storage must be shared across all worker hosts in the OCP cluster.

Openshift Image-registry storage options

OCP can run on many infrastructures, including public clouds, private clouds, and on-premises on VMware or bare metal clusters. As the OCP Image Registry must be shared with all worker nodes in the cluster, supported storage types include shared object storage and shared RWX Persistent Volumes (PVs).

Table 1: Storage Defaults and Recommendations for the OCP Image Registry

OCP can be deployed via two different methods, Installer Provisioned Infrastructure (IPI) or User Provisioned Infrastructure (UPI). With the IPI method, the OCP installer chooses a default storage to back the Image Registry. With the UPI method, the user chooses the default storage to back the Image Registry. Table 1 reflects storage repository defaults and recommendations for many popular platforms supported by OCP.

IPI configures infrastructure resources, such as compute, network and storage, directly for OCP. As a result, registry back-end storage is automatically setup and configured with IPI. For example, when running on AWS, IPI automatically requests and configures an S3 bucket to back the image registry.

Benefits of OCS with UPI Installation Mode

In the case of UPI, the OpenShift image-registry requires a pre-provisioned persistent volume (PV) with ReadWriteMany (RWX) access mode. This allows for multiple worker pods to have simultaneous access. An RWX persistent volume claim for registry must have "100Gi" capacity, which is however allowed to be thin-provisioned. In many OCP UPI deployments, only block storage is available as a basic storage provider. Examples of this can be local disk storage, SAN or VMware VSAN storage. These block storage providers do not offer File- or Object (S3) storage and are therefore not able to provide recommended storage for the OCP image-registry, nor fulfill all storage needs that modern containerized applications can have.

Red Hat OpenShift Container Storage (OCS) can provide the RWX PVs to back the OCP image registry. OCS leverages CephFS for this functionality, completely orchestrated by Rook. Besides serving RWX capacity to the Image-registry, OCS can also offer both Block based storage volumes and NooBaa S3 storage to other container pods that run other application workloads. At this point, use of NooBaa S3 storage is not supported by Red Hat for use with the built-in OCP image registry.

OCS Purpose in Private Cloud / Virtual- or Bare Metal environments

As shown in the graphic, on its South side, OCS can consume any existing block storage that is available within the infrastructure and then transform that through OCS into any type of storage that a modern containerized application could possibly need: Block, File or Object.

OCS also provides protected storage, as internal replication and other Ceph protection methodologies apply to the all storage that is served out on the North side of the OCS solution.
The OpenShift cluster now has multiple Storage Classes, which thereafter can be approached by application pods to address their persistent volume claims (PVC) onto.

Depending on the underlying block storage properties, specs and/or SLA’s, different Storage Classes can be created, based on their specific properties.

Container storage components in brief
PVC - Persistent Volume Claim - a request for storage, originating from an application

PV - Persistent Volume - storage volume for container pods - addressed against a SC

SC - Storage Class - Available storage resourcing, with certain properties and descriptions

Conclusion

In Private Cloud or with Virtual and Bare Metal environments, OCS is an enabler for all possible container application storage needs, even while only raw block storage is originally available within the underlying infrastructure.

OCS consumes raw block devices for its own sourcing and can then serve out all other frequently requested types of container storage, in a replicated and reliable way, powered by proven technologies like Ceph, NooBaa and Rook.

Container storage is provisioned and mounted to container pods in a fully abstracted and automated way. This means that there is no requirement for any administrator interaction in regards to the creation and user consumption of the actual container storage as such.

In practice, this means that developers or OpenShift users do not have to wait for storage provisioning or someone who needs to take care of storage sourcing to them. They can just request their specific storage need to the system and it can be made available instantly.
In reverse, when storage resources are no longer needed, the system can also take care of recycling of storage, depending on how policies have been set and applied.

Summarizing, with OCS, protected and replicated storage,  all frequently requested storage flavors are available. Storage capacity is provisioned instantly to requesting parties.

Housekeeping is realized in an efficient and automated way.
The OCS storage solution is self-healing and proactive in case of component failure, in case this would perhaps occur.  There is no single point of failure, providing a high level of availability.

In Public Cloud situations, it obviously makes less sense to use OCS for the OpenShift built-in image registry since S3 back-end storage already is available and provisioned by IPI.
It can however still be very valuable to have OCS functionality for other applications or workloads.  OCS usage for only the built-in image-registry use case makes less sense from a public cloud IPI perspective.

Additional Resources

• OpenShift Container Storage: openshift.com/storage
• OpenShift | Storage YouTube Playlist
• OpenShift Commons ‘All Things Data’ YouTube Playlist

Feedback

To find out more about OpenShift Container Storage or to take a test drive, visit https://www.openshift.com/products/container-storage/.

If you would like to learn more about what the OpenShift Container Storage team is up to or provide feedback on any of the new 4.3 features, take this brief 3-minute survey.