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 specific groups, keda.sh via v1alpha1 among them, to switch on KEDA-aware namespace scheduling.
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 detection that changes platform behavior
ZopNight reads the CRD inventory for 1 decision in particular: whether KEDA is present. Clusters with the keda.sh definitions get KEDA-aware namespace scheduling, where ScaledObjects are discovered and coordinated with instead of fought, while clusters without them skip that machinery entirely. Extension detection driving behavior is the pattern; KEDA is the current instance of it.
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.