Kubernetes——HPA自动伸缩机制

2024-06-11 17:28

本文主要是介绍Kubernetes——HPA自动伸缩机制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

目录

前言

一、概念

1.定义

2.核心概念

3.工作原理

4.HPA的配置关键参数

5.关键组件

5.1HPA控制器(HPA Controller)

5.2Metrics Server

5.3自定义指标适配器(Custom Metrics Adapter)

5.4Deployment/ReplicaSet

5.5Pods

5.6API服务器(API Server)

5.7Kubelet

5.8监控和日志系统

6.使用场景

7.注意事项

8.如何确保程序稳定和服务连续

8.1快速扩容

8.2缓慢缩容

8.3缩放策略

二、Metrics-Server

1.定义

2.部署Metrics-Server

2.1准备镜像

2.2使用Helm安装Metrics-Server

2.3配置Metrics-Server

2.4安装Metrics-Server

2.5验证Metrics-Server部署

三、部署HPA

1.上传镜像文件

2.创建Deployment和Service资源

四、配置和使用HPA

1.创建HPA控制器

2.监控HPA状态

3.压力测试

4.查看Pod状态

五、资源限制

1.资源限制饿重要性

2.Cgroup的作用

3.Pod资源限制

4.命名空间资源限制

4.1ResourceQuota

4.2LimitRange

六、总结

1.HPA

2.Kubectl 资源限制


前言

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

在实际工作中,我们常常需要做一些扩容缩容操作,如:电商平台在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提供适当的可用的节点。它既可以缩小过度请求资源的容器,也可以根据其使用情况随时提升资源不足的容量。

一、概念

1.定义

HPA(Horizontal Pod Autoscaler[Pod水平自动伸缩])是Kubernetes中实现自动扩缩容Pod副本数量的机制。它允许集群中的工作负载(如Deployments、ReplicaSets和StatefulSets)根据实际的负载情况自动调整Pod的数量,以此来优化资源的使用和提高服务的响应能力。通过此功能,只需简单的配置,便可以利用监控指标(CPU使用率、磁盘、自定义指标等)自动的扩容或缩容服务中的Pod数量,当业务需求增加时,系统将无缝地自动添加适量Pod容器,提高系统稳定性。

HPA的API有三个版本,通过Kubectl api-versions | grep autoscal可看到autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2 #autoscaling/v1 只支持基于CPU指标的缩放
autoscaling/v2beta1支持Resource Metrics(资源指标,如Pod的内存)和Custom Metrics(自定义指标)的缩放
autoscaling/v2beta2支持Resource Metrics(资源指标,如Pod的内存)和Custom Metrics

HPA/v1版本只能基于CPU做扩容

HPA/v2版本可以基于内存和自定义的指标做扩容和缩容 

Pod自动缩放不适用于无法缩放的对象,比如DaemonSet;

HPA由Kubernetes API 资源和控制器实现。控制器会周期性的获取平均CPU利用率,并与目标值相比较后调整Deployment中的副本数量

2.核心概念

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

3.工作原理

  • 指标收集:HPA监控Pod的资源使用情况,如CPU和内存利用率。这些指标可以通过Kubernetes的Metrics API获取,或者使用自定义的指标提供者(如Prometheus)。
  • 计算扩缩容:HPA根据当前的资源使用情况和预设的目标值(如CPU的目标利用率)计算出所需的Pod副本数量。如果当前的资源使用超过了目标值,HPA会增加Pod副本数量;如果资源使用低于目标值,HPA会减少Pod副本数量。
  • 执行扩缩容:HPA通过更新相关的Deployment或ReplicaSet来改变Pod副本的数量。增加副本时,Kubernetes会创建新的Pod;减少副本时,会删除多余的Pod。

如何实现自动扩缩容?

