Kubernetes(K8s)_17_Kubernetes扩展

Kubernetes(K8s)_17_Kubernetes扩展

  • Kubernetes扩展
    • CustomResuorceDefinition
    • 自定义API Server
    • Operator

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

Kubernetes(K8s)_17_Kubernetes扩展_第1张图片

// 建议以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: >
spec:
  grup: >                 # API群组版本名称
  grupPriorityMinimum: > # API群组版本的最低优先级
  version: >              # 注册版本
  versionPriority: >     # 注册版本在API群组版本的优先级
  service: >              # 自定义API Server对应的Service(必须为443)
    name: >
    namespace: >
  caBundle: >               # PEM编码的CA打包信息(验证APIService证书)
  insecureSkipTLSVerify: > # 是否禁止TLS证书认证
  1. APIService名称必须是合法的DNS子域名
  2. 当优先级相同时, 会根据字符集排序

如: API群组版本

Kubernetes(K8s)_17_Kubernetes扩展_第2张图片


Operator

Operator: 管理CRD的专用Controller

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

如: Controller处理流程

Kubernetes(K8s)_17_Kubernetes扩展_第3张图片

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

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


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

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

如: client-go监控处理流程

Kubernetes(K8s)_17_Kubernetes扩展_第4张图片

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

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


你可能感兴趣的:(kubernetes,容器)