Outcome
By the end of this lesson, you will be able to navigate the parent-child hierarchy in the resource list and drill from a cluster to its individual child workloads in three or fewer clicks.
| Prerequisites | L1 |
| Time | 10 minutes |
1. Concept
Cloud resources come in nests, not in a flat list.
A Kubernetes cluster holds groups of machines, and those groups hold the machines themselves. The same cluster separately holds the applications running on it. An Azure Databricks workspace holds clusters, instance pools and SQL warehouses. An ECS cluster holds services, and each service holds the tasks doing the work.
ZopNight works out which things belong to which, and lets you navigate down through them. Throughout this lesson, a parent is the thing that contains, and a child is what it contains.
The hierarchy model
TOP-LEVEL PARENT CHILDREN (one level down)─────────────────────────────────────────────────────────────EKS / GKE / AKS cluster → Nodegroup, Deployment, STS, CronJobECS cluster → Service, Task definition, Container instanceDatabricks Workspace → Cluster, Instance Pool, SQL WarehouseECR repository → ImageArtifact Registry repository → ImageCloudWatch → Log GroupRDS instance → Read replica (if any)ASG → Instance, Scheduled actionSome hierarchies go three levels deep:
LEVEL 1 LEVEL 2 LEVEL 3─────────────────────────────────────────────────────────EKS cluster → Nodegroup → EC2 instanceGKE cluster → Node pool → GCE instanceAKS cluster → Node pool → Azure VMSome types have no natural parent, so ZopNight files them under grouping folders it creates for the list, such as EBS Snapshots, RDS Snapshots, Disk Snapshots (GCP and Azure), Security Groups, Network Security Groups, VNet Peerings, Security Services and Developer Tools. These folders are not cloud resources. A snapshot whose source disk or database still exists sits under it; the rest go into the folder. You drill into a folder like any other parent.
The default Inventory view shows parents only. Each parent carries a child count badge. Clicking the badge or the parent itself drills into the children.
The default view
RESOURCES → Parents view (default)
NAME TYPE CHILDREN STATUS─────────────────────────────────────────────────────────────────prod-eks-cluster eks 3 child → Runningstaging-databricks-ws databricks 12 child → Runningprod-ecr-payments ecr 847 child → -prod-rds-payments rds 1 read replica → Availablebuild-asg-x86 asg 8 instances → RunningThat count is a link. Click “3 child” on prod-eks-cluster and the page becomes that cluster’s contents: its machine groups and its workloads, and nothing from anywhere else.
Breadcrumbs and scope
When viewing children, a breadcrumb shows the path:
Resources > prod-eks-cluster > Nodegroup: gp-nodes-1 > Instances
Each segment is clickable. Click "prod-eks-cluster" to return to its children.Click "Resources" to return to the all-parents view.Nothing is a dead end. Three levels down, you can step back one at a time or jump straight to the top.
Filters narrow per scope
Filters describe where you are, not the whole estate. Inside prod-eks-cluster, the Type filter offers only the four kinds of thing that cluster actually contains, rather than all 230+. You are never scrolling past types that cannot appear here.
Search overrides scope
Search is the exception. It looks across the whole estate and returns matches whatever they belong to, which is what you want when you know the name and have forgotten where it lives.
Why parent-child matters for scheduling
In Kubernetes, the unit you schedule is the namespace. Individual workloads (Deployments, StatefulSets, CronJobs) are listed as children so you can see them, but they cannot be scheduled one by one. To stop one team’s workloads outside working hours, you go:
Resources → prod-eks-cluster → reporting (namespace) → Schedules tab → attachWhole clusters and nodegroups can be scheduled too, but stopping the whole cluster would take the production applications down with it, which is almost never what anybody meant. Navigating into the cluster first makes the smaller, correct action, the namespace, the obvious one.
The same applies to Databricks. A team can schedule individual Databricks clusters or SQL warehouses off-hours without affecting other workspace components.
Why parent-child matters for cost
Cost attribution rolls up the hierarchy. A nodegroup’s cost is the sum of its instances. A cluster’s cost is the sum of its nodegroups. The Inventory page shows the rolled-up monthly cost on the parent row and the per-child cost when drilled into the children.
prod-eks-cluster Monthly: $14,300 └── gp-nodes-1 (nodegroup) Monthly: $11,400 └── i-0abc1 (instance) Monthly: $722 └── i-0abc2 (instance) Monthly: $722 └──... └── memory-nodes (nodegroup) Monthly: $2,900 └── i-0xyz1 (instance) Monthly: $972 └──... └── cronjob-daily-report Monthly: included in nodegroupThe job has no compute cost of its own, because it runs on machines the group is already paying for. It still appears here, because you need something to point at when you talk about it.
2. Demo
A typical navigation path:
SCENARIO: Find and schedule the namespace that runs the reporting jobs
T+0 Open Inventory page (Parents view)T+5 s Find "prod-eks-cluster" with "12 child →" badgeT+8 s Click "12 child →" Breadcrumb: Resources > prod-eks-cluster View: 12 children (4 nodegroups, 3 namespaces, 5 workloads)T+12 s Filter Type=namespace, search "report" View narrowed to 1 namespace: reportingT+15 s Click the namespace row Detail panel opens: shows resource UID, parent cluster, schedules, costT+18 s Schedules tab → attach → pick "Weekends Off"T+22 s Confirm Schedule attached. The reporting namespace will be stopped on weekends.22 seconds from estate view to scheduled. The hierarchy makes this fast.
3. Hands-on (7 min)
For your own estate:
1. Open Resources. Identify any parent with children (cluster, ECS service, Databricks workspace, ASG, ECR repo).2. Click the child count badge to drill in.3. Note the breadcrumb at the top of the page.4. Apply a filter (e.g., Type=Deployment).5. Confirm the filter scope is local to this parent: toggle back to the parent view and observe how the filter availability changes.6. Use the search bar to find a specific resource by name.7. Confirm search overrides scope: even if you're inside one cluster, search returns matches from across the estate.The exercise builds muscle memory for the navigation. Drill and back out multiple times.
4. Knowledge check
Q1
A team wants to stop the Kubernetes workloads in one namespace outside business hours. The right navigation path is:
A. Schedule the entire EKS cluster off, which will take every other workload down with it as well
B. Use the AWS console
C. Delete the namespace
D. Drill into the cluster’s children, find that namespace, and attach a schedule to the namespace
Show answer
Correct: D. The namespace is the Kubernetes unit you schedule, and the hierarchy is how you reach it. Scheduling the entire cluster would stop production workloads too.
Q2
A user is three levels deep (Resources > Cluster > Nodegroup > Instances) and wants to return to the cluster level. The most efficient way is:
A. Click the “Cluster” segment in the breadcrumb
B. Use the browser back button twice
C. Navigate back from the Resources homepage
D. Refresh the page
Show answer
Correct: A. The breadcrumb is how you move around parent-child hierarchies. Breadcrumb segments are clickable navigation. This is the designed navigation pattern.
Q3
Inside a children view (one specific cluster’s children), the Type filter shows only types present in this cluster (not the full 230+ list). This is:
A. A bug
B. Intentional: filters are scoped to the current view to keep the UI relevant
C. Inconsistent with the rest of the product experience overall in the UI
D. A limitation
Show answer
Correct: B. Search, by contrast, overrides scope and operates across the entire estate. Filters narrow per scope; search overrides scope. This is the designed behavior because each one serves a different intent.
5. Apply
The Inventory page implements the hierarchy as:
- Default Parents view with child-count badges per parent
- Click child badge → Children view with breadcrumb navigation
- Per-scope filters that adapt to the current view
- Global search that overrides scope
For specific workload patterns:
- K8s namespaces and workloads (Deployments, StatefulSets, CronJobs) are children of their cluster; the namespace is what you schedule
- Databricks (Clusters, Pools, SQL Warehouses) are children of their workspace