k8s 自动伸缩机制-------HPA 超详细解读

目录

在K8s中扩缩容分为两种：

---

前言

弹性伸缩是根据用户的业务需求和策略，自动“调整”其“弹性资源”的管理服务。通过弹性伸缩功能，用户可设置对定时、周期或监控策略，恰到好处地增加或减少“弹性资源”，并完成实例配置，保证业务平稳健康运行 

在实际工作中，我们常常需要做一些扩容缩容操作，如：电商平台在618和双十一搞秒杀活动；由于资源紧张、工作负载降低等都需要对服务实例数进行扩缩容操作。

在K8s中扩缩容分为两种：

Node层面：对K8s物理节点扩容和缩容，根据业务规模实现物理节点自动扩缩容
Pod层面：我们一般会使用Deployment中的Replicas参数，设置多个副本集来保证服务的高可用，但是这是一个固定的值，比如我们设置10个副本，就会启10个pod同时Running来提供服务。如果这个服务平时流量很少的时候，也是10个Pod同时在Running，而流量突然暴增时，又可能出现10个Pod不够用的情况，针对这种情况就要使用扩容和缩容

 自动扩容和缩容：VPA、KPA、HPA 

 KPA（Knative Pod Autoscaler）基于请求数对Pod自动扩缩容，KPA的主要限制在于它不支持基于CPU的自动扩缩容。

• 根据并发请求数实现自动扩缩容
• 设置扩缩容边界实现自动扩缩容

扩缩容边界是指应用程序提供服务的最小和最大Pod数量。通过设置应用程序服务的最小和最大Pod数量实现自动扩缩容。

VPA

Kubernetes VPA（Vertical Pod Autoscaler）垂直Pod自动扩缩容，VPA会基于Pod的资源使用情况自动为集群设置资源占用的限制，从而让集群将Pod调度到足够资源的最佳节点上。VPA也会保持最初容器定义中资源Request和Limit的占比。

它会根据容器资源使用率自动设置Pod的CPU和内存的Request，从而允许在节点上进行适当的调度，以便为每个Pod提供适当的可用的节点。它既可以缩小过度请求资源的容器，也可以根据其使用情况随时提升资源不足的容量。

 VPA    HPA 不能同时使用

Pod自动伸缩

HPA：Pod水平自动伸缩      根据Pod的CPU(原生支持)或内存(后期的新版本支持)的平均使用率为Pod控制器管理的Pod资源副本数量实现自动扩缩容
VPA：Pod垂直自动伸缩      根据Pod容器的CPU和内存的使用率自动设置Pod容器的CPU和内存的requests资源量限制
注：HPA和VPA不要同时使用

 一、HPA

1.1HPA介绍

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

（1）HPA 基于 Master 上的 kube-controller-manager 服务启动参数 horizontal-pod-autoscaler-sync-period 定义的时长（默认为15秒），周期性的检测 Pod 的 CPU 使用率。

（2）HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。

