（转）如何使用 CRD 拓展 Kubernetes 集群

https://blog.ihypo.net/15642142854314.html

在 6 月底 KubeCon 回来以后，就打算写几篇关于 CRD 的文章，还在 Twitter 上给人作了些许改进 CRD 相关文档的承诺，零零碎碎的事不少，直到如今才有时间落笔。不过在这一个多月里，我作了一个关于 CRD 的内部分享，两个 CRD Demo，向同事、客户数人解释 CRD 是什么东西，反而让我对这个东西更加的清晰。

我会分两到三篇文章介绍 CRD，这是第一篇，简单聊一下什么是 CRD。

太长不看版：

CRD 自己是 Kubernetes 的一种资源，容许咱们本身自定义新的资源类型
除了 CRD 咱们还要提供一个 controller 以实现本身的逻辑
CRD 容许咱们基于已有的 Kube 资源，拓展集群能力
CRD 可使咱们本身定义一套成体系的规范，自造概念
什么是 CRD
CRD 自己是一种 Kubernetes 内置的资源类型，是 CustomResourceDefinition 的缩写，能够经过 kubectl get 命令查看集群内定义的 CRD 资源。

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，全部的东西都叫作资源（Resource），就是 Yaml 里 Kind 那项所描述的
但除了常见的 Deployment 之类的内置资源以外，Kube 容许用户自定义资源（Custom Resource），也就是 CR
CRD 其实并非自定义资源，而是咱们自定义资源的定义（来描述咱们定义的资源是什么样子）
对于一个 CRD 来讲，其本质就是一个 Open Api 的 schema，就像 Kuber Blog 的一篇文章（https://kubernetes.io/blog/2019/06/20/crd-structural-schema/ ）讲到的，不管 R 仍是 CR 都须要 Yaml 来描述，可是，如何确保 Yaml 描述的资源是规范的、合法的，那就是 schema 要作的事情，CRD 就其功能来说，就是想集群注册一种新资源，并告知 ApiServer，这种资源怎么怎么被合法的定义。

控制器模式
在具体讲 CRD 以前先简单讲解一下控制器模式。对 Kubernetes 有过了解的就知道，咱们能够经过建立 Deployment 来管理 Pod，而其实 Deployment 并无直接建立 Pod，而是 Deployment 管理 RS，而 RS 管理 Pod，这其实就是控制器模式。

控制器模式容许基于已有的资源定义更高阶的控制器，来实现更复杂的能力，固然，具体的细节要更复杂，推荐我司杨老湿的文章 《浅析 Kubernetes 控制器的工做原理》（https://www.yangcs.net/posts/a-deep-dive-into-kubernetes-controllers/ ）

CRD 能作什么
通常状况下，咱们利用 CRD 所定义的 CR 就是一个新的控制器，咱们能够自定义控制器的逻辑，来作一些 Kubernetes 集群原生不支持的功能。

拿一个具体的例子来说，我用 Kubebulder 建立了一个简单的 CRD（https://github.com/Coderhypo/KubeService ），尝试在 Kubernetes 集群内置微服务管理。

我建立了两种资源，一个叫 App，负责管理整个应用的生命周期，另外一个叫 MicroService，负责管理微服务的生命周期。

具体的逻辑结构能够这样理解：

App 能够直接管理多个 MicroService，而且，每一个 MicroService 支持多个版本，得益于控制器模式，MicroService 能够为每一个版本建立一个 Deployment，使得能够多个版本同时被部署。

若是只是管理应用的部署未免有些简单，MicroService 支持为每一个微服务建立 Service 和 Ingress，以实现四层负载均衡和七层负载均衡：

而且，若是开启负载均衡的功能，MicroService 将为每一个版本都建立一个 Service，所以，一个服务将拥有 n + 1 个 SVC，其中 n 是每一个版本都拥有一个，而额外的 1 是微服务建立以后就不会再变更（名字和 clusterIP）的 SVC，而这个 SVC 的 Selector 会始终保持和 CurrentVersion 的 SVC 一致。

换句话讲，有一个稳定的 SVC 能够对其余组件提供当前版本的服务，而其余组件也有途径访问到特定版本的服务。这个 SVC + CurrentVersion 就很是轻松的实现了蓝绿发布的能力。

除了 SVC 外，MicroService 还基于 nginx ingress controller 的能力，实现了灰度发布的功能，同过修改 LoadBalance 里 canary 的配置，能够实现按 比例 / header / cookie 进行灰度发布。

这个例子中，App 和 MicroService 并无创造 “新能力”，而只是经过对 Kubernetes 已有资源进行组合，就实现了新功能。

可是除了快速对微服务进行蓝绿、灰度以外，App 和 MicroService 还有没有新的价值呢，另外一个看不到的价值就是管理的标准化，以前对应用下的任何操做都须要被翻译为 “Kube 语言”，即对那个 Deployment 或者 Ingress 管理，如今能够有一个统一的入口规范化管理。

总结
以一个简单的小 Demo 来描述什么是 CRD 很容易以偏概全，就我目前的思考，我认为 CRD 有两个很是重要的能力：

首先是功能上，CRD 使得 Kubernetes 已有的资源和能力变成了乐高积木，咱们很轻松就能够利用这些积木拓展 Kubernetes 原生不具有的能力。

其次是产品上，基于 Kubernetes 作的产品没法避免的须要让咱们将产品术语向 Kube 术语靠拢，好比一个服务就是一个 Deployment，一个实例就是一个 Pod 之类。可是 CRD 容许咱们本身基于产品建立概念（或者说资源），让 Kube 已有的资源为咱们的概念服务，这可使产品更专一与解决的场景，而不是如何思考如何将场景应用到 Kubernetes。