「走进k8s」Kubernetes1.15.1的Pod 自动扩缩容（23）

上次说了deployment，它也是kubernetes的核心概念，主要职责和RC一样就是为了保证pod的数量和健康，除了RC有的功能，它自带的光环属性查看事件和状态，还支持回滚，回滚到任意的版本，相对于RC强大。官方推荐就是使用deployment来管理无状态的应用。所以还是按照官方的理论走以后就用deployment来管理我们的pod。前面说过可以通过--replicas的方式来扩缩容，或者是通过dashboard的方式界面化的扩缩容。其实都需要手动，如果kubernetes可以通过当时容器使用情况来自动的扩缩容，其实有的可以进行预知，有的根本就是不确定的，纯手工去做也是不现实的人海战术。

（一）HPA

• ① 历史

HPA最早版本（autoscaling/v1）仅支持CPU作为可监控的度量标准。当前版本HPA处于测试阶段（autoscaling/v2beta1）支持内存和其他自定义指标。

• ②介绍

Horizontal Pod Autoscaling，简称HPA, Kubernetes通过HPA的设定，实现了容器的弹性伸缩功能。对于Kubernetes中的POD集群来说，HPA可以实现很多自动化功能，比如当POD中业务负载上升的时候，可以创建新的POD来保证业务系统稳定运行，当POD中业务负载下降的时候，可以销毁POD来减少资源的浪费。当前的弹性伸缩的指标包括：CPU，内存，并发数，包传输大小。HPA控制器默认每隔30秒就会运行一次，一旦创建的HPA，我们就可以通过命令查看获取到的当前指标信息。 原来是k8s下面单独的一个项目，现在已经独立在github上了

• ③ 官网

https://github.com/kubernetes-retired/heapster kubernetes 已经废弃了，我们还要顺势而为对吧。在说咱们是1.15.1 已经不在支持HPA，

（二）Metrics-Server

• ① 官网

https://github.com/kubernetes-incubator/metrics-server

• ② 介绍

kubernetesv1.11以后不再支持通过heaspter采集监控数据，支持新的监控数据采集组件metrics-server，比heaspter轻量很多，也不做数据的持久化存储，提供实时的监控数据查询还是很好用的。

• ③ 架构

metrics-server 通过 kube-apiserver 发现所有节点，然后调用 kubelet APIs（通过 https 接口）获得各节点（Node）和 Pod 的 CPU、Memory 等资源使用情况。从 Kubernetes 1.12 开始，kubernetes 的安装脚本移除了 Heapster，从 1.13 开始完全移除了对 Heapster 的支持，Heapster 不再被维护。替代方案如下：

1. 用于支持自动扩缩容的 CPU/memory HPA metrics：metrics-server；2. 通用的监控方案：使用第三方可以获取 Prometheus 格式监控指标的监控系统，如 Prometheus Operator；3. 事件传输：使用第三方工具来传输、归档 kubernetes events；

从 Kubernetes 1.8 开始，资源使用指标（如容器 CPU 和内存使用率）通过 Metrics API 在 Kubernetes 中获取, metrics-server 替代了heapster。Metrics Server 实现了Resource Metrics API，Metrics Server 是集群范围资源使用数据的聚合器。Metrics Server 从每个节点上的 Kubelet 公开的 Summary API 中采集指标信息。 在了解Metrics-Server之前，必须要事先了解下Metrics API的概念。Metrics API相比于之前的监控采集方式(hepaster)是一种新的思路，官方希望核心指标的监控应该是稳定的，版本可控的，且可以直接被用户访问(例如通过使用 kubectl top 命令)，或由集群中的控制器使用(如HPA)，和其他的Kubernetes APIs一样。官方废弃heapster项目，就是为了将核心资源监控作为一等公民对待，即像pod、service那样直接通过api-server或者client直接访问，不再是安装一个hepater来汇聚且由heapster单独管理。 假设每个pod和node我们收集10个指标，从k8s的1.6开始，支持5000节点，每个节点30个pod，假设采集粒度为1分钟一次，则"10 x 5000 x 30 / 60 = 25000 平均每分钟2万多个采集指标"。因为k8s的api-server将所有的数据持久化到了etcd中，显然k8s本身不能处理这种频率的采集，而且这种监控数据变化快且都是临时数据，因此需要有一个组件单独处理他们，k8s版本只存放部分在内存中，于是metric-server的概念诞生了。其实hepaster已经有暴露了api，但是用户和Kubernetes的其他组件必须通过master proxy的方式才能访问到，且heapster的接口不像api-server一样，有完整的鉴权以及client集成。 有了Metrics Server组件，也采集到了该有的数据，也暴露了api，但因为api要统一，如何将请求到api-server的/apis/metrics请求转发给Metrics Server呢， 解决方案就是：kube-aggregator,在k8s的1.7中已经完成，之前Metrics Server一直没有面世，就是耽误在了kube-aggregator这一步。kube-aggregator（聚合api）主要提供

1. Provide an API for registering API servers; 2. Summarize discovery information from all the servers; 3. Proxy client requests to individual servers;

Metric API的使用

1. Metrics API 只可以查询当前的度量数据，并不保存历史数据 2. Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 维护 3. 必须部署 metrics-server 才能使用该 API，metrics-server 通过调用 Kubelet Summary API 获取数据

