operator 之旅(一) (2)

每种资源的都需要有对应的Scheme，Scheme结构体包含gvkToType和typeToGVK的字段映射关系，APIServer 根据Scheme来进行资源的序列化和反序列化。

GV & GVK & GVR

GV: Api Group & Version

API Group 是相关 API 功能的集合

每个 Group 拥有一或多个 Versions

GVK: Group Version Kind

每个 GV 都包含 N 个 api 类型，称之为 Kinds，不同 Version 同一个 Kinds 可能不同

GVR: Group Version Resource

Resource 是 Kind 的对象标识，一般来 Kind 和 Resource 是 1:1 的，但是有时候存在 1:n 的关系，不过对于 Operator 来说都是 1:1 的关系

举个例子，我们在 k8s 中的 yaml 文件都有下面这么两行：

apiVersion: apps/v1 # 这个是 GV，G 是 apps，V 是 v1 kind: Deployment # 这个就是 Kind sepc: # 加上下放的 spec 就是 Resource了 ...

根据 GVK K8s 就能找到你到底要创建什么类型的资源，根据你定义的 Spec 创建好资源之后就成为了 Resource，也就是 GVR。GVK/GVR 就是 K8s 资源的坐标，是我们创建/删除/修改/读取资源的基础。

查看当前环境的所有资源，及其相关属性 # ctl api-resources -o wide 查看特定group下面的资源，例如：apps # ctl api-resources --api-group apps -o wide 查看指定资源的详情,例如：configmap # ctl explain configmap 查看所有Group和Version的命令 # ctl api-versions 官方文档速查

在实际学习和开发中，对指定资源做增删改查操作时，官方文档是我们最可靠的依赖，地址：https://kubernetes.io/docs/reference/kubernetes-api/

打开deployment的文档，如下图：

另外还有API文档也是必不可少的，最新的是1.19版本，地址：https://v1-22.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.22/

下图是deployment的api接口文档，可见示例、path、请求响应参数都有详细的说明：

APIResources数据结构

APIResource是个常用的数据结构了，可以用来描述资源，例如kubernetes/pkg/controller/resourcequota/resource_quota_controller_test.go中有对其的使用：

func TestDiscoverySync(t *testing.T) { serverResources := []*metav1.APIResourceList{ { GroupVersion: "v1", APIResources: []metav1.APIResource{ {Name: "pods", Namespaced: true, Kind: "Pod", Verbs: metav1.Verbs{"create", "delete", "list", "watch"}}, }, }, } unsyncableServerResources := []*metav1.APIResourceList{ { GroupVersion: "v1", APIResources: []metav1.APIResource{ {Name: "pods", Namespaced: true, Kind: "Pod", Verbs: metav1.Verbs{"create", "delete", "list", "watch"}}, {Name: "secrets", Namespaced: true, Kind: "Secret", Verbs: metav1.Verbs{"create", "delete", "list", "watch"}}, }, }, } 如何对Kubernetes进行扩展

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。
虽然现在 Kubernetes 已经是容器编排的事实标准，其本身的功能也非常丰富并且灵活，但是也不能满足所有人的需求，在遇到 Kubernetes 提供的能力无法满足我们需求的时候，我们就可以利用其强大的扩展能力进行定制。
在实际工作中，对kubernetes的资源执行各种个性化配置和控制是很常见的需求，例如自定义镜像的pod如何控制副本数、主从关系，以及各种自定义资源的控制等。

Kubernetes 有哪些扩展点

如上图所示，从客户端到底层容器运行时，绝大部分地方 Kubernetes 都为我们预留了扩展点，我们从上往下一个一个的来看

kubectl

kubectl 是我们平时和 Kubernetes 交互使用的最多的客户端工具，常见的运维操作都会通过 kubectl 来完成，kubectl 为我们提供了插件机制来方便扩展。

kubectl 插件其实就是以kubectl-为前缀的任意可执行文件 ，执行 kubectl 插件的时候可以通过 kubectl 插件名 参数 的方式运行插件。

就像 Ubuntu 使用 apt 管理软件，mac 可以使用 brew 一样，kubectl 也有类似的插件管理工具 krew ，同时我们可以从 https://krew.sigs.Kubernetes.io/plugins/ 查找是否已经存在我们需要的插件

APIServer 聚合层