Kubernetes HPA横向扩展（自动副本数调整）

Pod 的自动伸缩

HPA：Pod水平自动伸缩              为控制器管理的Pod资源副本数量实现自动扩缩容
VPA：Pod垂直自动伸缩              据容器资源使用率自动设置CPU和内存的requests

HPA（Horizontal Pod Autoscaling）Pod 水平自动伸缩（横向扩展），Kubernetes 有一个 HPA 的资源，HPA 可以根据 CPU 利用率自动伸缩一个 Replication Controller、 Deployment 或者Replica Set 中的 Pod 数量。

 

• HPA 基于 Master 上的 kube-controller-manager 服务启动参数 horizontal-pod-autoscaler-sync-period 定义的时长（默认为30秒），周期性的检测 Pod 的 CPU 使用率（1.22版本前只能检测cpu使用率 后续版本可以检测内存进行扩展）。
• HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况， 来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。
• metrics-server 也需要部署到集群中， 它可以通过 resource metrics API 对外提供度量数据（收集汇报内存 cpu使用率）。

HPA的实现原理

利用 metrics-server 定期收集 Pod 资源的平均 CPU 负载情况

根据HPA配置的 CPU/内存 requests 百分比阈值来动态调整 Pod 的副本数量

HPA 扩容时，Pod 副本数量上升会比较快；缩容时，Pod 副本数量下降会比较慢

HPA的常用命令

查看node或pod 的cpu 内存使用量

kubectl top  nodes|pods

创建HPA资源（指定对哪一个pod控制器——pod进行动态扩容        设置扩展需要达到的CPU阈值 扩展的最大最小副本数 ）

kubectl autoscale    <资源名称>  --min=<最小副本数>  --max=<最大副本数>  --cpu-percent=

部署 metrics-server （用于HPA获取pod中cpu 内存等资源使用率参数）

●metrics-server：是kubernetes集群资源使用情况的聚合器，收集数据给kubernetes集群内使用（收集汇报内存 cpu使用率），如kubectl、hpa、scheduler等。

方法1 上传安装包方式安装

 //在所有 Node 节点上传 metrics-server.tar 镜像包到 /opt 目录

cd /opt/
docker load -i metrics-server.tar

//使用 helm install 安装 metrics-server

mkdir /opt/metrics
cd /opt/metrics

helm repo remove stable

······
helm repo add stable https://charts.helm.sh/stable
或
helm repo add stable http://mirror.azure.cn/kubernetes/charts
······

helm repo update

helm pull stable/metrics-server

vim metrics-server.yaml

args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
image:
  repository: k8s.gcr.io/metrics-server-amd64
  tag: v0.3.2

//使用 helm install 安装 metrics-server      需要多等一会儿

helm install metrics-server stable/metrics-server -n kube-system -f metrics-server.yaml

kubectl get pods -n kube-system | grep metrics-server

此时可以使用top命令查看k8s中node的cpu 内存使用情况 

kubectl top node

kubectl top pods --all-namespaces

方法2 编写yaml配置文件安装

vim components.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  - nodes/stats
  - namespaces
  - configmaps
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls
        image: registry.cn-beijing.aliyuncs.com/dotbalo/metrics-server:v0.4.1
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          periodSeconds: 10
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

kubectl apply -f components.yaml

此时可以使用top命令查看k8s中node的cpu 内存使用情况 

kubectl top node

kubectl top pods --all-namespaces

使用HPA （自动扩容缩容工具）

下载hpa-example测试镜像以便测试（hpa-example测试镜像内包含可以运行 CPU 密集计算任务的代码）

其实这里不单独做也没问题，创建pod时也会自动拉取容器镜像。由于镜像较大所以这里预先安装。

另外这个测试镜像只是用于测试，并不是用作HPA扩容（HPA扩容由专门的HPA资源负责）

（稍后会用其他容器来wget这个hpa-example容器让其负载提高。所以使用其他容器镜像代替，只要再在其中运行消耗cpu的进程也是可行的，不一定需要使用hpa-example镜像）

需要动态扩容的pod需要设置容器的cpu request，再创建HPA资源并且指定这个pod

方法1 所有节点上传安装包安装

在所有节点上传 hpa-example.tar 镜像文件到 /opt 目录
hpa-example.tar 是谷歌基于 PHP 语言开发的用于测试 HPA 的镜像，其中包含了一些可以运行 CPU 密集计算任务的代码。

cd /opt
docker load -i hpa-example.tar

docker images | grep hpa-example
    gcr.io/google_containers/hpa-example          latest          4ca4c13a6d7c   5 years ago     481MB

方法2 去所有节点直接docker pull hpa-example测试镜像

去所有节点直接docker pull hpa-example测试镜像

docker pull mirrorgooglecontainers/hpa-example
如果谷歌源不能下载 换阿里云源
docker pull registry.cn-beijing.aliyuncs.com/dotbalo/metrics-server:v0.4.1

创建用于测试的 Pod 资源（这里容器使用hpa-example测试镜像，也可以使用其他镜像不影响），并设置请求资源为 cpu=200m

vim hpa-pod.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: php-apache
  name: php-apache
