Kubernetes Cost Optimization Inside the Cluster — Namespaces, Workloads and Waste
What does the Kubernetes integration do?
Kubernetes coverage spans 29 object types, most of them checked by reliability, security and waste rules. Nodes, PersistentVolumes and LoadBalancer Services map to direct cloud charges of their own. 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 restored from saved copies, and KEDA ScaledObjects are deleted for the window (manifests saved) and recreated once the workloads are back.
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 (falling back to cluster-admin credentials when user credentials are not allowed). Discovery only reads, but namespace scheduling writes: it patches Deployments, StatefulSets, CronJobs and DaemonSets, and deletes and recreates HPAs, PDBs and KEDA ScaledObjects. On EKS the guided setup attaches AmazonEKSClusterAdminPolicy at cluster scope through the access entry. Namespace scheduling records each workload’s replica count, CronJob suspend flag, DaemonSet node selector and matching HPA, PDB and ScaledObject before scaling down, and restores them 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, create the EKS access entry with AmazonEKSClusterAdminPolicy at cluster scope (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 that saves and restores workload state, with KEDA awareness. Live pod logs, events and metrics through the ZopNight UI and MCP tools. Recommendation rules 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 and Events are not stored as rows; pods appear as a count on each namespace. ConfigMaps and Secrets are stored as rows with key names and metadata (namespace, labels, key count, Secret type), never values. Live detail views fetch values from the cluster on request, and Secret values are stripped for Viewer and Editor roles. 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. Discovery only reads, but namespace scheduling writes: it patches workloads and deletes and recreates HPAs, PDBs and KEDA ScaledObjects, so on EKS the guided setup attaches AmazonEKSClusterAdminPolicy through the access entry.
Can I schedule a single deployment off-hours?
No, scheduling is namespace-level by design. A namespace scale-down deletes KEDA ScaledObjects first, since KEDA can scale a workload up from zero, then takes every Deployment and StatefulSet to zero and suspends CronJobs. HPAs and PodDisruptionBudgets are saved and removed as housekeeping, and the saved state is restored 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
53 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.