How is CRD (Custom Resource Definition) related to…

CRD (Custom Resource Definition) in Kubernetes allows defining and using custom resources, extending the Kubernetes API. It is key to creating systems that behave in a "cloud-native" manner.

CRD functionalities:

API extensibility of Kubernetes: Developers can create their own types of Kubernetes objects, managed just like built-in ones (Pods, Services, etc.).
Declarative management: Custom resources describe the desired state of an application or infrastructure, and Kubernetes controllers (often written to manage these CRDs) ensure its achievement.
Integration with the Kubernetes ecosystem: Custom resources can be used with other Kubernetes tools such as kubectl, RBAC, metrics, etc.
Creating domain-specific operators: CRDs are the foundation for creating Kubernetes operators that automate management of complex Stateful applications or cloud resources. An operator "understands" your application's logic and manages its lifecycle based on the CRD state.

Relation to cloud technologies:

Managing cloud provider resources: CRDs enable managing external cloud provider resources (AWS EKS/EC2/S3, GCP GKE/GCE/GCS, Azure AKS/VM/Blob Storage) directly through the Kubernetes API. Instead of using cloud provider APIs or consoles, you declare the desired state in a CRD, and the corresponding controller synchronizes it.
Abstraction of cloud services: With CRDs, you can create abstractions over provider-specific services, providing a unified interface for developers working across multiple clouds or hybrid environments. For example, a CRD for a database can abstract RDS in AWS, Cloud SQL in GCP, or Azure SQL Database.
Creating cloud-native applications: CRDs encourage the development of applications designed with cloud features in mind (scalability, fault tolerance), allowing management logic for these features to be embedded directly into the Kubernetes cluster.

Example CRD for managing a simple database:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: databases.stable.example.com
spec:
  group: stable.example.com
  versions:
    - name: v1
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                size:
                  type: string # For example, "small", "medium", "large"
                storage:
                  type: string # For example, "5Gi", "10Gi"
            status:
              type: object
              properties:
                state:
                  type: string # For example, "Provisioning", "Running", "Error"
  scope: Namespaced
  names:
    plural: databases
    singular: database
    kind: Database
    shortNames:
    - db

Example of using this CRD:

apiVersion: stable.example.com/v1
kind: Database
metadata:
  name: mydb
spec:
  size: medium
  storage: 10Gi

The corresponding controller (written for this CRD) will monitor objects of type Database and create/configure the actual database (e.g., in the cloud) based on the spec fields.

How is CRD (Custom Resource Definition) related to cloud technologies and what is its functionality?