CustomResourceDefinition
Does ZopNight manage CustomResourceDefinition?
CustomResourceDefinitions add new API types, and their inventory reads like a manifest of installed operators. ZopNight records group, kind, scope, and served versions for each CRD, marks definitions established once the API serves them, and uses the keda.sh group to report whether KEDA is installed; namespace scheduling does not depend on it.
Rules that fire on CustomResourceDefinition
No active rule family targets CustomResourceDefinition today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A CustomResourceDefinition teaches the Kubernetes API a new object type. CRDs are how operators extend a cluster. Install cert-manager, KEDA, or a service mesh and each arrives as a set of definitions, so the CRD list reads as a manifest of what else is running and making decisions in the cluster.
An inventory of operators, read from the API
Discovery records each CRD’s group, kind, scope, and served versions. The group alone identifies most operators at a glance: keda.sh means event-driven autoscaling is installed, cert-manager.io means certificates are automated, monitoring.coreos.com means Prometheus. Since every controller behind those groups runs pods, holds leases, and sometimes provisions cloud resources, the CRD inventory is the cheapest available answer to what software has authority here.
Established, or defined but not served
A CRD that the API server has validated and begun serving carries the Established condition, and discovery promotes that to the resource’s status; definitions still settling report as merely active. The distinction is a useful health check after operator installs: a chart that applied its CRDs but whose definitions never established leaves every dependent custom resource unservable.
Scope: the field that decides where instances live
Each definition declares whether its instances are Namespaced or Cluster scoped, and discovery keeps that field verbatim. Scope determines cleanup semantics (namespaced custom resources die with their namespace, cluster-scoped ones need explicit deletion), and it determines who can create instances under a given RBAC setup, which is why the field matters to more than taxonomists.
The KEDA check, and what it does not switch
ZopNight checks for the keda.sh definitions to report whether KEDA is installed and whether its scaling rules can be listed. Namespace scheduling does not wait on that check: at stop it lists the namespace’s KEDA ScaledObjects directly (an empty list when KEDA is absent), saves and deletes them first so KEDA cannot scale workloads back up, and recreates them at start.
kubectl get crds -o custom-columns=NAME:.metadata.name,GROUP:.spec.group,KIND:.spec.names.kind,SCOPE:.spec.scope,VERSIONS:.spec.versions[*].nameReviewing the list occasionally pays: CRDs from uninstalled operators linger indefinitely, and orphaned definitions with live instances are configuration that no controller reconciles anymore.