K8s的HPA Controller已经实现了一套简单的自动扩缩容逻辑,默认情况下,每30秒检测一次指标,只要检测到了配置HPA的目标值,则会计算出预期的工作负载的副本数,再进行扩缩容操作。同时,为了避免过于频繁的扩缩容,默认再5分钟内没有重新扩缩容的情况下,才会触发扩缩容。HPA本身的算法相对比较保守,可能并不适用于很多场景。例如,一个快速的流量突发场景,如果正处在5分钟内的HPA稳定期,这个时候根据HPA的策略,会导致无法扩容。 

4.HPA的配置关键参数

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

5.关键组件

5.1HPA控制器(HPA Controller)

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

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

5.2Metrics Server

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

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

5.3自定义指标适配器(Custom Metrics Adapter)

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

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

5.4Deployment/ReplicaSet

HPA通常与Deployment或ReplicaSet一起使用,这些是定义了Pod副本数量和更新策略的高级抽象。

当HPA决定调整副本数量时,它会通过修改Deployment或ReplicaSet的规格来实现。

5.5Pods

Pod是Kubernetes中的基本工作单元,HPA的目标就是根据指标自动调整Pod的数量。

每个Pod可以有一个或多个容器,HPA关注的是整个Pod的资源使用情况。

5.6API服务器(API Server)

Kubernetes API服务器是集群的通信中心,所有资源的创建、更新和删除都通过它进行。

HPA控制器通过API服务器与集群中的其他组件交互,如更新Deployment或ReplicaSet的副本数量。

5.7Kubelet

Kubelet是运行在每个节点上的守护进程,负责维护Pod的生命周期,包括启动、停止容器。

当HPA触发扩容时,Kubelet会在节点上启动新的Pod实例。

5.8监控和日志系统

虽然不是HPA的直接组件,但监控和日志系统对于理解和调试HPA的行为至关重要。

它们提供了关于Pod状态、资源使用和扩缩容事件的详细信息。

这些组件共同工作,使得HPA能够根据实际的负载情况自动调整Pod的数量,从而实现应用程序的弹性伸缩。

6.使用场景

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

7.注意事项

  • 周期性检测: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 就可以利用这些数据来做出伸缩决策。

8.如何确保程序稳定和服务连续

8.1快速扩容

当 CPU 负载超过 HPA 设置的目标百分比时,HPA 会迅速增加 Pod 的副本数,以快速分摊负载并减轻单个 Pod 的压力。

快速扩容有助于避免性能瓶颈和响应时间的显著增加,这对于保持用户体验和服务质量至关重要。

8.2缓慢缩容

当 CPU 负载下降到目标百分比以下时,HPA 不会立即减少 Pod 的副本数。这是因为

  • 稳定性: 快速缩容可能会导致服务不稳定,尤其是在业务高峰期。如果缩容过于积极,剩余的 Pod 可能无法处理突然增加的负载,从而导致服务中断。
  • 避免震荡: 避免因网络波动或其他临时负载变化导致的不必要缩放。缓慢缩容有助于减少因缩放操作本身引起的性能震荡。
  • 预热: 新创建的 Pod 需要时间来“预热”,即加载应用资源、建立网络连接等。缓慢缩容可以确保在移除 Pod 之前,它们已经为服务做好了准备。

8.3缩放策略

  • HPA 缩放策略包括两个主要参数:scaleDownDelayAfterAdd 和 scaleDownUnneededTime。
  • scaleDownDelayAfterAdd 控制在添加新 Pod 后,HPA 等待多长时间才开始考虑缩放操作。
  • scaleDownUnneededTime 控制在 Pod 被认为是“不需要”的之前,HPA 等待多长时间。这个时间过后,如果 Pod 仍然没有达到 CPU 使用率目标,HPA 将开始缩放过程。

通过这种设计,Kubernetes HPA 旨在平衡快速响应和资源稳定性之间的关系,确保在面对不断变化的负载时,应用程序能够持续稳定地运行。这种平衡有助于避免因缩放操作导致的服务中断和性能问题。

二、Metrics-Server

