k8s aggregator api 扩展实战记录

aggregator api作为k8 api扩展的两种方式之一(另外一种为CRD)，其原理是通过GVR的形式向apiserver 注册aggregator apiserver(k8s service服务)，当外部访问GVR时，通过kube-apiserver转发请求到aggregator apiserver上。常用于已存在外部服务(aggregator apiserver)，希望借用k8s的认证、授权和准入功能来规范api接口的访问的场景。原理比较简单，但是实践过程会遇到一些踩坑的点，记录如下：
个人理解实现aggregator api扩展大致分为两步：
1、aggregator apiserver部署和api的注册。其中aggregator apiserver的部署可以借助k8s deployment 和replicaset等形式来实现，服务需要通过service 暴露apiserver服务。
2、暴露服务需要通过GVR资源apiservice来注册。

在此过程中需要注意的点是：
1、aggregator apiserver部署过程中需要手动生成aggregator apiserver对kube-apiserver认证的CA证书，可以通过cfssl和openssl方式生成。cfssl生成CA证书方式可以参考
https://editor.csdn.net/md/?articleId=137720791 实现。tls验证可以通过将CA证书以secret形式挂载到aggregator apiserver。具体实现可以在aggregator apiserver主进程中实现。
通过secret挂载CA证书时需注意：data 中key 为证书需以base64编码形式

2、在进行api注册时，可以通过spec.caBundle来为设置kube-apiserver设置CA证书(证书内容为CA内容的base64编码)。

3、如果aggregator apiserver为自定义开发的web程序，需要预留 discoverycheck的api接口(个人理解时注册过程中kube-apiserver验证service是否存在及可提供服务)，api接口内容为api注册的GVR对应的api路由path。

例：注册名称为group：aa.k8s.io version:v1beta 则预留api为 /apis/aa.k8s.io/v1beta

判断api是否注册成功：可以通过kubectl describe 注册的apiservice来查看AVAILABLE字段为true。

4、外界访问注册的api需要配置对应的权限和通过认证。认证可以通过创建serviceaccount来生成对应认证凭证(servicecaccount生成过程中会生成同名的secret，内包含ca证书和token)，通过RBAC配置操作权限，Role绑定serviceaccount，使认证授权两者统一。外界访问注册api凭证可以通过获取secret中token来认证。
也可以跳过重新生成认证和授权、直接使用k8s集群中提供的CA证书(kubectl的CA证书)来访问(kubeadm安装的集群使用的证书在admin.conf文件配置中)
客户端CA证书和密钥为：client-certificate-data client-key-data
例如curl指令访问：
curl --cert client-certificate-data --key client-key-data -k …
使用-k跳过验证apiserver的证书
如果需要验证apiserver服务端证书，携带–cacert certificate-authority-data
使用certificate-authority-data验证apiserver服务端证书有效性。