Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News OVHcloud's Harbor Kubernetes Operator Becomes Part of CNCF’s goharbor Project

OVHcloud's Harbor Kubernetes Operator Becomes Part of CNCF’s goharbor Project

This item in japanese

Lire ce contenu en français

OVHcloud released their Kubernetes operator for the Harbor container registry as open source under the CNCF's goharbor project.

Harbor was built to manage container images and also provide services such as image vulnerability scanning, access control, and compliance. Harbor was an internal project at VMware before it was open sourced, and the CNCF accepted it as a Sandbox project in 2018. It is currently in the incubation stage. OVHcloud has a managed private container registry service which is based on Harbor. They wrote a Kubernetes operator - a software extension to Kubernetes for managing applications and their dependencies - for Harbor and open sourced it under the goharbor project.

InfoQ reached out to Maxime Hurtrel, product manager at OVHcloud, to learn more about it.

Harbor uses several other software components. These include Redis for caching and temporary persistence, PostgreSQL as a database, and nginx for API routing. In addition, it supports Notary for image signing, and several image vulnerability scanners. Harbor can be deployed on Kubernetes with high availability (HA) using Helm charts also. However, the HA part of the dependent components is not provided by Harbor in such deployments. They have to be separately scaled and made highly available.

As far as scaling Harbor itself, Hurtrel says the operator is "still at its early stages, especially concerning Day 2 operations". There are plans to rely on the Kubernetes horizontal pod autoscaler in the future. "As of today", Hurtrel clarifies, "the scaling of the components would require config updates."

Does the operator manage the lifecycle of Harbor’s dependencies too? Hurtrel responds:

We decided to focus the Harbor operator 1.0 on managing the lifecycle of Harbor and its different software components and leave the dependencies (DBs and registry layers storage) totally to the choice of the user, but out of the lifecycle scope for the moment. We see many use cases where those would be supplied as a service by other IT teams and/or cloud providers, so we want to add value on Harbor itself first.

He adds that "another packaged version of the operator ('cluster operator') is on its way, and there we will package a Redis operator for those who want to deploy it 'the hard way'."

Image courtesy: OVHcloud. Used with permission.

The Harbor operator does support external storage components, as one of its goals is to "be agnostic of the requirements" for such components. Hurtrel gives a real-world example of this:

At OVHcloud, we manage a thousand Harbor services with this operator. We deploy it with managed Postgres, Redis and S3-compatible backends, which are provided by other teams within OVHcloud.

The operator's future roadmap has full lifecycle management, scaling, updates, and backup management for Harbor. The source code is available on Github.

Rate this Article