1.定义

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

  • 资源使用情况聚合
    • metrics-server 收集集群中每个节点的资源使用数据,包括 CPU 和内存的使用情况。
    • 它还提供了 Pod 级别的资源使用信息。
  • 支持 Kubernetes 核心功能
    • Horizontal Pod Autoscaler (HPA): HPA 依赖 metrics-server 提供的数据来自动调整 Pod 副本的数量,以保持应用程序的稳定运行。
    • kubectl: kubectl top 命令使用 metrics-server 的数据来显示集群中节点和 Pod 的资源使用情况。
    • Scheduler: Kubernetes 的调度器使用节点的资源使用情况来做出调度决策,决定在哪里运行新的 Pod。
  • 安全性:
    • metrics-server 可以配置为使用安全的 kubelet API,这意味着它可以在不暴露节点上 kubelet 的端口的情况下收集资源使用数据。
  • 部署和维护:
    • metrics-server 通常作为 Kubernetes 集群的一部分进行部署,它可以使用 Helm chart 或者直接从容器镜像部署。
    • 它需要在集群中的每个节点上运行,以便收集所有节点的资源使用情况。
  • 配置选项:
    • 可以通过配置文件或 Helm chart 的 values 文件来调整 metrics-server 的行为,例如设置日志级别、指定 kubelet 的地址和端口、配置资源请求和限制等。

2.部署Metrics-Server

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

2.1准备镜像

#准备 metrics-server 镜像
cd /opt/
#将 metrics-server 的镜像包 metrics-server.tar 上传到所有 Node 节点的 /opt 目录
docker load -i metrics-server.tar
#加载镜像到本地 Docker 环境

2.2使用Helm安装Metrics-Server

mkdir /opt/metrics
cd /opt/metrics
#创建一个目录 /opt/metrics 用于存放 metrics-server 的配置文件#移除旧的 Helm 仓库(如果已添加)
helm repo remove stable#添加新的 Helm 仓库,可以选择使用官方源或镜像源,建议使用官方
helm repo add stable https://charts.helm.sh/stable
# 或
helm repo add stable http://mirror.azure.cn/kubernetes/charts#更新 Helm 仓库
helm repo update#从 Helm 仓库拉取 metrics-server chart
helm pull stable/metrics-server

2.3配置Metrics-Server

vim metrics-server.yaml
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-types=InternalIP
image:repository: k8s.gcr.io/metrics-server-amd64tag: v0.3.2#编辑 metrics-server.yaml 文件,配置 metrics-server 的参数,例如指定镜像仓库和标签,以及设置日志参数等

2.4安装Metrics-Server

helm install metrics-server stable/metrics-server -n kube-system -f metrics-server.yaml
#使用 helm install 命令安装 metrics-server 到 kube-system 命名空间,并应用自定义的配置文件

2.5验证Metrics-Server部署

使用 kubectl get pods -n kube-system | grep metrics-server 命令查看 metrics-server Pod 是否成功部署

kubectl top node
#查看节点资源使用情况kubectl top pods --all-namespaces
#查看所有命名空间中的 Pod 资源使用情况

通过这些步骤,可以确保 metrics-server 成功部署在 Kubernetes 集群中,并且可以提供集群资源使用情况的聚合信息,这对于 Kubernetes 集群的运维和自动扩缩容策略的实施非常关键。

三、部署HPA

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

1.上传镜像文件

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

2.创建Deployment和Service资源

vim hpa-pod.yamlapiVersion: apps/v1
kind: Deployment
metadata:labels:run: php-apachename: php-apache
spec:replicas: 1selector:matchLabels:run: php-apachetemplate:metadata:labels:run: php-apachespec:containers:- image: gcr.io/google_containers/hpa-examplename: php-apacheimagePullPolicy: IfNotPresentports:- containerPort: 80resources:requests:cpu: 200m
#指定 hpa-example 镜像,并设置 CPU 请求资源为 200m(200 毫核)
---
apiVersion: v1
kind: Service
metadata:name: php-apache
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:run: php-apache
#创建 Service 以暴露 Deployment 中的 Pod,使其可以通过网络访问kubectl apply -f hpa-pod.yamlkubectl get pods

