自定义 API Server
扩展 Kubernetes 系统 API 接口的另一种常用办法是使用自定义的 API Server。相比较 CRD 来说，使用自定义 API Server 更加灵活，例如可以自定义资源类型和子资源、自定义验证及其他逻辑，甚至于在 Kubernetes API Server 中实现的任何功能也都能在 API Server 中实现。
一、自定义 API Server 概述
自定义 API Server 完全可以独立运行并能够被客户端直接访问，但最方便的方式是将它们与主 API Server（kube-apiserver）聚合在一起使用，这样不仅可以使得集群中的多个 API Server 看起来好像是由单个服务提供服务，集群组件和 kubectl 等客户端可不经修改地继续正常通信，而且也无须特殊逻辑来发现不同的 API Server 等操作。在 kube-apiserver 中，用于聚合自定 API Server 的组件是 kube-aggregator，它自 Kubernetes 1.7 版本引入，并内建于主 API Server 之中作为其进程的一部分来运行。
在使用自定义 API Server 中的扩展资源之前，管理员需要在主 API Server 上添加一个相应的 APIService资源对象，将自定义 API Server 注册到 kube-aggregator 之上，以完成聚合操作。一个特定的 APIService 对象可用于在主 API Server 上注册一个 URL 路径，如 /apis/auth.zuoyang.tech/v1alph1/，从而使得 kube-aggregator 将发往这个路径的请求代理至相应的自定义 API Server。每个 APIService 对应一个 API 群组版本，不同版本的单个 API 可以由不同的 APIService 对象支持：
二、APIService 对象
APIService 资源类型的最初设计目标是用于将庞大的主 API Server 分解成多个小型但彼此独立的 API Server，但它也支持将任何遵循 Kubernetes API 设计规范的自定义 API Server 聚合进主 API Server中。
下面的配置清单示例，它定义了一个名为 v2beta1.auth.zuoyang.tech 的 APIService 对象，用于将 default 命中空间中名为 auth-api 的 Service 对象后端的自定义 API Server 聚合进主 API Server 中：
[root@k8s-master01-test-2-26 ~]# kubectl explain apiservice
KIND: APIService
VERSION: apiregistration.k8s.io/v1
DESCRIPTION:
APIService represents a server for a particular GroupVersion. Name must be
"version.group".
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an
object. Servers should convert recognized schemas to the latest internal
value, and may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <Object>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <Object>
Spec contains information for locating and communicating with a server
status <Object>
Status contains derived information about an API server
[root@k8s-master01-test-2-26 ~]#
apiservice.spec 内嵌字段定义如下：
[root@k8s-master01-test-2-26 ~]# kubectl explain apiservice.spec
KIND: APIService
VERSION: apiregistration.k8s.io/v1
RESOURCE: spec <Object>
DESCRIPTION:
Spec contains information for locating and communicating with a server
APIServiceSpec contains information for locating and communicating with a
server. Only https is supported, though you are able to disable certificate
verification.
FIELDS:
caBundle <string>
CABundle is a PEM encoded CA bundle which will be used to validate an API
server's serving certificate. If unspecified, system trust roots on the
apiserver are used.
group <string>
Group is the API group name this server hosts
groupPriorityMinimum <integer> -required-
GroupPriorityMininum is the priority this group should have at least.
Higher priority means that the group is preferred by clients over lower
priority ones. Note that other versions of this group might specify even
higher GroupPriorityMininum values such that the whole group gets a higher
priority. The primary sort is based on GroupPriorityMinimum, ordered
highest number to lowest (20 before 10). The secondary sort is based on the
alphabetical comparison of the name of the object. (v1.bar before v1.foo)
We'd recommend something like: *.k8s.io (except extensions) at 18000 and
PaaSes (OpenShift, Deis) are recommended to be in the 2000s
insecureSkipTLSVerify <boolean>
InsecureSkipTLSVerify disables TLS certificate verification when
communicating with this server. This is strongly discouraged. You should
use the CABundle instead.
service <Object>
Service is a reference to the service for this API server. It must
communicate on port 443. If the Service is nil, that means the handling for
the API groupversion is handled locally on this server. The call will
simply delegate to the normal handler chain to be fulfilled.
version <string>
Version is the API version this server hosts. For example, "v1"
versionPriority <integer> -required-
VersionPriority controls the ordering of this API version inside of its
group. Must be greater than zero. The primary sort is based on
VersionPriority, ordered highest to lowest (20 before 10). Since it's
inside of a group, the number can be small, probably in the 10s. In case of
equal version priorities, the version string will be used to compute the
order inside a group. If the version string is "kube-like", it will sort
above non "kube-like" version strings, which are ordered lexicographically.
"Kube-like" versions start with a "v", then are followed by a number (the
major version), then optionally the string "alpha" or "beta" and another
number (the minor version). These are sorted first by GA > beta > alpha
(where GA is a version with no suffix such as beta or alpha), and then by
comparing major version, then minor version. An example sorted list of
versions: v10, v2, v1, v11beta2, v10beta3, v3beta1, v12alpha1, v11alpha2,
foo1, foo10.
[root@k8s-master01-test-2-26 ~]#
定义一个 APIService 对象时，其 Spec 嵌套使用的字段包括如下这些字段：
-
- group <string>: 注册使用的 API 群组名称。
- groupPriorityMinimum <integer> -required-: API 群组的最低优先级，较高优先级的群组将优先被客户端使用；数值越大优先级越高，数值相同时则按名称字符进行排序。
- version <string>: 注册的 API 群组的版本。
- versionPriority <integer> -required-: 当前版本在其所属的 API 群组内的优先级；必须使用正整数数值，数值越大优先级越高，数值相同时则按名称字符进行排序。
- service <Object>: 自定义 API Server 相关的 Service 对象，是真正提供 API 服务的后端，它必须通过 443 端口进行通信。
- insecureSkipTLSVerify <boolean>: 与此服务通信是否禁止 TLS 证书认证。
APIService 仅用于将 API Server 进行聚合，真正提供服务的是相应的外部 API Server，这个自定义服务器通常应该以 Pod 的形式托管运行于当前 Kubernetes 集群之上。
在 Kubernetes 集群上部署使用自定义 API Server 主要由两步组成：
- 首先，需要将自定义 API Server 以 Pod 形式运行于集群之上并为其创建 Service 对象。
- 然后，创建一个专用的 APIService 对象与 API Server 完成聚合。
Kubernetes 系统的系统资源指标 API 就由 metrics-server 项目提供，该项目基于 metrics-server 提供了一个扩展的 API，并通过 API 群组 metrics.k8s.io 将其完成聚合。