请解释Kubernetes中Custom Resource Definitions(CRDs)的定义、作用及应用

CRDs是Kubernetes的核心扩展机制，允许你在集群中定义专属的自定义资源类型——就像K8s原生的Pod、Deployment一样，你可以创建比如RedisCluster、MLModel这类贴合业务场景的新资源。

定义完成后，你就能用和原生资源完全一致的方式操作它们，比如写这样的YAML创建实例：

apiVersion: example.com/v1
kind: RedisCluster
metadata:
  name: my-redis-cluster
spec:
  replicas: 3
  memory: 2Gi

之后用kubectl apply -f提交，用kubectl get redisclusters查看状态，和操作原生资源毫无差异。

• 零代码扩展K8s能力：不用修改K8s核心源码，就能让集群适配特定领域的业务需求，比如中间件运维、机器学习部署等。
• 统一资源管理入口：把业务专属组件纳入K8s的管理体系，用kubectl和K8s API统一操作，不用再维护独立的运维工具链。
• 实现声明式运维：和原生资源一样，用YAML声明你想要的最终状态，由对应的自定义控制器自动完成状态落地（比如创建Redis集群、配置服务网格规则）。
• 复用K8s生态：自定义资源可以无缝对接RBAC权限控制、Prometheus监控、日志采集等现有生态组件，不用重复造轮子。

• 中间件自助运维：云厂商或内部平台团队可以定义MySQLInstance、KafkaCluster等CRD，用户只需提交YAML声明实例规格，后台控制器就会自动完成实例创建、扩容、备份、故障自愈等操作，无需手动运维中间件。
• 服务网格配置：比如Istio用VirtualService、DestinationRule等CRD来管理流量路由、熔断、镜像等策略，用户通过K8s API就能配置服务网格规则，无需学习独立的Istio工具。
• CI/CD流程K8s化：定义Pipeline类型的CRD，把代码构建、镜像推送、集群部署的流程封装成自定义资源，用户提交YAML就能触发流水线，实现CI/CD流程的统一管理。
• 自定义监控告警：定义CustomMetric、AlertRule等CRD，用户通过K8s API声明监控指标和告警规则，后台控制器自动同步到Prometheus、Alertmanager中，统一管理监控配置。
• 机器学习模型运维：定义MLModel类型的CRD，声明模型镜像、资源需求、推理端口等信息，控制器自动完成模型部署、扩缩容、版本切换，把ML运维纳入K8s体系。

内容的提问来源于stack exchange，提问作者prasanth