晋城市 制作网站,网站建设团队分工,小程序代理哪家好,合肥网站关键词优化公司目录 一、概念
核心概念
工作原理
HPA 的配置关键参数
关键组件
使用场景
注意事项
如何确保程序稳定和服务连续
二、metrics-server
部署 metrics-server
准备 metrics-server 镜像:
使用 Helm 安装 metrics-server:
配置 metrics-server:
安装 metrics-server: …
目录 一、概念
核心概念
工作原理
HPA 的配置关键参数
关键组件
使用场景
注意事项
如何确保程序稳定和服务连续
二、metrics-server
部署 metrics-server
准备 metrics-server 镜像:
使用 Helm 安装 metrics-server:
配置 metrics-server:
安装 metrics-server:
验证 metrics-server 部署:
三、部署 HPA
上传镜像文件:
创建 Deployment 和 Service 资源:
应用资源定义:
四、配置和使用 HPA
创建 HPA 控制器
监控 HPA 状态
压力测试
查看 Pod 状态
五、资源限制
资源限制的重要性
cgroup 的作用
Pod 资源限制
示例配置解释
命名空间资源限制
ResourceQuota
计算资源配额:
配置对象数量配额限制:
LimitRange 一、概念
HPAHorizontal Pod Autoscaler是Kubernetes中实现自动扩缩容Pod副本数量的机制。它允许集群中的工作负载如Deployments、ReplicaSets和StatefulSets根据实际的负载情况自动调整Pod的数量以此来优化资源的使用和提高服务的响应能力。
核心概念 水平扩展Horizontal Scaling增加Pod的数量来分摊负载与垂直扩展增加单个Pod的资源相对。 Pod副本Pod Replicas运行应用程序的容器实例通常是在Deployment或ReplicaSet等控制器下管理的。 指标Metrics用于触发HPA扩缩容的度量值如CPU使用率、内存使用量、自定义的应用程序指标等。
工作原理 指标收集HPA监控Pod的资源使用情况如CPU和内存利用率。这些指标可以通过Kubernetes的Metrics API获取或者使用自定义的指标提供者如Prometheus。 计算扩缩容HPA根据当前的资源使用情况和预设的目标值如CPU的目标利用率计算出所需的Pod副本数量。如果当前的资源使用超过了目标值HPA会增加Pod副本数量如果资源使用低于目标值HPA会减少Pod副本数量。 执行扩缩容HPA通过更新相关的Deployment或ReplicaSet来改变Pod副本的数量。增加副本时Kubernetes会创建新的Pod减少副本时会删除多余的Pod。
HPA 的配置关键参数 ScaleTargetRef指定 HPA 将要作用的资源对象如 Deployment、Replica Set 或 RC 的名称。 MinReplicas最小副本数即使在负载很低时也不会低于这个数量。 MaxReplicas最大副本数即使在负载很高时也不会超过这个数量。 Metrics定义用于触发伸缩的度量标准和目标值。例如可以设置 CPU 的利用率目标当实际利用率超过这个目标值时HPA 会增加副本数量当利用率低于目标值时HPA 会减少副本数量。
关键组件 HPA控制器HPA Controller 这是HPA的核心组件负责周期性地检查Pod的资源使用情况并根据这些信息计算出所需的Pod副本数量。 它使用Metrics Server或其他监控工具来获取资源使用数据。 Metrics Server Metrics Server是Kubernetes集群中的一个组件用于聚合资源使用数据并通过Metrics API提供这些数据。 它提供了CPU和内存使用率等资源指标这些指标是HPA进行扩缩容决策的基础。 自定义指标适配器Custom Metrics Adapter 当需要使用自定义指标如来自Prometheus的指标时自定义指标适配器允许HPA使用这些外部指标。 它通过Custom Metrics API将外部指标转换为Kubernetes可以理解的格式。 Deployment/ReplicaSet HPA通常与Deployment或ReplicaSet一起使用这些是定义了Pod副本数量和更新策略的高级抽象。 当HPA决定调整副本数量时它会通过修改Deployment或ReplicaSet的规格来实现。 Pods Pod是Kubernetes中的基本工作单元HPA的目标就是根据指标自动调整Pod的数量。 每个Pod可以有一个或多个容器HPA关注的是整个Pod的资源使用情况。 API服务器API Server Kubernetes API服务器是集群的通信中心所有资源的创建、更新和删除都通过它进行。 HPA控制器通过API服务器与集群中的其他组件交互如更新Deployment或ReplicaSet的副本数量。 Kubelet Kubelet是运行在每个节点上的守护进程负责维护Pod的生命周期包括启动、停止容器。 当HPA触发扩容时Kubelet会在节点上启动新的Pod实例。 监控和日志系统 虽然不是HPA的直接组件但监控和日志系统对于理解和调试HPA的行为至关重要。 它们提供了关于Pod状态、资源使用和扩缩容事件的详细信息。 这些组件共同工作使得HPA能够根据实际的负载情况自动调整Pod的数量从而实现应用程序的弹性伸缩。
使用场景 应对流量波动在Web服务中流量可能在一天中的不同时间有很大波动。HPA可以根据流量自动调整Pod数量以保持服务的响应性。 负载均衡当新的Pod加入集群时负载均衡器如Kubernetes Service会自动将流量路由到新的Pod实现负载均衡。 资源优化通过自动调整Pod数量HPA有助于避免资源浪费并确保资源得到最佳利用。
注意事项 周期性检测HPA 根据 kube-controller-manager 服务的启动参数 horizontal-pod-autoscaler-sync-period 来定义检测周期默认为 30 秒。这意味着 HPA 控制器会每 30 秒检查一次 Pod 的 CPU 使用率以决定是否需要调整副本数量。 Kubernetes 资源对象HPA 是 Kubernetes 中的一种资源对象与 Replication ControllerRC、Deployment 或 Replica Set 等资源对象类似。HPA 通过监控这些控制器管理的 Pod 负载变化情况来动态调整副本数量。例如如果一个 Deployment 管理了多个 PodHPA 将会监控这些 Pod 的平均 CPU 使用率并根据这个指标来增加或减少 Pod 的数量。 metrics-server 部署为了使 HPA 能够获取到 Pod 的度量数据metrics-server 必须部署在 Kubernetes 集群中。metrics-server 通过 resource metrics API 提供集群资源的使用情况包括 CPU 和内存的使用情况。这样HPA 就可以利用这些数据来做出伸缩决策。
如何确保程序稳定和服务连续 快速扩容: 当 CPU 负载超过 HPA 设置的目标百分比时HPA 会迅速增加 Pod 的副本数以快速分摊负载并减轻单个 Pod 的压力。 快速扩容有助于避免性能瓶颈和响应时间的显著增加这对于保持用户体验和服务质量至关重要。 缓慢缩容: 当 CPU 负载下降到目标百分比以下时HPA 不会立即减少 Pod 的副本数。这是因为 稳定性: 快速缩容可能会导致服务不稳定尤其是在业务高峰期。如果缩容过于积极剩余的 Pod 可能无法处理突然增加的负载从而导致服务中断。 避免震荡: 避免因网络波动或其他临时负载变化导致的不必要缩放。缓慢缩容有助于减少因缩放操作本身引起的性能震荡。 预热: 新创建的 Pod 需要时间来“预热”即加载应用资源、建立网络连接等。缓慢缩容可以确保在移除 Pod 之前它们已经为服务做好了准备。 缩放策略: HPA 缩放策略包括两个主要参数scaleDownDelayAfterAdd 和 scaleDownUnneededTime。 scaleDownDelayAfterAdd 控制在添加新 Pod 后HPA 等待多长时间才开始考虑缩放操作。 scaleDownUnneededTime 控制在 Pod 被认为是“不需要”的之前HPA 等待多长时间。这个时间过后如果 Pod 仍然没有达到 CPU 使用率目标HPA 将开始缩放过程。
通过这种设计Kubernetes HPA 旨在平衡快速响应和资源稳定性之间的关系确保在面对不断变化的负载时应用程序能够持续稳定地运行。这种平衡有助于避免因缩放操作导致的服务中断和性能问题。
二、metrics-server
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 的地址和端口、配置资源请求和限制等。
部署 metrics-server
metrics-server是kubernetes集群资源使用情况的聚合器收集数据给kubernetes集群内使用如kubectl、hpa、scheduler等。
准备 metrics-server 镜像: 将 metrics-server 的镜像包 metrics-server.tar 上传到所有 Node 节点的 /opt 目录。 使用 docker load -i metrics-server.tar 命令加载镜像到本地 Docker 环境。
cd /opt/
docker load -i metrics-server.tar使用 Helm 安装 metrics-server:
创建一个目录 /opt/metrics 用于存放 metrics-server 的配置文件。
mkdir /opt/metrics
cd /opt/metrics移除旧的 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配置 metrics-server:
编辑 metrics-server.yaml 文件配置 metrics-server 的参数例如指定镜像仓库和标签以及设置日志参数等。
vim metrics-server.yaml
args:
- --logtostderr
- --kubelet-insecure-tls
- --kubelet-preferred-address-typesInternalIP
image:repository: k8s.gcr.io/metrics-server-amd64tag: v0.3.2安装 metrics-server:
使用 helm install 命令安装 metrics-server 到 kube-system 命名空间并应用自定义的配置文件
helm install metrics-server stable/metrics-server -n kube-system -f metrics-server.yaml验证 metrics-server 部署:
使用 kubectl get pods -n kube-system | grep metrics-server 命令查看 metrics-server Pod 是否成功部署。
helm install metrics-server stable/metrics-server -n kube-system -f metrics-server.yaml等待一段时间后可以使用 kubectl top node 命令查看节点资源使用情况。
kubectl top node使用 kubectl top pods --all-namespaces 命令查看所有命名空间中的 Pod 资源使用情况。
kubectl top pods --all-namespaces通过这些步骤可以确保 metrics-server 成功部署在 Kubernetes 集群中并且可以提供集群资源使用情况的聚合信息这对于 Kubernetes 集群的运维和自动扩缩容策略的实施非常关键。
三、部署 HPA
部署一个用于测试水平 Pod 自动扩缩容HPA的示例应用程序
上传镜像文件: 将 hpa-example.tar 镜像文件上传到所有节点的 /opt 目录。 hpa-example.tar 是谷歌基于 PHP 语言开发的用于测试 HPA 的镜像其中包含了一些可以运行 CPU 密集计算任务的代码。 使用 docker load -i hpa-example.tar 命令加载镜像到本地 Docker 环境。
cd /opt
docker load -i hpa-example.tar确认镜像已正确加载使用 docker images | grep hpa-example 命令查看镜像列表。
docker images | grep hpa-example创建 Deployment 和 Service 资源:
创建一个名为 hpa-pod.yaml 的文件定义一个 Deployment 和一个 Service 资源。
vim hpa-pod.yaml
apiVersion: 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
---
apiVersion: v1
kind: Service
metadata:name: php-apache
spec:ports:- port: 80protocol: TCPtargetPort: 80selector:run: php-apache在 Deployment 中指定 hpa-example 镜像并设置 CPU 请求资源为 200m200 毫核。 创建 Service 以暴露 Deployment 中的 Pod使其可以通过网络访问。
应用资源定义: 使用 kubectl apply -f hpa-pod.yaml 命令应用资源定义创建 Deployment 和 Service。 使用 kubectl get pods 命令查看 Pod 状态确认 Pod 已成功创建并处于运行状态。
kubectl apply -f hpa-pod.yamlkubectl get pods通过这些步骤可以在 Kubernetes 集群中部署一个应用程序并使用 HPA 根据实际负载自动调整 Pod 副本数从而实现应用程序的自动扩缩容。
四、配置和使用 HPA
在 Kubernetes 集群中使用 kubectl autoscale 命令创建一个水平 Pod 自动扩缩容HPA控制器并对其进行了压力测试
创建 HPA 控制器
使用 kubectl autoscale 命令创建 HPA 控制器设置 CPU 负载阈值为请求资源的 50%并指定最小和最大 Pod 数量限制
kubectl autoscale deployment php-apache --cpu-percent50 --min1 --max10监控 HPA 状态
使用 kubectl get hpa 命令查看 HPA 的状态包括当前的 CPU 负载百分比、最小和最大 Pod 数量以及当前的 Pod 副本数。
//需要等一会儿才能获取到指标信息 TARGETS
kubectl get hpakubectl top pods压力测试
创建一个临时的测试客户端容器使用 kubectl run 命令启动一个 busybox 容器并在其中运行一个无限循环的 wget 命令以模拟对 php-apache 服务的持续访问
kubectl run -it load-generator --imagebusybox /bin/sh
#增加负载
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done观察 HPA 控制器的响应可以看到随着 CPU 负载的增加Pod 的副本数从 1 个增加到最大限制的 10 个。
#打开一个新的窗口查看负载节点数目
kubectl get hpa -w#如果 cpu 性能较好导致负载节点上升不到 10 个可再创建一个测试客户端同时测试
kubectl run -i --tty load-generator1 --imagebusybox /bin/sh
# 加负载
while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done查看 Pod 状态
使用 kubectl get pods 命令查看集群中的 Pod 状态确认已经根据负载增加了新的 Pod 实例。
kubectl get pods通过这个过程验证了 HPA 控制器能够根据实际的 CPU 负载情况自动调整 Pod 的数量以保持服务的稳定性和响应性。当 CPU 负载超过设定的阈值时HPA 控制器会增加 Pod 的副本数以分摊负载当负载降低时它会减少 Pod 的数量以节省资源。这种自动扩缩容机制对于处理不同负载情况下的应用程序非常有用它有助于提高资源利用率和用户体验。 五、资源限制
资源限制的重要性 防止资源饥饿: 通过为 Pod 设置资源请求requests和限制limits可以防止单个应用程序消耗过多资源导致其他应用程序因资源不足而受到影响。 优先级和抢占: 资源限制还与 Pod 的调度和优先级相关。Kubernetes 可以根据 Pod 的资源请求和限制来决定哪些 Pod 应该在资源紧张时被调度或抢占。 成本管理: 通过合理配置资源限制可以避免在云环境中过度使用资源从而有助于控制成本。
cgroup 的作用 控制组: cgroupControl Groups是 Linux 内核的一个特性它允许对系统资源进行分组管理和限制。 资源隔离: cgroup 通过为每个组设置资源配额和限制实现了对 CPU、内存、I/O 等资源的隔离和控制。
Pod 资源限制 requests: 指定 Pod 运行所需的最小资源量。Kubernetes 调度器会考虑这些请求来决定在哪个节点上调度 Pod。如果节点无法满足 Pod 的资源请求Pod 将不会被调度到该节点。 limits: 指定 Pod 可以使用的最大资源量。如果 Pod 尝试使用超过其限制的资源系统将通过 cgroup 强制限制资源使用可能会导致 Pod 被杀死或重启。
示例配置解释
在提供的示例中定义了一个包含资源限制的 Pod 配置
spec:containers:- image: xxxximagePullPolicy: IfNotPresentname: authports:- containerPort: 8080protocol: TCPresources:limits:cpu: 2 # 限制 CPU 使用量为 2 个单位可以是核心数或毫核memory: 1Gi # 限制内存使用量为 1GiGibibytesrequests:cpu: 250m # 请求 CPU 使用量为 250 毫核memory: 250Mi # 请求内存使用量为 250MiMebibytes在这个配置中auth 容器请求了 250 毫核的 CPU 和 250Mi 的内存同时设置了 2 个单位的 CPU 和 1Gi 内存的限制。这意味着 Kubernetes 会确保 auth 容器至少有 250 毫核的 CPU 和 250Mi 的内存可用但如果资源充足它可以使用更多但不会超过 2 个单位的 CPU 和 1Gi 的内存。
通过这种方式可以为 Kubernetes 集群中的 Pod 设置合理的资源请求和限制以确保应用程序的性能和稳定性同时优化资源的使用。
命名空间资源限制
在 Kubernetes 中使用 ResourceQuota 和 LimitRange 资源类型来对命名空间级别的资源使用进行限制和管理
ResourceQuota
ResourceQuota 允许管理员限制命名空间中可以使用的计算资源和配置对象的数量。这有助于防止意外的资源过度使用确保集群资源的公平分配。
计算资源配额:
apiVersion: v1
kind: ResourceQuota #使用 ResourceQuota 资源类型
metadata:name: compute-resourcesnamespace: spark-cluster #指定命令空间
spec:hard:pods: 20 #设置 Pod 数量最大值requests.cpu: 2requests.memory: 1Gilimits.cpu: 4limits.memory: 2Gi在提供的第一个示例中ResourceQuota 被命名为 compute-resources它限制了 spark-cluster 命名空间中的资源使用 pods最多允许 20 个 Pod。 requests.cpu 和 requests.memory所有 Pod 总和的 CPU 和内存请求量上限。 limits.cpu 和 limits.memory单个 Pod 能够使用的 CPU 和内存量上限。
配置对象数量配额限制:
apiVersion: v1
kind: ResourceQuota
metadata:name: object-countsnamespace: spark-cluster
spec:hard:configmaps: 10persistentvolumeclaims: 4 #设置 pvc 数量最大值replicationcontrollers: 20 #设置 rc 数量最大值secrets: 10services: 10services.loadbalancers: 2第二个示例中的 ResourceQuota 被命名为 object-counts它限制了 spark-cluster 命名空间中的配置对象数量 configmaps、persistentvolumeclaims、replicationcontrollers、secrets、services这些项限制了各种类型配置对象的数量。 services.loadbalancers特别限制了使用负载均衡器类型的服务数量。
LimitRange 如果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、PVCLimitRange 示例中mem-limit-range 为 test 命名空间中的所有容器设置了默认的内存和 CPU 限制 default设置了默认的资源限制值。 defaultRequest设置了默认的资源请求值。 type指定了这些限制适用于的类型可以是 Container、Pod 或 PersistentVolumeClaim (PVC)。
通过这些资源限制Kubernetes 管理员可以精细地控制集群资源的使用避免资源浪费并确保集群的稳定性和效率。这些限制对于多租户环境或需要严格资源管理的场景尤为重要。
