Kubernetes 资源对象解析和API扩展引入

2020-08-14 0 By admin

一、Kubernetes 内建对象的实现

根据 Kubernetes 的设计,每种官方内建的资源对象(Node、Pod、Server等)的实现都包含以下主要功能。

1.1、资源对象的元数据Schema的定义

可以将其理解为数据库Table的定义,定义了对应资源对象的数据结构。官方内建资源对象的元数据定义是固化在源码中的。

1.2、资源对象的校验逻辑

确保用户提交的资源对象的属性的合法性。

1.3、资源对象CRUD操作代码

可以将其理解为数据库表的CRUD代码,但比后者更难;因为 API Server 对资源对象的 CRUD 操作都会保存到 etcd 数据库中,对处理性能的要求更高,还要考虑版本兼容性和版本转换等复杂问题。

1.4、资源对象相关的“自动控制器”(如RC、Deployment 等资源对象背后的控制器)

这是很重要的一个功能。因为 Kubernetes 是一个以自动化为核心目标的平台,用户给出期望的资源对象声明,运行过程中则由资源背后的“自动控制器”负责,确保对应资源对象的数量、状态、行为都始终符合用户的预期。

1.5、扩展 CRD(CustomResourceDefinition)

类似地,每个自定义 CRD 的开发人员都需要实现上面这些功能。为了减少编程难度和工作量,API Server 的设计者做出了大量努力,使得上面前三个功能无须编程实现,直接编写 YAML 定义文件即可实现。
对于唯一需要编程的第四个功能来说,由于 API Server 提供了大量基础 API 库,特别是易用的 List-Watch的编程框架,也使得 CRD 自动控制器的编程难度大大减少。

二、Kubernetes API的扩展

随着Kubernetes的发展,用户对Kubernetes的扩展性也提出了越来越高的要求。
从1.7版本开始,Kubernetes引入扩展API资源的能力,使得开发人员在不修改Kubernetes核心代码的前提下可以对Kubernetes API进行扩展,仍然使用Kubernetes的语法对新增的API进行操作,这非常适用于在Kubernetes上通过其API实现其他功能(例如第三方性能指标采集服
务)或者测试实验性新特性(例如外部设备驱动)。

2.1、Kubernetes API 资源对象扩展的要求

在Kubernetes中,所有对象都被抽象定义为某种资源对象,同时系统会为其设置一个API入口(API Endpoint),对资源对象的操作(如新增、删除、修改、查看等)都需要通过Master的核心组件API Server调用资源对象的API来完成。与API Server的交互可以通过kubectl命令行工具或访问其RESTful API进行。
每个API都可以设置多个版本,在不同的API URL路径下区分,例如“/api/v1”或“/apis/extensions/v1beta1”等。
使用这种机制后,用户可以很方便地定义这些API资源对象(YAML配置),并将其提交给Kubernetes(调用RESTful API),来完成对容器应用的各种管理工作。
Kubernetes系统内置的Pod、RC、Service、ConfigMap、Volume等资源对象已经能够满足常见的容器应用管理要求,但如果用户希望将其自行开发的第三方系统纳入Kubernetes,并使用Kubernetes的API对其自定义的功能或配置进行管理,就需要对API进行扩展了。

2.2、Kubernetes 提供的两种扩展API的方式

目前Kubernetes 提供了以下两种机制供用户扩展API。
(1)使用CRD机制:复用Kubernetes的API Server,无须编写额外的API Server。用户只需要定义CRD,并且提供一个CRD控制器,就能通过Kubernetes的API管理自定义资源对象了,同时要求用户的CRD对象符合API Server的管理规范。
(2)使用API聚合机制:用户需要编写额外的API Server,可以对资源进行更细粒度的控制(例如,如何在各API版本之间切换),要求用户自行处理对多个API版本的支持。