Cluster → namespace → workload hierarchy

EKS cluster
├── Namespace: payments
│   ├── Deployment: payment-api (3 replicas)
│   ├── Deployment: order-service (2 replicas)
│   └── CronJob: nightly-cleanup
├── Namespace: staging
│   ├── Deployment: staging-api (1 replica)
│   └── Deployment: staging-worker (2 replicas)
└── Namespace: kube-system
    └── (system workloads; reserved, never schedulable)

NAVIGATION FLOW:

1. Open Resources
2. Filter type=EKS or GKE or AKS
3. Click into a cluster (child count badge shows its children)
4. View shows the cluster's namespaces and workloads
5. Filter by namespace, kind (deployment/statefulset/cronjob), or name
6. To schedule: pick the NAMESPACE and attach a schedule there
7. To inspect: click a workload for its detail and recommendations

THREE CLICKS from estate-wide view to a namespace you can schedule

DEPLOYMENT / STATEFULSET:
  Name, namespace, kind
  Current replicas, desired replicas
  Pod template:
    Container images
    Resource requests/limits
    Labels and annotations
  Status: Available, Progressing, Updated

CRONJOB:
  Name, namespace
  Schedule (cron expression in K8s syntax)
  Last schedule time
  Active jobs count
  Suspended (boolean)

JOB (one-time):
  Name, namespace
  Completions / Parallelism
  Start time, completion time

NAMESPACE IS THE NATURAL ATTRIBUTION BOUNDARY in K8s

Production / staging / dev separation typically via namespaces
Filtering by namespace = quick access to environment-scoped workloads

COMMON NAMESPACE PATTERNS:
  prod / staging / dev
  team-platform / team-services / team-data
  cluster-autoscaler / kube-system (control plane)
  monitoring / observability

NAMESPACE is the filter that matters most
  Namespace narrows to environment
  It is also the unit you attach a schedule to

DISCOVERED, BUT NOT SCHEDULED:
  Pods, Services and Ingress
  ConfigMaps / Secrets
  NetworkPolicies
  CRDs, PVCs, HPAs, PDBs and more

WHY THEY ARE NOT SCHEDULED:
  They are config/runtime infrastructure
  Not workloads that can be scaled to zero
  Namespace Stop acts on the workloads that run pods

SCHEDULABLE: the namespace (eks-, gke-, aks-namespace)

WHAT NAMESPACE STOP DOES TO EACH KIND INSIDE IT:
  Deployment        (replicas to zero; HPA + PDB deleted, saved)
  StatefulSet       (replicas to zero: careful with PV)
  CronJob           (suspend = true)
  DaemonSet         (evicted via a sentinel nodeSelector)
  KEDA ScaledObject (deleted first, saved, recreated on Start)

NOT SCHEDULABLE:
  Any single workload on its own (schedule its namespace instead)
  Reserved namespaces: default, kube-system, kube-public,
    kube-node-lease, and any name starting kube-, zopnight-,
    istio-, helm-, gke-managed-, gmp-, gatekeeper-, aks-

DEPLOYMENT STATUS:
  Available:   pods are healthy + meeting desired replicas
  Progressing: deployment is updating
  ReplicaFailure: replica set having trouble

HEALTH SIGNALS (from drilling down):
  Restart count (per pod)
  Last restart time
  Crashloop detection
  OOMKilled events

SCHEDULE STATUS:
  Attached to schedule: yes/no (and which)
  Currently in active window: yes/no
  Last action: scale up / scale down / no action

DISCOVERY EVERY 6 HOURS:
  Discoverer fetches all workloads + their current labels
  Refreshes labels and replica counts in ZopNight's record

EFFECT IF YOU ADD OR REMOVE A LABEL:
  Next discovery: the workload's labels are updated
  Group membership does NOT change
  Schedule attachment does NOT change

WHAT CONTROLS SCHEDULING:
  Schedules are attached explicitly to a namespace,
  or to a group whose members you added by hand

A SERVICE may run in multiple clusters:
  prod-eks-us-east-1
  prod-eks-eu-west-1
  prod-eks-ap-south-1

ZopNight discovers each cluster's instance separately
  Each has its own workload entry
  Each cluster's namespace can be scheduled separately

GROUP across clusters:
  Add each cluster's payments-api namespace to one group by hand
  Attach the schedule to the group
  Single schedule applies to all members

SEE L6 (cross-cluster) for the pattern in depth

T+0       Inventory page → filter type=EKS → 6 clusters
T+5s      Click prod-eks-1 (28 workloads)
T+10s     Filter namespace=staging (8 workloads)
T+12s     Filter kind=Deployment (6 deployments)
T+15s     Click "staging-orders-svc" to check it
            Replicas: 4 (max 6, configured by HPA)
            Image: registry.io/orders-svc:1.2.3
            Container resources:
              Requests: 500m CPU, 1 GB RAM
              Limits:   1000m CPU, 2 GB RAM
            Status: Available, Progressing
T+18s     Back to the staging namespace → Attach Schedule
            → pick "business-hours-staging"
T+25s     Schedule attached. All 8 staging workloads,
          staging-orders-svc included, scale to zero off-hours.

OUTCOME:
  25 seconds from estate view to namespace scheduling
  No complex search; predictable hierarchy
  Engineer-friendly navigation

□ STEP 1: Open Resources; filter type=EKS/GKE/AKS
  Cluster count: _____

□ STEP 2: Pick one cluster; click in
  Workload count: _____
  Namespaces: _____

□ STEP 3: Filter to non-prod namespace
  Workloads visible: _____

□ STEP 4: Pick one Deployment
  Replicas: _____
  Resource requests: __________
  Its namespace: __________

□ STEP 5: Identify schedulable namespaces in cluster
  Total namespaces: _____
  Schedulable (not reserved, not prod): _____
  Already scheduled: _____
  Could schedule: _____