概念
kubernetes的 Aggregated API是什么呢?API Aggregation 允许k8s的开发人员编写一个自己的服务,可以把这个服务注册到k8s的api里面,这样,就像k8s自己的api一样,你的服务只要运行在k8s集群里面,k8s 的Aggregate通过service名称就可以转发到你写的service里面去了。(另外一种扩展 Kubernetes API 的方法是使用CustomResourceDefinition, 编写的自定义CRD, k8s会自动的注册到apiservice上 )
这个设计理念:
- 增加了api的扩展性,这样k8s的开发人员就可以编写自己的API服务器来公开他们想要的API。集群管理员应该能够使用这些服务,而不需要对核心库存储库进行任何更改。
- 丰富了APIs,核心kubernetes团队阻止了很多新的API提案。通过允许开发人员将他们的API作为单独的服务器公开,并使集群管理员能够在不对核心库存储库进行任何更改的情况下使用它们,这样就无须社区繁杂的审查了
- 开发分阶段实验性API的地方,新的API可以在单独的聚集服务器中开发,当它稳定之后,那么把它们封装起来安装到其他集群就很容易了。
- 确保新API遵循kubernetes约定:如果没有这里提出的机制,社区成员可能会被迫推出自己的东西,这可能会或可能不遵循kubernetes约定。
原理
当APIAggregator接收到请求之后,如果发现对应的是一个service的请求,则会直接转发到对应的服务上否则委托给apiserver进行处理,apiserver中根据当前URL来选择对应的REST接口处理,如果未能找到对应的处理,则会交由CRD server处理, CRD server检测是否已经注册对应的CRD资源,如果注册就处理
当在集群中创建了对应的CRD资源的时候,k8s通过内部的controller来感知对应的CRD资源信息,然后为其创建对应的REST处理接口,这样后续接收到对应的资源就可以进行处理
APIAggreagtor中会通过informer 监听后端Service的变化,如果发现有新的服务,就会创建对应的代理转发,从而实现对应的服务注册
注册自定义service资源
1 | apiVersion: apiregistration.k8s.io/v1beta1 |
在这个APIService中设置的API组名为custom.metrics.k8s.io,版本号为v1beta1,这两个字段将作API路径的子目录注册到API路径“/apis/”下。注册成功后,就能通过Master API路径“/apis/custom.metrics.k8s.io/v1beta1”访问自定义的API Server了, API聚合层会代理转发到后端服务custom-metrics-server.custom-metrics.svc上。
官方提供有一个 自定义api service 样例, 通过官方样例可以创建一个自定义聚合api
注意点
service监听的端口必须是https,否则认证通过不了。(通过
kubectl get apiservice
能看到是否通过认证)请求的根路径需要应答请求,否则会报404错误(
kubectl get apiservice v1alpha3.demo.com.cn -o yaml
能拷看到状态)请求的根路径的应答结果需要包含
kind
,apiVersion
,groupVersion
,resources
:1
2
3
4
5
6{
"kind": "APIResourceList",
"apiVersion": "v1",
"groupVersion": "metrics.k8s.io/v1beta1",
"resources": []
}