Kubernetes（K8s）_17_Kubernetes扩展

Kubernetes扩展

Kubernetes扩展: 不同角度实现对Kubernetes功能的增加/增强

1. 内部组件: API Server、CRD、Operator、授权和准入控制
2. kubelet: CRI、CNI、CSI、Device Plugins
3. 调度: 调度插件、调度框架

CustomResuorceDefinition

CustomResuorceDefinition(CRD): 定义自定义资源类型

1. 创建CRD时会在API Server上注册生成GVR类型URL端点
2. CRD支持定义验证, 通过OpenAPI模式声明验证(仅支持部分)
3. CustromResource(CR): 用户通过CRD创建的自定义资源类型

Resource(资源): API Server存储对应类别的API对象集合的端点

1. 本质: API Server中以结构化存储数据的集合
2. Kubernetes中所有均基于资源实现, 且CRD也属于种资源类型

如: CRD和CR的关系

//   +---------------------+
//   |    CustomResource   |
//   |                     |
//   +                     v
//  CRD +---yaml---> 自定义资源类型 +---yaml---> 自定义资源实例 

CRD的常用创建格式:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: <String>                         # CRD名称
spec:
  conversion: <Object>                   # 不同版本间的格式转换
    strategy: <String>                   # 不同版本间的自定义资源转换策略(None或Webhook)
    webhook: <Object>                    # 调用Webhook的方式
  group: <String>                        # 所属API Group
  names: <Object>                        # 自定义资源
    categories: <[]String>               # 自定义资源所属的分组类别
    kind: <String>                       # 自定义资源的类型名称(必选)
    plural: <String>                     # 自定义资源的API路径和复数形式的名称
    shortName: <[]String>                # 自定义资源的类型的缩写名称
    singular: <String>                   # 自定义资源的类型名称的单数形式(全小写)
  preserveUnknownFields: <Boolean>       # 预留字段
  scope: <String>                        # 作用域(Cluster或Namespaced)
  versions: <[]Object>                   # 版本号定义
    additionalPrinterColumns: <[]Object> # 返回的额外信息(kubectl get命令的返回结果)
    - name: <String>                     # 额外信息名称
      type: <String>                     # 额外信息的数据类型
      jsonPath: <String>                 # 对应数据格式的字段
      description: <String>              # 额外信息的描述
    name: <String>                       # 自定义资源的版本(如: v1alpha1和v1等)
    schema: <Object>                     # 数据格式(必选, 参考对应文档编写)
      openAPIV3Schema: <Object>          # 校验字段的 schema 对象
    served: <Boolean>                    # 是否允许REST API调用(必选)
    storage: <Boolean>                   # 是否存储于Etcd
    subresources: <Object>               # 定义子资源
      scale: <Object>                    # 启用scale子资源(通过 autoscaling/v1.Scale 发送负载)
        labelSelectorPath: <String>      # 引用status中的标签选择器字段(jsonPath格式)
        specReplicasPath: <String>       # 引用数据格式的字段(jsonPath格式, 代表期望副本数)
        statusReplicasPath: <String>     # 引用status中的字段(jsonPath格式, 代表当前副本数)
      status: <Map[String]String>        # 启用status子资源(生成 /status 端点, 由集群维护)

1. 自定义资源类型名称必须是合法的DNS子域名
2. 自定义资源通过spec.versions[].schema.openAPIV3Schema字段指定自定义配置字段
3. 自定义资源中包含子资源时必须有对应的controller实现, 且scale必须搭配status字段才有效

自定义API Server

自定义API Server: 自定义扩展的API资源

1. 自定义API Server需维护其使用的存储系统(集群或外置)
2. 访问方式: 独立运行暴漏端点、API Server聚合
3. 适用于添加新的核心类型

API Aggregation(AA): 聚合不同的API Server以提供统一的访问端点和管理接口

1. 本质: 原API Server内置的kube-aggregator向特定URL发送请求获取功能
2. 被聚合的自定义API Server都会在原API Server上注册个URL(请求代理)

如: API Server请求处理

// 建议以Pod形式托管部署自定义API Server, 存储使用外置Etcd

API Service: 管理API群组版本(实现不同版本的统一访问入口和配置)

1. API群组版本(API Group Version)：API资源分组和版本控制(便于扩展)
2. 每个APIServer都对应个API群组版本

APIService的常用创建格式:

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: <String>
spec:
  grup: <String>                 # API群组版本名称
  grupPriorityMinimum: <Integer> # API群组版本的最低优先级
  version: <String>              # 注册版本
  versionPriority: <Integer>     # 注册版本在API群组版本的优先级
  service: <Object>              # 自定义API Server对应的Service(必须为443)
    name: <String>
    namespace: <String>
  caBundle: <String>               # PEM编码的CA打包信息(验证APIService证书)
  insecureSkipTLSVerify: <Boolean> # 是否禁止TLS证书认证

1. APIService名称必须是合法的DNS子域名
2. 当优先级相同时, 会根据字符集排序

如: API群组版本

Operator

Operator: 管理CRD的专用Controller

1. 功能: 实现资源的status中的实际状态向spec中的期望状态收敛
2. 本质: 监控资源状态变动, 根据变动执行对应操作以确保向期望状态收敛

如: Controller处理流程

1. Controller通过集群的Informer/SharedInformer注册监视特定资源类型下的所有资源
2. 当资源发生事件时都会发送至Controller的Workqueue等待处理
3. Controller调用对应事件的函数处理

// SharedInfomer: 共享缓存, 但无法跟踪每个Controller(Controller必须自行维护Workqueue和重试机制)

Controller都需遵循以下3个机制:

1. 声明式API: 仅需请求期望状态, 而非执行特定操作就可完成请求
2. 异步处理: 请求在API Server获取并存储后即返回, 无需等待实际处理响应
3. 水平触发: 资源多次变更时, 仅根据最近次变动作为依据处理(仅依赖当前状态)

如: client-go监控处理流程

1. Informer通过Reflector调用API Server的Listing和WatchAPI获取并监视所有资源
2. 获取后交由Indexer索引后缓存于本地(默认namespace/name), 并根据变动事件同步更新本地缓存
3. 发生变动事件时会同时发送至各个Controller的Workqueue, 并调用Resouce Event Handler回调函数
4. 可自定义Indexer以实现不同方式的索引(需在创建Informer/SharedInformer时指定)

// Informer为确保缓存的有效性, 会以resyncPeriod周期强制更新本地缓存