Kubernetes Cost Optimization Inside the Cluster — Namespaces, Workloads and Waste
What does the Kubernetes integration do?
Kubernetes is scored by 24 rules over 29 object types. Only Nodes carry a direct cloud bill and only PersistentVolumes carry a storage one. Everything else costs nothing itself but reserves node capacity through requests, which is where almost all Kubernetes waste actually originates.
Coverage by category
Cloud bills say ‘node group’; engineers think in namespaces and deployments. ZopNight bridges that gap by discovering 29 Kubernetes resource types inside every EKS, GKE and AKS cluster it can reach (deployments, statefulsets, cronjobs, HPAs, PDBs, PVCs, services, ingresses, RBAC and more) and scheduling whole namespaces off-hours: workloads scale to zero, CronJobs suspend, HPAs and PodDisruptionBudgets are removed and faithfully restored, and KEDA ScaledObjects are handled correctly.
Cluster access minted from your cloud credentials
There is nothing separate to install and no kubeconfig to upload. ZopNight mints cluster access at use time from your cloud credentials: an EKS access entry with a presigned STS token on AWS, OAuth on GKE, and cluster-user credentials on AKS. It needs only list permissions on the standard API groups. Namespace scheduling snapshots the state of every workload before scaling down and restores it exactly on start; system namespaces are always excluded.
Connect the cloud account, then group namespaces
- Connect the cloud account (AWS, GCP or Azure) with the Kubernetes permissions included in the standard setup.
- On AWS, attach the EKS Cluster Policy access entry (one console step, shown in the guide).
- Clusters and their workloads appear in discovery within one cycle.
- Group namespaces into resource groups and attach schedules.
Workload types covered, and scheduling by namespace
29 in-cluster resource types discovered per cluster with security posture enrichment (probes, root/privileged containers, host network, TLS on ingress). Namespace-boundary scheduling with full state restoration and KEDA awareness. Live pod logs, events and metrics through the ZopNight UI and MCP tools. 24 recommendation rules per provider covering reliability (missing probes/limits, single replicas, latest tags), security (no-TLS ingress, privileged pods), idle workloads and orphaned PVCs. Workload rows re-slice node spend for honest cost attribution.
Limits worth knowing before you connect
Scheduling is namespace-level by design; individual workload scheduling is not offered. Pods, ConfigMaps, Secrets and Events are aggregated as counts rather than stored as rows. Reserved namespaces (kube-system and friends) are never scheduled.
Kubernetes integration: common questions
Do I need to install an agent or upload a kubeconfig?
Neither. ZopNight mints cluster access at use time from the cloud credentials you already connected: an EKS access entry with a presigned STS token on AWS, OAuth on GKE, and cluster-user credentials on AKS. It needs only list permissions on the standard API groups.
Can I schedule a single deployment off-hours?
No, scheduling is namespace-level by design. A namespace scale-down takes every Deployment and StatefulSet to zero, suspends CronJobs, removes HPAs and PodDisruptionBudgets, handles KEDA ScaledObjects, and restores the snapshot exactly on start.
Could a schedule ever scale down kube-system?
No. Reserved namespaces such as kube-system are excluded from scheduling entirely, so they cannot be attached to a schedule by accident.
Recommendations
24 live rule families evaluate Kubernetes spend. Each page documents the metric, threshold, window, and the IAM actions the check needs.
Scheduling
1 Kubernetes resource types can be stopped and started on a schedule.