Custom Resource Definition (CRD)

The PrometheusRule CRD, defined by the Prometheus Operator, allows users to declaratively manage alerting and recording rules for the Prometheus monitoring system. Instead of editing static configuration files, rules are defined as Kubernetes objects.

• Key Fields: groups containing lists of rules with expr (PromQL expression) and for (duration) fields.
• Controller: The Prometheus Operator watches for these objects and dynamically updates the Prometheus configuration.
• Benefit: Enables GitOps for monitoring; rules can be versioned, rolled back, and applied via standard kubectl commands.

The VirtualService CRD is a core component of the Istio service mesh, defining rules for how traffic is routed to a service. It decouples traffic routing from service discovery, enabling advanced deployment patterns.

• Key Capabilities: Specifies traffic splitting (e.g., 90% to v1, 10% to v2), fault injection (delays/aborts), retry policies, and timeouts.
• Abstraction Layer: Operates alongside the DestinationRule CRD, which defines subsets and load balancing policies.
• Use Case: Essential for implementing canary deployments, A/B testing, and circuit breaking within a microservices architecture.

The PostgresCluster CRD, managed by the Crunchy Data Postgres Operator, defines a complete, production-ready PostgreSQL cluster within Kubernetes. It encapsulates the entire stack.

• Managed State: Defines specifications for instances, replication, backups, PGBouncer connection pooling, and monitoring.
• Automated Operations: The associated controller handles complex lifecycle tasks: failover, point-in-time recovery, minor version updates, and persistent volume management.
• Example: A single YAML manifest can provision a highly available cluster with a primary, two replicas, and scheduled backups to cloud storage.

The TensorFlowModel CRD, used by frameworks like KFServing/KServe, provides a declarative interface for serving machine learning models. It abstracts the underlying inference server deployment.

• Specification: Includes fields for the model URI (e.g., s3://bucket/model), framework (tensorflow, pytorch), resource requirements, and scaling parameters.
• Automated Serving: The controller provisions the necessary inference server (e.g., TensorFlow Serving) as a Kubernetes Deployment and Service, often with autoscaling enabled.
• Benefit: Standardizes ML model deployment, enabling CI/CD for models and multi-model serving on shared infrastructure.

The Certificate CRD is defined by cert-manager, a native Kubernetes certificate management controller. It is used to automatically provision and renew TLS certificates from various issuers.

• Declarative TLS: A user defines a desired certificate (DNS names, secret name, issuer reference). cert-manager handles the entire lifecycle.
• Issuer Types: Works with Issuer or ClusterIssuer CRDs configured for sources like Let's Encrypt (ACME), HashiCorp Vault, or private PKI.
• Automation: Automatically creates CertificateSigningRequests, performs domain validation (e.g., HTTP-01 challenge), and stores the signed certificate and private key in a Kubernetes Secret. This eliminates manual certificate renewal operations.

The CronTab CRD is the classic example from the Kubernetes documentation, used to illustrate the basic mechanics of defining and using a custom resource. It represents a simplified cron job.

• Schema: A simple spec with cronSpec (schedule string) and image (container image to run).
• Purpose: Demonstrates the separation of the API extension (CRD) from the business logic (a custom controller).
• Learning Value: The associated controller would watch for CronTab objects and create Kubernetes Job or CronJob resources based on the defined schedule. This example highlights how CRDs model application-specific concepts.

The Operator Pattern is a Kubernetes extension method that uses a custom controller paired with one or more Custom Resource Definitions (CRDs) to encode domain-specific operational knowledge. This pattern automates complex lifecycle tasks for applications, turning manual procedures into code.

• Core Concept: An operator acts as an automated Site Reliability Engineer (SRE) for its application.
• Custom Controller: A control loop that watches the state of your custom resources and takes action to reconcile the actual state with the desired state declared in the CRD.
• Use Case: For Edge AI, an operator could manage the full lifecycle of a machine learning model—deploying it, monitoring its performance, scaling it based on inference load, and performing rolling updates to a new version.

API Aggregation is a Kubernetes feature that allows installing additional, specialized API servers behind the main Kubernetes API server. While CRDs extend the API by adding new resource types to the existing API server, API aggregation adds entirely new API groups and endpoints.

• Comparison with CRDs: CRDs are simpler and are sufficient for most custom resource needs. Aggregated APIs (AA) are more complex but offer full control over the API logic, storage, and versioning.
• When to Use: Use a CRD when your resource can be represented as a standard Kubernetes API object. Consider an Aggregated API for advanced features like custom storage backends, protobuf encoding, or subresource support (e.g., /exec, /logs) on your custom resource.