【云原生】K8s pod 动态弹性扩缩容 HPA

一、概述

Horizontal Pod Autoscaler（HPA，Pod水平主动弹性），依据平均 CPU 利用率、平均内存利用率或你指定的任何其他自界说方针主动调整 Deployment 、ReplicaSet 或 StatefulSet 或其他类似资源，实现布置的主动扩展和缩减，让布置的规模挨近于实际服务的负载。HPA不适用于无法缩放的方针，例如DaemonSet。

官方文档：kubernetes.io/zh-cn/docs/…

实际生产中，一般运用这四类方针：

1. Resource metrics——CPU核 和 内存利用率方针。

2. Pod metrics——例如网络利用率和流量。

3. Object metrics——特定方针的方针，比如Ingress, 能够按每秒运用请求数来扩展容器。

4. Custom metrics——自界说监控，比如经过界说服务响应时刻，当响应时刻到达必定方针时主动扩容。

二、装置 metrics-server

1）HPA 前提条件

默许情况下，Horizontal Pod Autoscaler 控制器会从一系列的 API 中检索度量值。 集群管理员需求保证下述条件，以保证 HPA 控制器能够拜访这些 API：

• 关于资源方针，将运用 metrics.k8s.io API，一般由 metrics-server 供给。 它能够作为集群插件发动。

• 关于自界说方针，将运用 custom.metrics.k8s.io API。 它由其他度量方针方案厂商的“适配器（Adapter）” API 服务器供给。 检查你的方针管道以检查是否有可用的 Kubernetes 方针适配器。

• 关于外部方针，将运用 external.metrics.k8s.io API。可能由上面的自界说方针适配器供给。

Kubernetes Metrics Server：

• Kubernetes Metrics Server 是 Cluster 的核心监控数据的聚合器，kubeadm 默许是不布置的。
• Metrics Server 供 Dashboard 等其他组件运用，是一个扩展的 APIServer，依赖于 API Aggregator。所以，在装置 Metrics Server 之前需求先在 kube-apiserver 中敞开 API Aggregator。
• Metrics API 只能够查询当时的度量数据，并不保存历史数据。
• Metrics API URI 为 /apis/metrics.k8s.io/，在 k8s.io/metrics 下维护。
• 必须布置 metrics-server 才能运用该 API，metrics-server 经过调用 kubelet Summary API 获取数据。

2）敞开 API Aggregator

# 添加这行
# --enable-aggregator-routing=true
### 修正每个 API Server 的 kube-apiserver.yaml 装备敞开 Aggregator Routing：修正 manifests 装备后 API Server 会主动重启生效。
cat /etc/kubernetes/manifests/kube-apiserver.yaml

3）开端装置 metrics-server

GitHub地址：github.com/kubernetes-… 下载

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/metrics-server-helm-chart-3.8.2/components.yaml

修正

...
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --kubelet-insecure-tls                    #   加上该发动参数，不加可能会报错
        image: registry.aliyuncs.com/google_containers/metrics-server:v0.6.1   # 镜像地址依据情况修正
        imagePullPolicy: IfNotPresent
...

metrics-server pod无法发动，呈现日志unable to fully collect metrics: ... x509: cannot validate certificate for because ... it doesn't contain any IP SANs ... 解决方法：在metrics-server中添加--kubelet-insecure-tls参数越过证书校验

开端装置

kubectl apply -f components.yaml
kubectl get pod -n kube-system | grep metrics-server
# 检查
kubectl get pod -n kube-system | grep metrics-server
# 检查node和pod资源运用情况
kubectl top nodes
kubectl top pods

三、Horizontal Pod Autoscaler 作业原理

1）原理架构图

• 主动检测周期由 kube-controller-manager 的 --horizontal-pod-autoscaler-sync-period 参数设置（默许间隔为 15 秒）。
• metrics-server 供给 metrics.k8s.io API 为pod资源的运用供给支撑。
• 15s/周期 -> 查询metrics.k8s.io API -> 算法核算 -> 调用scale 调度 -> 特定的扩缩容战略履行。