通过这些步骤,可以在 Kubernetes 集群中部署一个应用程序,并使用 HPA 根据实际负载自动调整 Pod 副本数,从而实现应用程序的自动扩缩容。

四、配置和使用HPA

在 Kubernetes 集群中使用 kubectl autoscale 命令创建一个水平 Pod 自动扩缩容(HPA)控制器,并对其进行了压力测试

1.创建HPA控制器

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
#使用 kubectl autoscale 命令创建 HPA 控制器,设置 CPU 负载阈值为请求资源的 50%,并指定最小和最大 Pod 数量限制

2.监控HPA状态

#需要等一会儿,才能获取到指标信息 TARGETS
kubectl get hpa
#使用 kubectl get hpa 命令查看 HPA 的状态,包括当前的 CPU 负载百分比、最小和最大 Pod 数量以及当前的 Pod 副本数。kubectl top pods

3.压力测试

kubectl run -it load-generator --image=busybox /bin/sh
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
#增加负载#创建一个临时的测试客户端容器,使用 kubectl run 命令启动一个 busybox 容器,并在其中运行一个无限循环的 wget 命令,以模拟对 php-apache 服务的持续访问

#打开一个新的窗口,查看负载节点数目
kubectl get hpa -w#观察 HPA 控制器的响应,可以看到随着 CPU 负载的增加,Pod 的副本数从 1 个增加到最大限制的 10 个

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

4.查看Pod状态

kubectl get pods
#查看 Pod 状态,也发现已经创建了 10 个 Pod 资源

通过这个过程,验证了 HPA 控制器能够根据实际的 CPU 负载情况自动调整 Pod 的数量,以保持服务的稳定性和响应性。当 CPU 负载超过设定的阈值时,HPA 控制器会增加 Pod 的副本数以分摊负载;当负载降低时,它会减少 Pod 的数量以节省资源。这种自动扩缩容机制对于处理不同负载情况下的应用程序非常有用,它有助于提高资源利用率和用户体验。

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

五、资源限制

1.资源限制饿重要性

  • 防止资源饥饿: 通过为 Pod 设置资源请求(requests)和限制(limits),可以防止单个应用程序消耗过多资源,导致其他应用程序因资源不足而受到影响。
  • 优先级和抢占: 资源限制还与 Pod 的调度和优先级相关。Kubernetes 可以根据 Pod 的资源请求和限制来决定哪些 Pod 应该在资源紧张时被调度或抢占。
  • 成本管理: 通过合理配置资源限制,可以避免在云环境中过度使用资源,从而有助于控制成本。

2.Cgroup的作用

  • 控制组: cgroup(Control Groups)是 Linux 内核的一个特性,它允许对系统资源进行分组管理和限制。
  • 资源隔离: cgroup 通过为每个组设置资源配额和限制,实现了对 CPU、内存、I/O 等资源的隔离和控制。

3.Pod资源限制

  • requests: 指定 Pod 运行所需的最小资源量。Kubernetes 调度器会考虑这些请求来决定在哪个节点上调度 Pod。如果节点无法满足 Pod 的资源请求,Pod 将不会被调度到该节点。
  • limits: 指定 Pod 可以使用的最大资源量。如果 Pod 尝试使用超过其限制的资源,系统将通过 cgroup 强制限制资源使用,可能会导致 Pod 被杀死或重启。
spec:containers:- image: xxxximagePullPolicy: IfNotPresentname: authports:- containerPort: 8080protocol: TCPresources:limits:cpu: "2"        # 限制 CPU 使用量为 2 个单位(可以是核心数或毫核)memory: 1Gi     # 限制内存使用量为 1Gi(Gibibytes)requests:cpu: 250m       # 请求 CPU 使用量为 250 毫核memory: 250Mi    # 请求内存使用量为 250Mi(Mebibytes)#在这个配置中,auth 容器请求了 250 毫核的 CPU 和 250Mi 的内存,同时设置了 2 个单位的 CPU 和 1Gi 内存的限制。这意味着 Kubernetes 会确保 auth 容器至少有 250 毫核的 CPU 和 250Mi 的内存可用,但如果资源充足,它可以使用更多,但不会超过 2 个单位的 CPU 和 1Gi 的内存。#通过这种方式,可以为 Kubernetes 集群中的 Pod 设置合理的资源请求和限制,以确保应用程序的性能和稳定性,同时优化资源的使用。

