Custom Resource Definition (CRD)

A CRD defines a new RESTful API endpoint in Kubernetes by specifying an OpenAPI v3 schema. This schema enforces strict validation on the desired state of custom resources, ensuring that every instance of a network function—such as a distributed unit (DU) or centralized unit (CU)—conforms to a well-defined structural contract before it is persisted to etcd. The schema specifies required fields, data types, and immutable constraints, preventing configuration drift at the point of ingestion.

Once a CRD is registered, users can create, read, update, and delete (CRUD) instances of the custom resource via kubectl or the API. Each instance represents a declarative intent for a specific domain object. The system tracks the resource's observed state through a status subresource, which is kept strictly separate from the desired spec. This separation is critical for implementing the reconciliation loop pattern, where a controller continuously drives the observed state toward the desired state.

A CRD becomes operationally powerful when paired with a Kubernetes Operator. The operator contains a control loop that watches for changes to custom resources and executes domain-specific logic to reconcile state. For example, an O-RAN operator might watch an ORANRU custom resource and automatically provision a physical radio unit. This pattern encodes human operational knowledge into software, enabling fully automated Day 0 and Day 2 operations for telecom infrastructure.

CRDs support multiple API versions simultaneously, allowing for the evolution of a resource's schema without breaking existing clients. A conversion webhook can be deployed to translate resources between versions on-the-fly. This is essential for telecom operators managing long-lived infrastructure, as it allows a network service descriptor to be upgraded from v1alpha1 to v1 while maintaining backward compatibility for all existing instances of the resource in the cluster.

Custom resources are fully integrated with Kubernetes' Role-Based Access Control (RBAC) system. Cluster administrators can define fine-grained permissions for each custom resource type, controlling which users or service accounts can create, modify, or delete specific network functions. This ensures that a team managing O-RAN Central Units cannot inadvertently modify resources belonging to the Distributed Unit team, enforcing a strict separation of concerns within a shared multi-tenant cluster.

CRDs can expose standard /status and /scale subresources. The status subresource enables a controller to write the current operational state of a resource without having permission to modify the user-defined spec, preventing feedback loops. The scale subresource allows a custom resource to be horizontally scaled using kubectl scale, integrating with the Horizontal Pod Autoscaler. This is used to dynamically adjust the capacity of cloud-native network functions based on real-time traffic load.

A software extension that uses Custom Resources to manage applications and their components. It encodes human operational knowledge into a control loop, automating the entire lifecycle of a stateful workload.

• Watches a CRD instance for changes
• Runs a reconciliation loop to drive observed state toward desired state
• Handles Day 2 Operations like scaling, backup, and upgrades without manual intervention

A continuous control mechanism that compares the observed state of a resource against its desired state declared in a CRD instance. If drift is detected, the loop automatically executes corrective actions.

• Core pattern in declarative configuration
• Ensures idempotency—applying the same spec twice yields the same result
• Used by every Kubernetes Operator to enforce intent

A provisioning model where the desired end-state of a resource is specified in a YAML or JSON manifest, and an automated engine determines the sequence of steps to achieve that state.

• Contrasts with imperative scripting
• A CRD is the schema that defines what a valid declaration looks like
• Enables GitOps workflows where Git is the single source of truth

An operational framework that uses a Git repository as the single source of truth for declarative infrastructure and application configurations. An automated reconciliation agent continuously enforces the desired state stored in Git onto the target cluster.

• CRDs define the custom resources stored in Git
• Tools like Argo CD and Flux implement the reconciliation loop
• Every change is version-controlled, auditable, and rollback-ready

The practice of managing and provisioning computing infrastructure through machine-readable definition files rather than physical hardware configuration or interactive tools.

• CRDs extend IaC principles to domain-specific resources like Network Service Descriptors
• Enables versioning, testing, and automated deployment of network functions
• Forms the foundation for immutable infrastructure patterns

The automated process of detecting and correcting unauthorized or unintended changes to a system's configuration, restoring it to its declared desired state.

• A CRD's spec field defines the desired state; the status field reports observed state
• The reconciliation loop detects any mismatch between spec and status
• Critical for maintaining compliance in zero-touch provisioning environments