I would like to know the great advantages of GitLab Operator. I read the GitLab Operator documentation, but I don’t quite understand it.
Ease the installation and configuration of GitLab instances.
I don’t think the difficulty is much different than install GitLab Helm Chart.
Offer seamless upgrades from version to version.
Is this mean zero-downtime upgrade? I don’t think the upgrade on GitLab Chart will change that much now.
Ease backup and restore of GitLab and its components.
Both using the backup utility in toolbox (task-runner) is the same way.
…
Since GitLab Operator has become GA, I would like to introduce it, but I did not understand the clear merit, so please tell me.
What I understood by the GA release blog post, it doesn’t offer much for normal Kubernetes, compared to the Helm Chart.
The main difference is that it can be installed on Red Hat OpenShift which does not support Helm Charts.
Also, I’ve had some problems upgrading Gitlab using Helm Charts before. Although it was a rare scenario where I had lots of custom configurations but I’d hope that the new Operator approach would be even simpler.
The Operator offers extended capabilities beyond the Cloud Native Helm Chart. The Operator functions to not only deploy GitLab initially, it also actively secures the deployment against unwarranted changes and keeps GitLab continually up-to-date as components are versioned. Most importantly, the GA release of the GitLab Operator provides the ability to run production instances of GitLab on Red Hat Openshift (with official Red Hat OpenShift certification coming soon!). While the Helm Chart only supports vanilla Kubernetes, the Operator runs on both Red Hat OpenShift and vanilla Kubernetes.