# Kubernetes Cost Optimization Inside the Cluster — Namespaces, Workloads and Waste

> ZopNight looks inside EKS, GKE and AKS: 29 workload types discovered, namespace-level off-hours scheduling, and 43 reliability, security and waste rules per cluster.

Source: https://zop.dev/integrations/kubernetes
Updated: 2026-08-20

---

## 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.

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

1. Connect the cloud account (AWS, GCP or Azure) with the Kubernetes permissions included in the standard setup.
2. On AWS, attach the EKS Cluster Policy access entry (one console step, shown in the guide).
3. Clusters and their workloads appear in discovery within one cycle.
4. 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.