Harbor is a CNCF Graduated project, creating an open source trusted cloud native registry project that stores, signs, and scans content. A Kubernetes operator is a method of packaging, deploying, and managing a Kubernetes application that is both deployed on Kubernetes and managed using the Kubernetes API and kubectl tooling. The Kubernetes operator allows users to better manage the entire lifecycle of applications running in Kubernetes.
We’re pleased to announce the general availability of Harbor operator 1.0.0! A huge thank you to the contributors to this release, including but not limited to: @holyhope, @steven-zou, @sguyennet, @jMonsinjon, @mhurtrel, @heww, @bitsf, @wangcanfengxs, @Ghostbaby, @soulseen, @chlins, @XavierDuthil. We believe this operator will help users deploy and manage Harbor with much better operational capabilities.
The Harbor operator provides high customizability for you to define and configure your own Harbor stack according to your actual needs by configuring the top level CRD `HarborCluster`. The diagram below shows the overall architecture of the Harbor operator.
The `HarborCluster` CR defines the whole Harbor registry stack by owning the CR `Harbor` which represents core components as well as related services such as PostgreSQL database, Redis cache and backend storage. There are a couple of ways to configure this stack to fit your environment. If you have some services already installed, then you can directly leverage these by simply setting the imageChartStorage spec for the backend storage service, database spec for the database service and redis spec for the cache service. If you want the Harbor Operator to deploy the related dependent services into your Kubernetes cluster together with Harbor components, you just need to declare the related requirements by setting the inClusterStorage spec for the backend service, inClusterDatabase spec for the database service and inClusterCache spec for the cache service. Currently, the default in-cluster storage service is Minio, the default in-cluster database is zalando postgreSQL, and the default in-cluster cache is spotahome redis. Our plan is to have other 3rd party operators validated and added to the Harbor Operator in the near future. To successfully deploy Harbor through the operator, we need to make sure the corresponding underlying operators are deployed first before configuring and enabling the in-cluster services in the `HarborCluster` CR spec. The Harbor operator repo provides an all-in-one deployment manifest for deploying all the underlying operators as well as Harbor operator itself with one command. Please refer to the detailed installation guide on additional options for deployment.
The Harbor registry is composed of multiple service components. In the Harbor operator, each service component is represented by a separate CR with its own reconciling controller. The component reconciling controllers share the same reconcile flow. The component CRs are owned and controlled by the upper `Harbor` CR mentioned above. The components are categorized into two groups: mandatory components and optional components. Mandatory components include `Portal`, `Core`, `Jobservice`, `Registry` and `Registry Controller` which must be installed by default. `Notary` (server and signer), `Trivy`, `Chartmuseum` and `Metrics Exporter` are optional and can be added into the Harbor deploying stack by explicitly configuring it in the spec.
The Harbor operator leverages the cert-manager project to generate and manage the related certificates required by Harbor. For exposing the related accessing services, ingress(v1beta1) is adopted. So far, default(NGINX), GCE and NCP ingress controllers have been verified. See details here.
Current features:
- Provides high customizability in the deployment stack (identified by HarborCluster CR)
- Minimal stack: provisions core components only including Harbor Core, Registry, Registry Controller, Job Service and Web Portal
- Standard stack: provisions optional components such Notary, Trivy, ChartMuseum and Metrics Exporter
- Full stack: provisions related dependent services including the database (PostgreSQL), cache (Redis) and storage (MinIO)
- Supports configuring either external or in-cluster deployed dependent services
- Supports a variety of backend storage configurations
- filesystem: A storage driver configured to use a directory tree in a Kubernetes volume.
- s3: A driver storing objects in an Amazon S3 bucket.
- swift: A driver storing objects in Openstack Swift.
- Supports updating the deployed Harbor cluster
- Allows configuring replicas of individual components
- Support in place upgrades
- Deletes all the linked resources when deleting the Harbor cluster
- Configures Harbor system settings with ConfigMap in a declarative way
- Support services exposed with ingress (validated NGINX, GCE, NSX NCP)
What’s next?
A patch release 1.0.1 is being planned. This patch release will focus on:
- Enable the Harbor operator to work with the Contour ingress controller
- Fix issue of using NSX NCP ingress controller
- Verify compatibility on OpenShift platform
- Fix some functional bugs
Roadmap:
More features we look to research for future releases:
- More backend storage driver configurations:
- Remove the optional Harbor components by updating the spec of the deployed Harbor cluster.
- Expose services with a LoadBalancer.
- Backup and restore data in an easy manner (such as registry layer, chartmuseum data, databases content etc.).
- Auto-scaling for each component.
Additionally, we would like to provide more Day2 operations to simplify the Harbor usage and improve the Harbor user experience on Kubernetes. The Day2 operations might contain the following items:
- CRD based system configuration settings (at present, configMap based has been already supported)
- Auto mapping Kubernetes namespaces and Harbor project
- Pull secrets auto injections
- Container image path rewriting
- Transparent proxy cache settings
Those Day2 operation functionalities have been prototyped in a PoC project already, and we’re planning to port these into the Harbor operator repository in the near future.
Furthermore, we’ll continue to refactor the spec of the top level CR `HarorCluster` to make it more consistent, efficient and explicit.
The next minor releases have also been planned too, learn more about what new features will be included in, check out the 1.1 release plan and 1.2 release plan.
Lastly, voices from the community are highly valued. We look forward to working with the community to figure out and agree on important features for our users worldwide.
Getting started:
Come try it out by reading the tutorial!
Contributions:
We would love your feedback!If you’re interested in doing contributions to Harbor operator, want to join the operator maintainer group, or just give us feedback please join our Slack channel #harbor-operator-dev in the CNCF workspace.
About Harbor
Harbor is an open source, trusted cloud native registry project that stores, signs, and scans container images, Helm charts, and any other OCI-compliant artifacts. Harbor extends the open-source Docker Distribution by adding key enterprise-level features in authentication and access control (LDAP and AD as well as OIDC support for RBAC), two-way replication to and from other third-party registries, advanced garbage collection, and authenticity and provenance capabilities through third-party image scanning and signing solutions. Harbor, which supports Docker Compose and Kubernetes, deploys in under 30 minutes. Harbor can be fully managed through a single web console and comes with a rich set of APIs managed with Swagger.
Collaborate with the Harbor Community!
Get updates on Twitter ( @project_harbor)
Chat with us on Slack ( #harbor and #harbor-dev on the CNCF Slack)
Collaborate with us on GitHub: github.com/goharbor/harbor
Attend the community meetings: https://github.com/goharbor/community/wiki/Harbor-Community-Meetings
References:
You can find more documentation here.
Steven Zou
Harbor Maintainer
Staff Engineer VMware