kubernetes实现用户自定义扩缩容

本文章主要参考walkthrough，aggregation和auth。涉及custom metric API的注册认证以及API server aggregation的相关知识。walkthrough中主要实现了Prometheus adapter的功能，Prometheus adapter主要从Prometheus以一定间隔收集可用的metrics，然后以特定的格式暴露该metrics。

强烈建议阅读官方文档：setup an extension API server

HorizontalPodAutoscaler控制器可以通过两种方式获取metrics：通过Heapster接入方式和REST client接入方式。其中REST client方式即获取custom metrics的方式(参见：Horizontal Pod Autoscaler)

walkthrough中的主要步骤如下：

使能aggregation

　　API server的flag中启用如下内容：

--requestheader-client-ca-file=<path to aggregator CA cert>
--requestheader-allowed-names=aggregator
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to aggregator proxy cert>
--proxy-client-key-file=<path to aggregator proxy key>
--runtime-config=api/all=true

　　kube-controller-manager的flag中启用如下内容：

--horizontal-pod-autoscaler-use-rest-clients=true
--horizontal-pod-autoscaler-sync-period=10s //default 30s
--master=<apiserver-address>:<port> //port should be 8080

下载prometheus和prometheus adapter镜像
在prom命名空间下部署prometheus和prometheus adapter，创建名称为prometheus的configmap，包含prometheus的配置，后续mount到prometheus容器中；prom命名空间中创建service，名称为prom-cm-adapter，该serviceaccount用在prometheus和prometheus adapter的deploment中。最终输出prom-adapter.deployment.yaml文件。注意还需要在该文件中添加adapter容器描述（文章第二段有）
创建rolebing prom-ext-auth-reader使得prom:prom-cm-adapter service有权限获取extension-apiserver-authentication的configmap；同时创建一个名为serving-cm-adapter的tls secret，用于https通信(adapter需要与apiserver通信)；创建名为cm-adapter-resource-lister的clusterrolebinding，使得prom:prom-cm-adapter有权限列出集群的资源信息
创建Prometheus和adapter的deploment，并创建名为prometheus的clusterip service，暴露端口为--tcp=443:443，该端口为访问apiserver的端口
创建APIServer，注册API到custom.metrics.k8s.io/v1beta1(1.10中为custom.metrics.k8s.io/v1)，该操作对应的yaml文件中的caBundle为aggregator用于认证serving证书的ca（--tls-cert-file和--tls-private-key-file指定的），使用命令导出： base64 --w 0 < /tmp/ca.crt，最后创建该apiservice，metadata.name中包含了后面定义的version和group
使用命令检查：kubectl get --raw /apis/custom.metrics.k8s.io/v1beta1
创建一个产生custom metrics的APP service，可以使用文章中描述的，也可以自己实现annotations的配置需要与prometheus中获取kubernetes的配置一致，如下

# * `prometheus.io/scrape`: Only scrape pods that have a value of `true`
# * `prometheus.io/path`: If the metrics path is not `/metrics` override this.
# * `prometheus.io/port`: Scrape the pod on the indicated port instead of the

创建HPA，HPA的yaml文件中需要用于产生custom metrics的app名称

注：根据官方文档setup an extension API server，需要给serviceaccount绑定ClusterRole system:auth-delegator，该ClusterRole是为了插件API server向main API server请求认证和授权检查，认证方式为Webhook Token Authentication。绑定方式参考custom-metrics.yaml

上述流程中主要涉及的难点有：Prometheus和adapter的原理，证书的生成，extension-apiserver-authentication-role和aggregation

Prometheus和adapter的原理

prometheus获取用户metrics使用的是service-discovery机制，参见kubernetes_sd_config（The service role discovers a target for each service port for each service. This is generally useful for blackbox monitoring of a service. The address will be set to the Kubernetes DNS name of the service and respective service port）

Prometheus adapter的原理类似heapster，请求收集各prometheus的数据，并通过REST发送给HPA controller。prometheus的数据可以由prometheus client产生

相关证书主要是两个，serving CA和RequestHeader client CA，证书描述参见kubernete的证书总结。文章中所说的Serving Certificates可以使用kube-apiserver配置中--tls-cert-file --tls-private-key-file指定的值，也可以使用不同的CA，用于https通信认证。注意：serving证书的hosts字段需要包含<service>.<namespace>.svc，其中service和namespace为APIService注册时指定的service和namespace，生成参见aggregation

同时还有--proxy-client-cert-file 和--proxy-client-key-file指定的代理证书。更多描述参见Configure the aggregation layer (There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA)，也可以在插件的API server flag中传入--authentication-skip-lookup，但这样会同时关闭client认证，可以通过手动传入--client-ca-file启用client认证

extension-apiserver-authentication-role

关于extension-apiserver-authentication-role的表述参见Serving Certificates, Authentication, and Authorization，该role用于插件API server在默认条件下获取kube-system命名空间中的extension-apiserver-authentication ConfigMap，extension-apiserver-authentication ConfigMap中包含了main api server使用--client-ca-file指定的client CA和--requestheader-client-ca-file指定的RequestHeader client CA 。这种方式下，相同的client证书既可以用于k8s的认证，也可以用于插件API server的认证。

aggregation

　　　　用于注册custom API，作为代理使用。参见aggregation

总结：

产生custom metrics的app模板中的annotations字段定义了暴露给prometheus的metrics的端口和路径；prometheus的配置中的scrape_configs字段通过标签定义了需要抓取的内容，与app中的annotations字段相呼应；custom metric API注册模板中指定了API的组和版本，以及该API对应的prometheus和prometheus adapter的service；
这样整个流程可以描述为：app产生custom metrics；prometheus抓取app产生的custom metrics；prometheus adapter请求并缓存更新prometheus的metrics，后续上报给kubernetes。从配置中可以看到prometheus并没有配置认证，而prometheus adapter则配置了与kubernetes交互的认证信息

流程图如下，aggregator通过service名称连接到APIService中指定的服务获取metric