spec:
  replicas: 1
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache #与service中设定的标签选择器需要对应，让service能够绑定pod
    spec:
      containers:
      - image: gcr.io/google_containers/hpa-example
#如果谷歌源不能下载换阿里云源registry.cn-beijing.aliyuncs.com/dotbalo/metrics-server:v0.4.1
        name: php-apache
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
        resources:
          requests: #HPA根据cpu资源请求量扩容或缩容
            cpu: 200m #cpu请求量200毫核
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache-service
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: php-apache #与pod标签需要对应，让service能够绑定pod

kubectl apply -f hpa-pod.yaml

kubectl get pods

NAME                          READY   STATUS    RESTARTS   AGE
php-apache-799f99c985-5j5b4   1/1     Running   0          26s

创建HPA资源以对设定了资源限制的pod进行动态副本数调整

使用 kubectl autoscale 命令创建 HPA 控制器

设置 cpu 负载阈值为请求资源的 50%（刚刚设置cpu请求量是200毫核，即为超过100毫核使用量就扩容）

指定最少负载节点数量为 1 个，最大负载节点数量为 10 个

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
               #指定HPA对哪个deployment生效

//需要等一会儿（默认30s刷新一次），才能获取到指标信息 TARGETS

kubectl get hpa

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   0%/50%    1         10        1          8m27s 

kubectl top pods

NAME                          CPU(cores)   MEMORY(bytes)   
php-apache-799f99c985-5j5b4   0m           11Mi           

测试

创建一个测试客户端容器

kubectl run -it load-generator --image=busybox /bin/sh

使用创建的测试客户端容器

访问刚刚创建的名为php-apache的pod【hpa-example测试镜像】为其增加负载

（循环wget 名为php-apache的pod【hpa-example测试镜像】）

# while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
                             这里的php-apache.default.svc.cluster.local相当于pod对应的IP
                             所以也可以查询kubectl get service，直接填写pod对应的clusterIP  http://clusterIP

打开一个新的窗口，查看负载节点数目

可见 名为php-apache的pod 由于设置了cpu request，所以HPA资源对其动态扩容副本数以降低cpu占用。

kubectl get hpa -w

NAME         REFERENCE               TARGETS   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache   39%/50%   1         10        1          13m
php-apache   Deployment/php-apache   54%/50%   1         10        1          13m
php-apache   Deployment/php-apache   342%/50%   1         10        1          14m
php-apache   Deployment/php-apache   315%/50%   1         10        4          14m
php-apache   Deployment/php-apache   315%/50%   1         10        7          14m
php-apache   Deployment/php-apache   315%/50%   1         10        7          14m
php-apache   Deployment/php-apache   68%/50%    1         10        7          15m
php-apache   Deployment/php-apache   62%/50%    1         10        7          15m
php-apache   Deployment/php-apache   67%/50%    1         10        7          15m
php-apache   Deployment/php-apache   67%/50%    1         10        10         15m
php-apache   Deployment/php-apache   56%/50%    1         10        10         16m
php-apache   Deployment/php-apache   52%/50%    1         10        10         16m
php-apache   Deployment/php-apache   45%/50%    1         10        10         16m
php-apache   Deployment/php-apache   34%/50%    1         10        10         16m

可以看到经过压测，负载节点数量最大上升到 10 个，并且 cpu 负载也随之下降。

 如果 cpu 性能较好导致负载节点上升不到 10 个，可再创建一个测试客户端同时测试：

kubectl run -i --tty load-generator1 --image=busybox /bin/sh
#再创建一个客户端pod   循环wget名为php-apache的pod【hpa-example测试镜像】为其增加负载
# while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

查看 Pod 状态，也发现已经创建了 10 个 Pod 资源

kubectl get pods

NAME                             READY   STATUS    RESTARTS   AGE
load-generator-7d549cd44-xq5rv   1/1     Running   0          6m34s
php-apache-799f99c985-5j5b4      1/1     Running   0          20m
php-apache-799f99c985-6zn9n      1/1     Running   0          3m12s
php-apache-799f99c985-8rnqz      1/1     Running   0          101s
php-apache-799f99c985-lgth4      1/1     Running   0          2m57s
php-apache-799f99c985-nhtzv      1/1     Running   0          101s
php-apache-799f99c985-nssrp      1/1     Running   0          2m57s
php-apache-799f99c985-nx4hn      1/1     Running   0          3m12s
php-apache-799f99c985-p7h4w      1/1     Running   0          2m57s
php-apache-799f99c985-rmb9t      1/1     Running   0          3m12s
php-apache-799f99c985-xwj5p      1/1     Running   0          101s

HPA 扩容的时候，负载节点数量上升速度会比较快；但回收的时候，负载节点数量下降速度会比较慢。
原因是防止在业务高峰期时因为网络波动等原因的场景下，如果回收策略比较积极的话，K8S集群可能会认为访问流量变小而快速收缩负载节点数量，而仅剩的负载节点又承受不了高负载的压力导致崩溃，从而影响业务。

另外在可预见的 高并发时期（例如双11）

应该手动扩容副本数到预期值【防止突然高并发来不及扩展导致崩溃】，在后续业务较为平稳时再依靠HPA进行动态调整