GKO changelog

Disaster recovery from the Core Hub UI. Settings → Disaster Recovery sets up, joins, shows the pairing code of and disables a disaster-recovery pair on Kubernetes, as Conductor does on Docker. The pairing code is Conductor’s, so a Kubernetes site and a Docker site pair with each other. See Disaster recovery on Kubernetes

GKO writes the Secret gko-disaster-recovery, wires it into Core Hub, mounts the Chronos data into Core Hub, moves the Core Hub probes to the control port, sets GS_DR_CONTROL_URL on Chronos and publishes ports 1718 and 1719 with the Service gko-disaster-recovery. It backs up both workloads first and restores them if Core Hub does not come up

While disaster recovery is enabled, Core Hub and Chronos cannot be updated from the UI, as with Conductor. No update starts during a disaster-recovery change

New spec.disasterRecovery and status.disasterRecovery in the custom resource definition: apply the definition of this release before you upgrade. GKO’s chart 0.3.0 and the kit (chart 0.5.0) add the RBAC GKO needs for it

While GKO restarts on its new version, POST /containers answers like Conductor’s update mode (503, Retry-After), so the Core Hub UI shows an update in progress and retries

GKO updates itself. Platform updates in the Core Hub UI lists GKO as a module, with the version available on Core Hub’s release channel, and Update all includes it. Without a pin in spec.modules, GKO moves to the latest version whenever Core Hub is updated. See GKO’s own update

GKO changes its own image last: after the update has ended, its result has been saved and the UI has its answer, and once no update has run for 15 seconds. While its new pod starts, new updates wait

The new GKO pod starts next to the old one, which stays in charge until the new pod has been Ready for 10 seconds. A new GKO that crashes, cannot be pulled or is not ready in time is rolled back by the old one

No GKO self-update with updatePolicy: gitops, or with selfUpdate.enabled: false

GKO is Ready only when it can read its GluesyncPlatform through the Kubernetes API

The kit (from v0.0.296, chart 0.4.0) and GKO’s chart 0.2.0 label the GKO Deployment, roll it out with RollingUpdate, enable leader election, and keep the GKO version GKO set on helm upgrade unless the chart brings a newer one. No change to the custom resource definition

Image pull errors that retrying can fix no longer roll an update back at once. A registry or network timeout, or a pull-through cache or registry mirror that has not cached the new image yet, is now retried until spec.stability.maxWaitSeconds. Only a pull the registry refuses (image not found, manifest unknown, unauthorized, denied or forbidden) still fails the stability check at once. When maxWaitSeconds runs out, the failure message now ends with the last pull error. See Stability check

First release of the Gluesync Kubernetes Operator (GKO): it updates Core Hub and its modules on Kubernetes the way Conductor does on Docker, Docker Swarm and Podman. See Gluesync Kubernetes Operator (GKO)

Platform updates in the Core Hub UI work on Kubernetes: GKO connects to Core Hub as its Conductor module and serves the Conductor API on /conductor/api

One GluesyncPlatform resource (short name gsp) per install holds the desired Core Hub version, module pins, the update policy (ui or gitops) and the stability and maintenance settings. GKO reads the release channel set in Core Hub

Every running pipeline is put into maintenance mode while Core Hub changes, and resumed as soon as Core Hub is ready again or rolled back. Pipelines that were already in maintenance mode stay there

Core Hub is updated first, behind a stability check (windowSeconds, maxWaitSeconds), then the modules one by one. A component that does not come up is rolled back to its previous image

The progress of an update is kept in the GluesyncPlatform status, so a restarted GKO carries on from the last finished step. The outcome of each update is kept in status.lastAttempt and the last 10 in status.history

Offline installs (offline: true) and private registry mirrors (imageRegistry) are supported