Metrics server定时从Kubelet的Summary API(类似/ap1/v1/nodes/nodename/stats/summary)采集指标信息，这些聚合过的数据将存储在内存中，且以metric-api的形式暴露出去。Metrics server复用了api-server的库来实现自己的功能，比如鉴权、版本等，为了实现将数据存放在内存中吗，去掉了默认的etcd存储，引入了内存存储（即实现Storage interface)。因为存放在内存中，因此监控数据是没有持久化的，可以通过第三方存储来拓展，这个和heapster是一致的。 Kubernetes Dashboard 还不支持 metrics-server，如果使用 metrics-server 替代 Heapster，将无法在 dashboard 中以图形展示 Pod 的内存和 CPU 情况，需要通过 Prometheus、Grafana 等监控方案来弥补。kuberntes 自带插件的 manifests yaml 文件使用 gcr.io 的 docker registry，国内被墙，需要手动替换为其它 registry 地址（本文档未替换）；可以从微软中国提供的 gcr.io 免费代理下载被墙的镜像；下面部署命令均在k8s-master01节点上执行。 监控架构

• ④ Metrics-Server 部署

下载git上边的文件，因为是1.15所以需要下载指定文件夹 https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy/1.8+ 本来可以通过git clone 来下载项目的，项目比较大，在加上网速不行。就6个文件，选择了进入文件内部直接复制文件内容的方式，一定要认真。

mkdir metrics-servercd metrics-servervi aggregated-metrics-reader.yamlvi auth-delegator.yamlvi auth-reader.yamlvi metrics-apiservice.yamlvi metrics-server-deployment.yamlvi metrics-server-service.yamlvi resource-reader.yaml

修改metrics-server-deployment.yaml 文件

vi metrics-server-deployment.yaml

这是已经修改好的

修改内容

1. 国内的镜像
2. 镜像拉取策略
3. 添加命令和相关参数
4. 选择目录
5. 从 kubelet 采集数据的周期 30s
6. 优先使用 InternalIP 来访问 kubelet，这样可以避免节点名称没有 DNS 解析记录时，通过节点名称调用节点 kubelet API 失败的情况（未配置时默认的情况）
7. 不验证客户端证书

image: gcr.azk8s.cn/google_containers/metrics-server-amd64:v0.3.3imagePullPolicy: IfNotPresentcommand: - /metrics-server - --metric-resolution=30s - --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP - --kubelet-insecure-tls

如果不修改command区域的参数则会报如下错误

E0811 05:02:17.819517       1 manager.go:111] unable to fully collect metrics: [unable to fully scrape metrics from source kubelet_summary:k8s-master: unable to fetch metrics from Kubelet k8s-master (192.168.86.100): Get https://192.168.86.100:10250/stats/summary/: x509: cannot validate certificate for 192.168.86.100 because it doesn't contain any IP SANs, unable to fully scrape metrics from source kubelet_summary:k8s-node1: unable to fetch metrics from Kubelet k8s-node1 (192.168.86.101): Get https://192.168.86.101:10250/stats/summary/: x509: cannot validate certificate for 192.168.86.101 because it doesn't contain any IP SANs]

部署metrics-server

 kubectl apply -f .

查看运行情况

kubectl -n kube-system get pods -l k8s-app=metrics-serverkubectl get svc -n kube-system  metrics-server

测试

kubectl top node#出现error: metrics not available yet，等等kubectl top nodeskubectl top pods -n kube-systemkubectl cluster-info

火狐访问dashboard，https://192.168.86.101:32500/

（三）自动扩所容演示

• ① 新建 yaml 生成Deployment

一定要加 resources，cpu这部分，否则后面查看hpa的时候，初始化是unknow

---apiVersion: apps/v1beta1kind: Deploymentmetadata:  name: hpa-nginx-deploy  labels:    app: nginx-demospec:  revisionHistoryLimit: 15  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx        resources:         requests:          cpu: 100m        ports:        - containerPort: 80

• ② 创建deployment

kubectl apply -f auto-deployment.yaml

• ③ 创建自动扩所容的hpa

最大cup 5%，最少1个pod，最多5个pod。根据设定的 cpu使用率（5%）动态的增加或者减少pod数量。

kubectl autoscale deployment hpa-nginx-deploy --cpu-percent=5 --min=1 --max=5  

• ④ 查看上面命令行创建的HPA的YAML

kubectl get hpa hpa-nginx-deploy -o yaml

• ⑤ 通过请求的方式增加cpu的使用，演示pod数量

目前的pod数量

kubectl get pod

查看pod，IP（10.244.1.27），开始加压

kubectl run -i --tty load-generator --image=busybox /bin/shwhile true; do wget -q -O- http://10.244.1.27; done

新启动一个窗口查看hpa情况，刚开始cpu =1% 后来变成28%，自动进行扩容处理

kubectl describe hpa hpa-nginx-deploy

kubectl get podkubectl get hpa

同样的这个时候我们来关掉busybox来减少负载，然后等待一段时间观察下HPA和Deployment对象

kubectl get pod

上边的图是5个pod，下面变成了1个完成了缩容

PS：在yaml里面没有添加CpuUtillizationPercentage目标pod所有副本自身的cpu利用率平均值。一个pod自身的cpu利用率，该pod当前cpu的使用量/pod Request值。如果某一时刻，CpuUtillizationPercentage的值超过了80%，则判断当前的pod已经不够支撑业务，需要增加pod。扩所容基本讲述完毕，最复杂的是装Metrics-Server。