4.命名空间资源限制

在 Kubernetes 中使用 ResourceQuota 和 LimitRange 资源类型来对命名空间级别的资源使用进行限制和管理

4.1ResourceQuota

ResourceQuota 允许管理员限制命名空间中可以使用的计算资源和配置对象的数量。这有助于防止意外的资源过度使用,确保集群资源的公平分配。

#计算资源配额apiVersion: v1
kind: ResourceQuota         #使用 ResourceQuota 资源类型
metadata:name: compute-resourcesnamespace: spark-cluster  #指定命令空间
spec:hard:pods: "20"              #设置 Pod 数量最大值requests.cpu: "2"       #所有 Pod 总和的 内存 请求量上限requests.memory: 1Gi    #所有 Pod 总和的 CPU 请求量上限limits.cpu: "4"         #单个 Pod 能够使用的 CPU 上限limits.memory: 2Gi      #单个 Pod 能够使用的 内存 上限
#配置对象数量配额限制apiVersion: v1
kind: ResourceQuota
metadata:name: object-countsnamespace: spark-cluster
spec:hard:configmaps: "10"persistentvolumeclaims: "4"        #设置 pvc 数量最大值replicationcontrollers: "20"       #设置 rc 数量最大值secrets: "10"services: "10"services.loadbalancers: "2"        #特别限制了使用负载均衡器类型的服务数量

4.2LimitRange

如果Pod没有设置requests和limits,则会使用当前命名空间的最大资源;如果命名空间也没设置,则会使用集群的最大资源。K8S 会根据 limits 限制 Pod 使用资源,当内存超过 limits 时 cgruops 会触发 OOM。

LimitRange 允许管理员设置命名空间中 Pod 或容器的资源请求和限制的默认值。这有助于确保即使 Pod 没有明确设置 requests 和 limits,也不会超出命名空间或集群级别的资源限制。

apiVersion: v1
kind: LimitRange        #使用 LimitRange 资源类型
metadata:name: mem-limit-rangenamespace: test       #可以给指定的 namespace 增加一个资源限制
spec:limits:- default:            #default 即 limit 的值memory: 512Micpu: 500mdefaultRequest:     #defaultRequest 即 request 的值memory: 256Micpu: 100mtype: Container     #类型支持 Container、Pod、PVC

 通过这些资源限制,Kubernetes 管理员可以精细地控制集群资源的使用,避免资源浪费,并确保集群的稳定性和效率。这些限制对于多租户环境或需要严格资源管理的场景尤为重要。

六、总结

1.HPA

  • HPA:为控制器管理的Pod资源的副本数量实现自动伸缩
  • 原理:追踪控制器管理的Pod负载情况,来根据设置的阀值动态的调整Pod副本的数量
  • Metrics-Server:收集K8s当中的Pods、Pod等资源使用情况,使用Kubectl top node/pod命令行
  • Kubectl autoscale 控制器 --cpuprecent= 60 --min --max 最大值

2.Kubectl 资源限制

  • Resource.Request/limits:限制Pod的容器的资源量
  • ResourceQuota:资源类型对命名空间的资源对象或者量 进行配额限制
  • LimitRanger:资源类型设置命名空间中 Pod(容器默认的)  资源限制 Limit Request

这篇关于Kubernetes——HPA自动伸缩机制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1051809

相关文章

JVM 的类初始化机制

前言 当你在 Java 程序中new对象时,有没有考虑过 JVM 是如何把静态的字节码(byte code)转化为运行时对象的呢,这个问题看似简单,但清楚的同学相信也不会太多,这篇文章首先介绍 JVM 类初始化的机制,然后给出几个易出错的实例来分析,帮助大家更好理解这个知识点。 JVM 将字节码转化为运行时对象分为三个阶段,分别是:loading 、Linking、initialization

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注,收藏不迷路💖 Kubernetes的PodSecurityPolicy(PSP)是一个关键的安全特性,它在Pod创建之前实施安全策略,确保P

