Search docs.molo17.com

    Gluesync Kubernetes Operator (GKO)

    The Gluesync Kubernetes Operator (GKO) updates a Gluesync install on Kubernetes the way Conductor does on Docker, Docker Swarm and Podman. Platform updates in the Core Hub UI work the same on every platform, and on Kubernetes every running pipeline is put into maintenance mode while Core Hub changes.

    GKO is open source. Its repository, gluesync-operator, its container image molo17/gluesync-operator and its Helm chart keep the name gluesync-operator.

    What GKO does

    One GluesyncPlatform custom resource (short name gsp) describes each Gluesync install and the Core Hub version it should run. When the desired version differs from the version that runs, GKO:

    1. puts every running pipeline into maintenance mode;

    2. changes the Core Hub image and waits until Core Hub stays ready;

    3. takes the pipelines out of maintenance mode;

    4. updates Chronos, Grafana, Prometheus and the other modules, one by one;

    5. rolls back any component that does not come up on its new version;

    6. updates itself last, once no other update is running (GKO 0.2.0 and later).

    From GKO 0.3.0 it also builds a disaster-recovery site when a Super Admin sets up a pair from Settings → Disaster Recovery, as Conductor does on Docker, see Disaster recovery on Kubernetes.

    The update can start from:

    • Platform updates in the Core Hub UI (Update all, or one component), which calls GKO through the same /conductor/api path it uses for Conductor on Docker;

    • a change to spec.version of the GluesyncPlatform, made with kubectl or committed to Git.

    See How an update runs for each step, the stability check and rollback.

    How it compares with Conductor

    Conductor (Docker, Swarm, Podman) GKO (Kubernetes)

    Platform updates in the Core Hub UI

    Yes

    Yes, through the same Conductor API

    Pipelines during a Core Hub update

    Keep running

    Put into maintenance mode, resumed when Core Hub is ready again or after a rollback

    Stability check and rollback

    UPDATE_VERIFY_SECONDS, UPDATE_VERIFY_MAX_WAIT_SECONDS

    spec.stability.windowSeconds, spec.stability.maxWaitSeconds

    Add, start, stop or remove components from Modules Manager

    Yes

    No: Helm owns the workloads; GKO changes only their image

    Versions kept in Git

    No

    Yes, with updatePolicy: gitops or Argo CD

    Updates itself

    Yes, alone, before the other components

    Yes, last, after Core Hub and the modules; the old GKO rolls the new one back if it does not come up (GKO 0.2.0 and later)

    Guided disaster-recovery setup in the Core Hub UI

    Yes, on Docker Compose and Podman: it edits the compose file and writes gluesync-dr.env

    Yes, from GKO 0.3.0: it writes a Secret, changes the Core Hub and Chronos workloads and publishes ports 1718 and 1719 with a Service

    What GKO manages

    GKO works on its own namespace only. It manages the StatefulSets and Deployments of that namespace that carry the label com.molo17.conductor.type, the label Conductor reads in the Docker kits:

    Label value Component

    core-hub

    Core Hub. Exactly one workload carries this value.

    module

    Gluesync modules and bundled services that follow Core Hub’s release channel, such as Chronos, Grafana and Prometheus.

    third-party

    Other images GKO may update.

    operator

    GKO’s own Deployment. GKO lists it in the Core Hub UI as a module and updates it last, see GKO’s own update. The kit and the GKO chart set this label from GKO 0.2.0.

    GKO changes only the container image of these workloads. Replicas, resources, volumes and every other setting stay as Helm installed them. The one exception is a disaster-recovery setup made from the Core Hub UI, which changes what Core Hub and Chronos need for it, see Disaster recovery on Kubernetes. When a pod has several containers, GKO changes the first one, or the one named in the workload annotation gluesync.molo17.com/container.

    Requirements

    • A Gluesync install made with the Kubernetes kit, see Kubernetes and Helm.

    • Helm 3.

    • GKO in the same namespace as Core Hub.

    • Outbound HTTPS from GKO to api.backoffice.molo17.com, the version catalog Conductor also reads. Offline installs do not need it, see Offline installs.

    • A registry the cluster can pull the new images from: Docker Hub, or your mirror set in spec.imageRegistry.

    In this section