GitOps

KubeGlass finds Argo CD, Flux and Argo Rollouts through API discovery. There is nothing to configure: install one and its view fills in. Without Argo CD or Flux, Applications › GitOps says so, with links to install either, and Look again checks for them.

GitOps applications

Applications › GitOps is one list of the Argo CD Applications and Flux Kustomizations and HelmReleases KubeGlass found. Above it, a line names each Argo CD or Flux installation with its version (marked when it isn’t healthy) and how many applications there are, followed by counts of the applications that are degraded, missing, out of sync or progressing. Click a count to show only those applications; click it again to show all.

The list reads each installation as you. When the API server refuses one (you may not list its applications), doesn’t answer in time or can’t be reached, a note above the list names that installation and which of the three it was, and the list has the other installations’ applications. When none could be listed, the note takes the list’s place. Clusters, Topology and Sources do the same; Topology still shows each controller.

Each row shows the application, its sync status and health, its source (repository and path, or chart), revision and last sync. Under the name are the message of an application that is degraded or out of sync, the application that manages it, and for app-of-apps setups how many it manages. Cluster, Instance and Provider columns appear when there is more than one of each, and so do filters for the instance, the destination cluster, the repository’s organization and the provider. Where two Argo CD or two Flux installations run, each application is listed once, under the installation that manages it: the one in the application’s namespace, else for Argo CD the one whose application.namespaces (in argocd-cmd-params-cm) names that namespace, read as Argo CD reads it (a glob such as team-* or [!a]*, or a regular expression between slashes such as /^team-(?!b)/), else the first. A pattern that doesn’t compile matches no namespace, and the server logs it once. The text filter matches names, namespaces, projects, sources and states.

An application that deploys to this cluster links to its page under Applications, with its workloads, pods and logs.

An application

Open a row for its actions:

Sync now: sync the application with what Git has now. Flux doesn’t reconcile a suspended Kustomization or HelmRelease, so KubeGlass says so, with the flux resume command, instead of syncing it; the same goes for Refresh.
Refresh: have it compare with Git again.
Stop sync (Argo CD): stop the sync that is running, as argocd app terminate-op does. It shows while one runs. Flux has no way to stop a reconcile; to keep a Kustomization or HelmRelease from reconciling, suspend it.
Roll back (Argo CD): go back to the deploy before the current one in its sync history, as argocd app rollback does: with the source and parameters that deploy had, without pruning. The line next to the buttons names that revision, and KubeGlass asks before it rolls back. While auto-sync is on, Roll back is off, since Argo CD would sync the application straight back; turn auto-sync off in Argo CD first. To go back with Flux, revert the commit in Git.

They run as you, so your RBAC decides whether they work, and Argo CD’s history names you as who started a sync or rollback. Below them:

Overview: the source (repository, path or chart), ref and revision, the destination namespace and cluster, the project, how many resources it manages and how many of those are synced or out of sync, its parent and children, its instance, and its conditions.
Resources: the objects it manages, by kind, with those that are out of sync or not healthy marked. On this cluster each links to its page.
Events: the application’s recent events.

Other views

Views switches the page to:

Clusters: the clusters the applications deploy to, with how many applications each has and how many are healthy, degraded or out of sync. Click one to list its applications.
Topology: which controller manages which application, and which cluster each deploys to.
Sources: the repositories the applications pull from, with their state and when they were last fetched.

Changing what GitOps manages

When Argo CD or Flux manages an object, its page has a banner that names the application, with View in GitOps. Scaling it, rolling it back, editing its YAML, deleting it and the fixes on a problem say before they run that the next sync can put back what Git has, and that to keep the change you should make it in Git. Restart doesn’t, because it only stamps the pod template, which neither tool reverts.

When Argo CD or Flux made a change, the Timeline names the Git commit its application had synced. An Argo CD Application that is out of sync shows on the Overview with Sync as its fix.

Rollouts

Applications › Rollouts appears when Argo Rollouts is installed. It lists Argo Rollouts with their strategy (canary or blue-green), current step, canary weight, images and analysis runs. It lists the namespace picked in the top bar. On All namespaces it lists the allowed namespaces from your cluster settings when there are any, and every namespace when there are none, and it says which it listed and the namespaces where you may not list Rollouts. From a rollout’s menu you can promote it past its pause, promote it fully (the remaining steps, pauses and analyses are skipped), abort it, retry it after an abort, or restart its pods. Each makes the change kubectl argo rollouts makes, as you, so it needs patch on rollouts or rollouts/status (Argo Rollouts adds both to the built-in edit role). Abort, Promote fully and Restart ask first, and a read-only cluster has no menu.

A plain Deployment’s rollout shows on its own page. On the Overview, Rolling out lists the Deployments, StatefulSets and DaemonSets rolling out now, and a Deployment whose rollout is stuck is under Needs attention.

Helm

Applications