Docker（三）：利用Kubernetes实现容器的弹性伸缩

一、前言

　　前两章有的介绍docker与Kubernetes。docker是项目运行的容器，Kubernetes则是随着微服务架构的演变docker容器增多而进行其编排的重要工具。Kubernetes不仅可以对容器进行检测状态，还能对其自动扩容缩容。下面就来介绍介绍Kubernetes是如何自动的扩容缩容的。

二、Kubernetes弹性伸缩简介

　　手动的扩缩容是通过kubectl scale命令或者修改deployment的replicas数量来控制Pod的扩缩容。当然前一章有说过可以自己开发客户端发送请求到APIServer中。但是这稍微会麻烦点。而Kubernetes自带的功能使得其从两个维度上支持自动的弹性伸缩：

　　Cluster AutoScale：处理Kubernetes集群中Node节点伸缩，缺点在于严重依赖Iaas厂商提供的云主机服务和资源监控服务。

　　HPA：处理Pod副本集的自动弹性伸缩，使用的是监控服务采集到的资源监控指标数据。

三、HPA简介

　　HPA是通过周期性检查Deployment（可以理解为微服务架构中的一个服务。是在Master节点中的对象。下面可以控制多个Pod）控制的目标Pod的相关监控指标的变化情况来确定是否需要针对性地调整目标Pod的副本数。通常应用的扩缩容都是由CPU或内存的使用率实现的。

　　HPA可以通过Kubernetes自带的监控系统heapster来获取到CPU的使用率。但是从Kubernetes1.8开始，资源使用指标改为通过metrics api获取，所以需要注意自己的Kubernetes版本。而从1.8开始，Kubernetes也将资源分为了下面两种

　　core metrics（核心指标）：采集每个节点上kubelet公开的summary api中的指标信息，通常只包含CPU，内存使用率信息

　　custom metrics（自定义指标）：允许用户从外部的监控系统当中采集自定义的指标，如应用的QPS等指标。

四、直接使用HPA进行自动扩缩容（Kubernetes版本<1.8）

　　可直接定义HPA对象

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  maxReplicas: 10
  minReplicas: 4
  scaleTargetRef:
    kind: Deployment
    name: nginx-demo
  targetCPUUtilizationPercentage: 90

　　从上面配置可以看出HPA控制了一个nginx-demo的Deployment里的4个Pod副本，当这个Pod的CPUUtilizationPercentage也就是Pod自身的CPU利用率为90%就会进行扩容，最大不超过10个，最小值不会低于4个

　　注：CPUUtilizationPercentage 是一个计算平均值，即目标 Pod 所有副本自身的 CPU 利用率的平均值。一个 Pod 自身的 CPU 利用率是该Pod当前的 CPU 的使用量除以它的 Pod Request 的值，比如定义一个 Pod 的 Pod Request 为0.4，而当前的 Pod 的CPU 使用量为 0.2，则它的 CPU 使用率为 50%。所以如果目标Pod没有定义Pod Request的值，是无法使用CPUUtilizationPercentage来进行扩缩容的。

　　当然使用简单的命令也可以直接创建等价的HPA对象

kubectl autoscale deployment php-apache --cpu-percent=90 --min=4 --max=10

五、通过metrics-server来实现扩缩容

　　1、安装metrics-server　　

　　metrics-server代码仓库地址： https://github.com/kubernetes-incubator/metrics-server。下载并且安装后

# 配置command

编辑metrics-server-deployment.yaml，配置如下内容：
...
      containers:
      - name: metrics-server
        image: hub.dz11.com/library/metrics-server-amd64:v0.3.6
        command:
        - /metrics-server
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP
        imagePullPolicy: Always
...
kubectl apply -f ./

　　在metrics-server-deployment.yaml中添加一个command，需要加入两个kubelet配置项，使得metrics-server能够通过kubelet采集数据指标。上述操作会在kube-system中启动一个名称前缀为metrics-server的pods以提供实时数据采集。

　　通过如下命令验证安装是否成功

# 在apiservice中可以看到多了一个接口
kubectl get apiservice
...
v1beta1.metrics.k8s.io                  2020-02-09T03:14:46Z
...

# 通过访问metrics.k8s.io接口，如能正常访问代表安装成功

kubectl get --raw "/apis/metrics.k8s.io/v1beta1" | jq .
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "nodes",
      "singularName": "",
      "namespaced": false,
      "kind": "NodeMetrics",
      "verbs": [
        "get",
        "list"
      ]
    },
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "PodMetrics",
      "verbs": [
        "get",
        "list"
      ]
    }
  ]
}

　　然后再运行下面两条命令：

#获取node的指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq .
#获取pod的指标
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .

　　确保当前两个命令能正确获得指标

　　2、创建HPA对象

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: Java
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: serviceA
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 90
  - type: Resource
    resource:
      name: memory
      targetAverageValue: 200Mi

　　当serviceA的所有副本的CPU使用率值超过request限制的90%或者memory的使用率超过200Mi时会触发自动动态扩容行为。而Pod数在2-10之间浮动。

六、总结

　　通过手工执行 kubectl scale 命令或者通过修改deployment的replicas数量，可以实现 Pod 扩容或缩容从而间接实现我们docker的扩容缩容。但如果仅止于此，显然不符合 Google 对 Kubernetes 的定位目标 —— 自动化、智能化。在 Google 看来，分布式系统要能够根据当前负载的变化情况自动触发水平扩展或缩容的行为。所以HPA就是这样诞生了。而HPA也给我们提供了动态的扩缩容，让我们服务更加具有弹性。