Clusters and Environments

Clusters and Environments

This document describes the actual current cluster target for GloriousFlywheel and how the repo’s logical deployment environments map onto it.

Physical Cluster Truth

There is one Kubernetes cluster in the current on-prem rollout:

Physical Cluster Role Access Current Status
honey control plane and operator-facing services private, tailnet-first kubeconfig primary deployment target

Important:

  • bumble and sting are not separate clusters
  • bumble and sting are worker or storage nodes inside honey
  • tinyland-civo-dev was a Civo compatibility context (decommissioned April 2026)

Primary operator access:

  • kubeconfig: ~/.kube/kubeconfig-honey.yaml
  • context: honey
  • API server: https://100.113.89.12:6443

Logical Deployment Environments

GloriousFlywheel still uses logical environment names such as dev and prod inside config/organization.yaml, stack tfvars, and ENV=... recipes.

Those environment names do not imply separate physical clusters anymore.

Logical Env Intended Role Physical Cluster Default Context
dev active development and canary rollout honey honey
prod stricter operator or production intent honey honey

The difference between dev and prod is deployment intent, domains, state separation, and tfvars. It is not a different Kubernetes API endpoint.

Node Roles And Placement

Node Role Placement Bias
honey control plane, primary state anchor, operator-facing services dashboard, operator surfaces, control-plane integrations
bumble durable bulk storage and stateful backends OpenEBS ZFS-backed volumes, durable state, storage-heavy services
sting protected stateless compute expansion explicit low-blast-radius compute workloads and burstable stateless capacity

Canonical placement sentence:

Move runner/control workloads into the honey cluster only, keep them tailnet-only, put durable backing state on bumble, and use sting only for explicit stateless compute capacity.

Namespace Layout

Each functional component still runs in its own namespace to provide resource isolation and RBAC boundaries.

Primary namespaces:

  • attic-cache-dev or attic-cache
  • arc-systems
  • arc-runners
  • runner-dashboard
  • gitlab-runners only if the legacy GitLab runner path is still in use

Authentication And Access

Primary local operator model:

  • kubeconfig from ~/.kube/kubeconfig-honey.yaml
  • KUBECONFIG or k8s_config_path
  • cluster_context = "honey"
  • tailnet-private API access

Compatibility paths:

  • tinyland-civo-dev was Civo cloud compatibility (decommissioned April 2026)
  • SOCKS proxy only when tailnet or direct private access is unavailable
  • GitLab Agent only for legacy GitLab-oriented surfaces, not as the primary GloriousFlywheel deployment contract

Stateful Backends And Storage

Stateful backing services should assume durable placement on bumble where possible. That includes:

  • PostgreSQL and other durable metadata stores
  • object storage and cache backing volumes
  • storage-heavy observability or cache-adjacent components

Civo has been decommissioned (April 2026); there is no remaining Civo dependency.

Validation

Recommended checks before applying GloriousFlywheel locally:

kubectl --context honey cluster-info
kubectl --context honey get nodes -o wide
just cluster-access-audit-local
just onprem-baseline-check

GloriousFlywheel