2）HPA扩缩容算法

从最基本的视点来看，Pod 水平主动扩缩控制器依据当时方针和希望方针来核算扩缩份额。

希望副本数 = ceil[当时副本数 * (当时方针 / 希望方针)]

1、扩容

• 假如核算出的扩缩份额挨近 1.0, 将会放弃本次扩缩, 度量方针 / 希望方针挨近1.0。

2、缩容

• 冷却/推迟: 假如推迟（冷却）时刻设置的太短，那么副本数量有可能跟曾经一样呈现抖动。 默许值是 5 分钟（5m0s）–horizontal-pod-autoscaler-downscale-stabilization

3、特殊处理

• 丢掉度量值：缩小时假设这些 Pod 耗费了方针值的 100%， 在需求扩大时假设这些 Pod 耗费了 0% 方针值。 这能够在必定程度上按捺扩缩的起伏。
• 存在未安排妥当的pod的时候：咱们保守地假设尚未安排妥当的 Pod 耗费了希望方针的 0%，然后进一步降低了扩缩的起伏。
• 未安排妥当的 Pod 和短少方针的 Pod 考虑进来再次核算运用率。 假如新的比率与扩缩方向相反，或许在忍受范围内，则越过扩缩。 否则，咱们运用新的扩缩份额。
• 指定了多个方针， 那么会按照每个方针分别核算扩缩副本数，取最大值进行扩缩。

3）HPA 方针界说

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  behavior:
  scaleDown:
    policies:
    - type: Pods
      value: 4
      periodSeconds: 60
    - type: Percent
      value: 10
      periodSeconds: 60
    stabilizationWindowSeconds: 300
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

HPA方针默许行为

behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
    selectPolicy: Max

四、示例演示

1）编列yaml

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-nginx
spec:
  maxReplicas: 10 # 最大扩容到10个节点（pod）
  minReplicas: 1 # 最小扩容1个节点（pod）
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 40 # CPU 平局资源运用率到达40%就开端扩容，低于40%便是缩容
        # 设置内存
        # AverageValue：40
        type: Utilization
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-nginx
---
apiVersion: v1
kind: Service
metadata:
  name: hpa-nginx
spec:
  type: NodePort
  ports:
    - name: "http"
      port: 80
      targetPort: 80
      nodePort: 30080
  selector:
    service: hpa-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      service: hpa-nginx
  template:
    metadata:
      labels:
        service: hpa-nginx
    spec:
      containers:
        - name: hpa-nginx
          image: nginx:latest
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
            limits:
              cpu: 200m
              memory: 200Mi

主要参数解释如下：

• scaleTargetRef：方针效果方针，能够是Deployment、ReplicationController或ReplicaSet。
• minReplicas和maxReplicas：Pod副本数量的最小值和最大值，体系将在这个范围内进行主动扩缩容操作，并维持每个Pod的内存运用率为40%，这个值便是上面设置的阈值averageUtilization。
• metrics：方针方针值。在metrics中经过参数type界说方针的类型；经过参数target界说相应的方针方针值，体系将在方针数据到达方针值时（考虑忍受度的区间，见前面算法部分的说明）触发扩缩容操作。
• 关于CPU运用率，在target参数中设置averageUtilization界说方针平均CPU运用率。
• 关于内存资源，在target参数中设置AverageValue界说方针平均内存运用值。

履行

kubectl apply -f test.yaml

2）运用 ab 工具进行压测

进入apache官网 httpd.apache.org/ 下载apache即可，或许直接经过yum装置apache都行，这里挑选最简略的方式yum装置

yum install httpd -y

开端压测

ab -n 100000 -c 800 http://local-168-182-112:30080/
#-c：并发数
#-n：总请求数

从上图发现已经实现了依据CPU 动态扩容了，关于更多 HPA相关的知识点，能够先检查官方文档，后面会在实战项目里运用，请小伙伴耐性等候；有疑问的小伙伴，欢迎给我留言，后续会继续共享【云原生和大数据】相关的文章，请小伙伴耐性等候哦~