CRD本身是Kubernetes内置的资源类型，全称是CustomResourceDefinition，可以通过命令查看，kubectl get查看集群内定义的CRD资源。
NAME CREATED AT
apps.app.o0w0o.cn 2019-07-25T07:02:47Z
microservices.app.o0w0o.cn 2019-07-25T07:02:47Z在与人们谈论CRD时，我发现人们对CRD存在一些常见的误解，因此需要提前澄清一些概念：
- 在 Kubernetes 中，一切都称为资源，如 Yaml 中的 Kind 项所述。
- 但除了 Deployment 等常见的内置资源之外，Kube 还允许用户定义资源（CR）。
- CRD 并不是真正的自定义资源，而是自定义
资源的定义（描述我们定义的资源的样子）
对于 CRD，它本质上是一个 Open Api 架构，正如 Kuber 博客文章 ( kubernetes.io/blog/2019/0… ) 所说，R 和 CR 都需要 Yaml。但是如何保证Yaml描述的资源是规范的、合法的，这就是schema的作用，而CRD的作用就是向集群注册一个新的资源，并告诉ApiServer这个资源是如何合法定义的。
控制器模式
在详细介绍 CRD 之前，我们先简要解释一下控制器模型。如果你对 Kubernetes 有了解的话，就知道我们可以通过创建 Deployment 来管理 Pod，但是 Deployment 并不是直接创建 Pod，而是 Deployment 管理 RS，RS 管理 Pod，这实际上就是控制器模式。
控制器模式允许基于现有资源定义更高阶的控制器，以实现更复杂的功能，当然，具体细节肯定会更复杂。
CRD 可以做什么
总的来说，我们用CRD定义的CR是一个新的控制器，我们可以自定义Controller的逻辑来完成一些Kubernetes集群原生不支持的功能。
举个具体的例子，我使用 Kubebulder 创建了一个简单的 CRD（github.com/Coderhypo/K…），尝试将微服务管理构建到 Kubernetes 集群中。
我创建了两个资源，一个名为App，负责管理整个应用程序生命周期，另一个名为MicroService，负责管理微服务的生命周期。
具体逻辑结构可以理解如下
App可以直接管理多个MicroServices，每个都MicroService支持多个版本，并且得益于控制器模型，MicroService可以Deployment为每个版本创建一个，允许多个版本同时部署。
如果管理应用部署过于简单，MicroService支持创建Service并Ingress为每个微服务启用四层负载均衡和七层负载均衡。
并且，如果启用负载平衡，将为每个版本创建一个 SVC，因此一个服务将有 n + 1 个 SVC，其中 n 为每个版本 1 个，额外的 1 个 SVC 在运行后不会更改（名称和 clusterIP）MicroService。微服务创建完成后，该SVC的Selector将始终与CurrentVersion SVC相同。
换句话说，存在一个稳定的SVC，它向其他组件提供当前版本的服务，而其他组件则可以访问特定版本的服务。这种SVC+CurrentVersion使得实现蓝绿发布能力变得非常容易。
除了SVC之外，MicroService还基于nginx Ingress控制器的能力实现灰度发布，通过修改canaryLoadBalance中的配置，可以通过scale/header/cookie实现灰度发布。
在这个例子中，App并MicroService没有创建new capabilities，而是通过组合 Kubernetes 中已有的资源来实现新功能。
但是，除了快速蓝绿化和灰化微服务之外，还有什么新价值吗App？MicroService另一个看不见的价值是管理的标准化，以前应用程序下的任何操作都需要翻译成“Kube语言”，即对Deployment或Ingress进行管理，现在可以通过统一的入口点规范化进行管理。
概括
通过一个简单的小演示来描述 CRD 是什么，很容易概括。从我目前的想法来看，我认为CRD有两个非常重要的能力。
- 首先，从功能上来说，CRD 将 Kubernetes 中已有的资源和能力变成了乐高积木，我们可以轻松地使用它来扩展 Kubernetes 原生不具备的能力。
- 其次，基于Kubernetes的产品不可避免地要求我们将产品术语与Kube术语保持一致，例如服务是Deployment，实例是Pod等等。但CRD让我们可以根据产品创建自己的概念（或者资源），让Kube现有的资源为我们的概念服务，这让产品更专注于它解决的场景，而不是考虑如何将场景应用到Kubernetes上。