Kubernetes之APIService资源

精选原创

wx6325de70699f3 2023-12-27 23:03:23 博主文章分类：容器化&K8S云平台 ©著作权

文章标签 APIService 自定义APIServer 文章分类 kubernetes 云计算

©著作权归作者所有：来自51CTO博客作者wx6325de70699f3的原创作品，请联系作者获取转载授权，否则将追究法律责任

一、前言

在说自定义APIServer前，我们先来了解下Kubernetes原生的APIServer。
其实APIServer就是一个https服务器，我们可以使用kubectl工具通过https协议请求APIServer创建资源，删除资源，查看资源等等操作；每个请求都对应着RESTful API中的请求方法，对应资源就是http协议中的url路径；比如我们要创建一个Pod，其kubectl请求APIServer 使用post方法将资源定义提交给APIServer；Pod资源就是对应群组中的某个版本下某个名称空间下的某个Pod资源。
Kubernetes将RESTful风格的API以层级结构组织在一起，每个API群组表现为一个以/apis为根路径的RESTful路径，比如/apis/apps/v1。不过名称为core的核心群组有一个专用的简化路径：/api/v1。
名称空间级别的每一个资源类型在API中的URL路径表示都可简单抽象为形如/apis/<group>/<version>/namespaces/<namespace>/<kind-plural>的路径。比如访问default名称空间下某个pod，其路径就为/apis/core/v1/namespaces/default/pod/mypod。

Kubernetes之APIService资源_APIService

此外，Kubernetes还支持由用户自定义资源类型，常用的方式有3种：一是修改Kubernetes源码自定义类型；二是创建一个自定义的APIServer，并将其聚合至集群中；三是使用CRD（Custom Resource Definition，自定义资源），它们均可用于API群组扩展。

二、Aggregator聚合器&APIService资源

2.1 介绍

Kubernetes原生APIServer主要有两个组件组成，第一个组件Aggregator，其功能类似web代理服务器，第二个组件就是真正的APIServer；其工作逻辑是，用户请求首先送达给Aggregator，由Aggregator根据用户请求的资源，将对应请求路由至APIServer；简单讲Aggregator这个组件主要作用就是用来路由用户请求；默认情况Aggregator会把所有请求都路由至原生的APIServer上进行响应；如果我们需要自定义APIServer，就需要在默认的Aggregator上使用APIService资源将自定义APIServer注册到原生的APIServer上，让其用户请求能够被路由至自定义APIServer进行响应。

APIServer是Kubernetes的唯一访问入口，默认客户端的所有操作都是发送给APIServer进行响应，我们自定义的APIServer要想能够被客户端访问，就必须通过内建APIServer中的Aggregator组件中的路由信息，把对应路径的访问路由至对应APIServer进行访问；对应Aggregator中的路由信息，由Kubernetes内建APIService资源定义。
简单的说APIService资源就是用来定义原生APIServer中Aggregator组件上的路由信息，该路由就是将某某端点的访问路由至对应APIServer。

查看原生APIServer中的群组/版本信息

kubectl api-versions

admissionregistration.k8s.io/v1
apiextensions.k8s.io/v1
apiregistration.k8s.io/v1
apps/v1
authentication.k8s.io/v1
authorization.k8s.io/v1
autoscaling/v1
autoscaling/v2
batch/v1
certificates.k8s.io/v1
coordination.k8s.io/v1
crd.projectcalico.org/v1
discovery.k8s.io/v1
events.k8s.io/v1
flowcontrol.apiserver.k8s.io/v1beta2
flowcontrol.apiserver.k8s.io/v1beta3
networking.k8s.io/v1
node.k8s.io/v1
policy/v1
rbac.authorization.k8s.io/v1
scheduling.k8s.io/v1
storage.k8s.io/v1
v1

只有上面列出的群组版本才能够被客户端访问，即客户端只能访问上述列表中群组版本中的资源，没有出现群组版本是一定不会被客户端访问到。

2.2 创建APIService资源

vim apiservice.yaml
#apiservice资源属于apiregistration.k8s.io/v1群组，其类型为APIService
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: v2beta1.auth.ilinux.io
spec:
  #insecureSkipTLSVerify字段用来描述是否忽略安全验证，即不验证https证书；true表示不验证，false表示要验证
  insecureSkipTLSVerify: true
  #group字段用来描述对应自定义apiserver的群组
  group: auth.ilinux.io
  #groupPriorityMinimum字段用来描述对应群组的优先级
  groupPriorityMinimum: 1000
  #versionPriority字段用来描述对应群组版本的优先级
  versionPriority: 15
  #service字段是用来描述把对应群组版本的请求路由至某个service；该service就是对应自定义apiserver关联的service
  service:
    name: auth-api
    namespace: default
  #version字段用来描述对应apiserver属于对应群组中的某个版本
  version: v2beta1

上述资源清单表示在aggregator上注册auth.ilinux.io/v2beta1这个端点，该端点对应的后端apiserver的service是default名称空间下的auth-api service；即客户端访问auth.ilinux.io/v2beta1下的资源都会被路由至default名称空间下的auth-api service进行响应。

之后应用清单

Kubernetes之APIService资源_APIService_02

上述清单只是用来说明对应APIService资源的使用，并无实质的作用，其原因是我们对应名称空间下并没有对应的服务，也没有对应自定义APIServer；所以通常自定义APIServer，之后用APIService资源来把自定义APIServer整合进原生APIServer中。一个典型的例子就是部署Metrics Server，具体可参考https://blog.51cto.com/u_15796303/6860555