（3）metrics-server 也需要部署到集群中， 它可以通过 resource metrics API 对外提供度量数据。(HPA通过metrices-server这个插件定期的去搜集pod的平均负载情况，再根据HPA的设置动态的去调整pod的副本数）

HPA（Horizontal Pod Autoscaler）是Kubernetes中实现自动扩缩容Pod副本数量的机制。它允许集群中的工作负载（如Deployments、ReplicaSets和StatefulSets）根据实际的负载情况自动调整Pod的数量，以此来优化资源的使用和提高服务的响应能力

1.2核心概念

水平扩展（Horizontal Scaling）：增加Pod的数量来分摊负载，与垂直扩展（增加单个Pod的资源）相对。
Pod副本（Pod Replicas）：运行应用程序的容器实例，通常是在Deployment或ReplicaSet等控制器下管理的。
指标（Metrics）：用于触发HPA扩缩容的度量值，如CPU使用率、内存使用量、自定义的应用程序指标等

1.3HPA 的配置关键参数

ScaleTargetRef：指定 HPA 将要作用的资源对象，如 Deployment、Replica Set 或 RC 的名称。
MinReplicas：最小副本数，即使在负载很低时也不会低于这个数量。
MaxReplicas：最大副本数，即使在负载很高时也不会超过这个数量。
Metrics：定义用于触发伸缩的度量标准和目标值。例如，可以设置 CPU 的利用率目标，当实际利用率超过这个目标值时，HPA 会增加副本数量；当利用率低于目标值时，HPA 会减少副本数量。

1.4关键组件

1.4.1HPA控制器（HPA Controller）

这是HPA的核心组件，负责周期性地检查Pod的资源使用情况，并根据这些信息计算出所需的Pod副本数量。

它使用Metrics Server或其他监控工具来获取资源使用数据。

1.4.2Metrics Server

Metrics Server是Kubernetes集群中的一个组件，用于聚合资源使用数据，并通过Metrics API提供这些数据。

它提供了CPU和内存使用率等资源指标，这些指标是HPA进行扩缩容决策的基础。

1.4.3自定义指标适配器（Custom Metrics Adapter）

当需要使用自定义指标（如来自Prometheus的指标）时，自定义指标适配器允许HPA使用这些外部指标。

它通过Custom Metrics API将外部指标转换为Kubernetes可以理解的格式。

1.4.4Deployment/ReplicaSet

HPA通常与Deployment或ReplicaSet一起使用，这些是定义了Pod副本数量和更新策略的高级抽象。
当HPA决定调整副本数量时，它会通过修改Deployment或ReplicaSet的规格来实现。

1.4.5Pods

Pod是Kubernetes中的基本工作单元，HPA的目标就是根据指标自动调整Pod的数量。
每个Pod可以有一个或多个容器，HPA关注的是整个Pod的资源使用情况。

1.4.6API服务器（API Server）

Kubernetes API服务器是集群的通信中心，所有资源的创建、更新和删除都通过它进行。
HPA控制器通过API服务器与集群中的其他组件交互，如更新Deployment或ReplicaSet的副本数量。

1.4.7Kubelet

Kubelet是运行在每个节点上的守护进程，负责维护Pod的生命周期，包括启动、停止容器。
当HPA触发扩容时，Kubelet会在节点上启动新的Pod实例。

1.4.8监控和日志系统

虽然不是HPA的直接组件，但监控和日志系统对于理解和调试HPA的行为至关重要。
它们提供了关于Pod状态、资源使用和扩缩容事件的详细信息。
这些组件共同工作，使得HPA能够根据实际的负载情况自动调整Pod的数量，从而实现应用程序的弹性伸缩。

1.5使用场景

应对流量波动：在Web服务中，流量可能在一天中的不同时间有很大波动。HPA可以根据流量自动调整Pod数量，以保持服务的响应性。
负载均衡：当新的Pod加入集群时，负载均衡器（如Kubernetes Service）会自动将流量路由到新的Pod，实现负载均衡。
资源优化：通过自动调整Pod数量，HPA有助于避免资源浪费，并确保资源得到最佳利用。

1.6注意事项

周期性检测：HPA 根据 kube-controller-manager 服务的启动参数 horizontal-pod-autoscaler-sync-period 来定义检测周期，默认为 30 秒。这意味着 HPA 控制器会每 30 秒检查一次 Pod 的 CPU 使用率，以决定是否需要调整副本数量。
Kubernetes 资源对象：HPA 是 Kubernetes 中的一种资源对象，与 Replication Controller（RC）、Deployment 或 Replica Set 等资源对象类似。HPA 通过监控这些控制器管理的 Pod 负载变化情况，来动态调整副本数量。例如，如果一个 Deployment 管理了多个 Pod，HPA 将会监控这些 Pod 的平均 CPU 使用率，并根据这个指标来增加或减少 Pod 的数量。
metrics-server 部署：为了使 HPA 能够获取到 Pod 的度量数据，metrics-server 必须部署在 Kubernetes 集群中。metrics-server 通过 resource metrics API 提供集群资源的使用情况，包括 CPU 和内存的使用情况。这样，HPA 就可以利用这些数据来做出伸缩决策。

 二、部署 metrics-server

2.1metrics-server介绍

metrics-server 是 Kubernetes 集群中的一个关键组件，它的作用是聚合和提供集群资源的使用情况。这些信息对于 Kubernetes 集群的各种内部组件和外部工具来说非常重要，它们依赖这些数据来进行决策和操作。以下是 metrics-server 的一些关键功能和用途：

2.1.1资源使用情况聚合

• metrics-server 收集集群中每个节点的资源使用数据，包括 CPU 和内存的使用情况。
• 它还提供了 Pod 级别的资源使用信息。

2.1.2支持 Kubernetes 核心功能

Horizontal Pod Autoscaler (HPA): HPA 依赖 metrics-server 提供的数据来自动调整 Pod 副本的数量，以保持应用程序的稳定运行。
kubectl: kubectl top 命令使用 metrics-server 的数据来显示集群中节点和 Pod 的资源使用情况。
Scheduler: Kubernetes 的调度器使用节点的资源使用情况来做出调度决策，决定在哪里运行新的 Pod。

2.1.3安全性

metrics-server 可以配置为使用安全的 kubelet API，这意味着它可以在不暴露节点上 kubelet 的端口的情况下收集资源使用数据。

2.1.4部署和维护

metrics-server 通常作为 Kubernetes 集群的一部分进行部署，它可以使用 Helm chart 或者直接从容器镜像部署。

它需要在集群中的每个节点上运行，以便收集所有节点的资源使用情况。

2.1.5配置选项

可以通过配置文件或 Helm chart 的 values 文件来调整 metrics-server 的行为，例如设置日志级别、指定 kubelet 的地址和端口、配置资源请求和限制等。

2.2部署Metrics-Server

metrics-server：是kubernetes集群资源使用情况的聚合器，收集数据给kubernetes集群内使用，如kubectl、hpa、scheduler等。

2.2.1准备 metrics-server 镜像

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

 

//在所有 Node 节点上传 metrics-server.tar 镜像包到 /opt 目录
cd /opt/
docker load -i metrics-server.tar
 
#在主master节点上执行
kubectl apply -f components.yaml

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

• 使用 docker load -i metrics-server.tar 命令加载镜像到本地 Docker 环境。

 node1 node2 同时操作

 随后，在master上面操作

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 top nodes/pods去查看cpu的情况

#部署完毕后，可以通过命令来监视pod的资源占用
kubectl top pods
 
kubectl top nodes

 

 

 三、部署 HPA 

hpa-example.tar 是谷歌基于 PHP 语言开发的用于测试 HPA 的镜像，其中包含了一些可以运行 CPU 密集计算任务的代码。

部署一个用于测试水平 Pod 自动扩缩容（HPA）的示例应用程序

3.1上传镜像文件

在所有节点上传 hpa-example.tar 镜像文件到 /opt 目录

 

cd /opt
docker load -i hpa-example.tar
 
docker images | grep hpa-example

将 hpa-example.tar 镜像文件上传到所有节点的 /opt 目录。
hpa-example.tar 是谷歌基于 PHP 语言开发的用于测试 HPA 的镜像，其中包含了一些可以运行 CPU 密集计算任务的代码。
使用 docker load -i hpa-example.tar 命令加载镜像到本地 Docker 环境。

 

 第二种方式： 就是不用每个节点都下载这个hpa-example，而是直接在创建的过程中使用特定的镜像mirrorgooglecontainers/hpa-example，或者在node节点上面通过docker  pull mirrorgooglecontainers/hpa-example ，随后写入一个yaml文件里面

随后，保存并且生成

 

 

 随后，进入到此pod中，去测试一下写一个死循环 进入其中一个pod容器仲，进行死循环模拟