Java ArrayList扩容机制 (源码解读)

结论:初始长度为10,若所需长度小于1.5倍原长度,则按照1.5倍扩容。若不够用则按照所需长度扩容。 一. 明确类内部重要变量含义         1:数组默认长度         2:这是一个共享的空数组实例,用于明确创建长度为0时的ArrayList ,比如通过 new ArrayList<>(0),ArrayList 内部的数组 elementData 会指向这个 EMPTY_EL

K8S(Kubernetes)开源的容器编排平台安装步骤详解

K8S(Kubernetes)是一个开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。以下是K8S容器编排平台的安装步骤、使用方式及特点的概述: 安装步骤: 安装Docker:K8S需要基于Docker来运行容器化应用程序。首先要在所有节点上安装Docker引擎。 安装Kubernetes Master:在集群中选择一台主机作为Master节点,安装K8S的控制平面组件,如AP

什么是Kubernetes PodSecurityPolicy?

@TOC 💖The Begin💖点点关注,收藏不迷路💖 1、什么是PodSecurityPolicy? PodSecurityPolicy(PSP)是Kubernetes中的一个安全特性,用于在Pod创建前进行安全策略检查,限制Pod的资源使用、运行权限等,提升集群安全性。 2、为什么需要它? 默认情况下,Kubernetes允许用户自由创建Pod,可能带来安全风险。

基于51单片机的自动转向修复系统的设计与实现

文章目录 前言资料获取设计介绍功能介绍设计清单具体实现截图参考文献设计获取 前言 💗博主介绍:✌全网粉丝10W+,CSDN特邀作者、博客专家、CSDN新星计划导师,一名热衷于单片机技术探索与分享的博主、专注于 精通51/STM32/MSP430/AVR等单片机设计 主要对象是咱们电子相关专业的大学生,希望您们都共创辉煌!✌💗 👇🏻 精彩专栏 推荐订阅👇🏻 单片机

【编程底层思考】垃圾收集机制,GC算法,垃圾收集器类型概述

Java的垃圾收集(Garbage Collection,GC)机制是Java语言的一大特色,它负责自动管理内存的回收,释放不再使用的对象所占用的内存。以下是对Java垃圾收集机制的详细介绍: 一、垃圾收集机制概述: 对象存活判断:垃圾收集器定期检查堆内存中的对象,判断哪些对象是“垃圾”,即不再被任何引用链直接或间接引用的对象。内存回收:将判断为垃圾的对象占用的内存进行回收,以便重新使用。

【Tools】大模型中的自注意力机制

摇来摇去摇碎点点的金黄 伸手牵来一片梦的霞光 南方的小巷推开多情的门窗 年轻和我们歌唱 摇来摇去摇着温柔的阳光 轻轻托起一件梦的衣裳 古老的都市每天都改变模样                      🎵 方芳《摇太阳》 自注意力机制(Self-Attention)是一种在Transformer等大模型中经常使用的注意力机制。该机制通过对输入序列中的每个元素计算与其他元素之间的相似性,

如何通俗理解注意力机制?

1、注意力机制(Attention Mechanism)是机器学习和深度学习中一种模拟人类注意力的方法,用于提高模型在处理大量信息时的效率和效果。通俗地理解,它就像是在一堆信息中找到最重要的部分,把注意力集中在这些关键点上,从而更好地完成任务。以下是几个简单的比喻来帮助理解注意力机制: 2、寻找重点:想象一下,你在阅读一篇文章的时候,有些段落特别重要,你会特别注意这些段落,反复阅读,而对其他部分

Python3 BeautifulSoup爬虫 POJ自动提交

POJ 提交代码采用Base64加密方式 import http.cookiejarimport loggingimport urllib.parseimport urllib.requestimport base64from bs4 import BeautifulSoupfrom submitcode import SubmitCodeclass SubmitPoj():de