cub cluster k8sbot-install

Install argobot in a cluster wired into ConfigHub

Synopsis

Installs argobot in a cluster attached without it ("cub cluster attach --no-k8sbot" or "cub cluster up --no-k8sbot"). It is the last part of "cub cluster attach", which runs it unless --no-k8sbot is given.

argobot is a bot that listens on a Channel and has the controller deploy a Release the moment it is published, instead of waiting for its poll: it force-syncs the matching Argo CD Application, redeploys the Sveltos ClusterProfile, or reconciles the Flux OCIRepository. It also reports each Release's live status, and stores facts about the cluster on its target.

In ConfigHub:

argobot-base argobot's shared base Space, installed from the deployment for the controller that argobot's newest release image carries, or with --k8sbot-installer, with ConfigHub's installer from argobot's installer package ("argobot-sveltos-base" and "argobot-flux-base" for Sveltos and Flux). When it exists already, --k8sbot-base says whether to update it first or clone it as it is. argobot- the cluster's downstream variant of it, released to the cluster's target, whose deployment "cub variant create" adds to the apps Space like any other. /argobot the Channel argobot listens on, in the cluster Space, delivering the release.published events of the Spaces that release to the target. The cluster's service account is granted Claim on it.

argobot runs as the cluster's service account, with the key in the argobot-secrets Secret that "cub cluster svc-account-bootstrap" applied; one is issued and applied here when the cluster has none. A Secret already there, such as one a secret store keeps, is used as it is, and has to hold the key as CONFIGHUB_AUTH_PRIVATE_KEY. With --secrets-dir

the Kubernetes manifest of the Secret holding an issued key (with the argobot Namespace, which is applied) is written to //argobot_argobot-secrets.yaml instead of being applied, for the store to put in the cluster, and a manifest written there before is used rather than another key issued; argobot cannot start until the Secret is in the cluster.

The apps Space's Release is published with argobot in it, so the root deploys it, and with Argo CD the root is asked to refresh at once. A Sveltos or Flux cluster attached without argobot polls its Releases every minute; with argobot that is only a fallback, so the root, the target, and every deployment created from here on move to polling every 10 minutes, as for a cluster attached with argobot. Deployments that already exist keep polling every minute.

"cub cluster detach" removes argobot along with the rest of the wiring.

cub cluster k8sbot-install <name> [flags]

Options

  -h, --help                 help for k8sbot-install
      --k8sbot-base string   what to do with argobot's shared base Space when it already exists: update (install argobot's newest release over it, then clone it) or clone (clone it as it is); asked when stdin is a terminal, otherwise update
      --k8sbot-installer     install argobot's shared base Space with ConfigHub's installer, from its installer package, rather than from the deployment its image carries; needs the installer cub plugin (cub plugin install confighub/installer)
      --registry string      where to pull argobot's image from: ghcr, gcr, or a mirror prefix holding <prefix>/argobot, and <prefix>/packages/argobot for --k8sbot-installer (default ghcr)
      --secrets-dir string   write the Secrets holding ConfigHub credentials (argobot's key, the controller's pull token) to this directory as Kubernetes Secret manifests instead of applying them, for a secret store, such as the External Secrets Operator, to put in the cluster

Options inherited from parent commands

      --context string   The context to use for this command
      --debug            Debug output

cub cluster k8sbot-install