如何为Kubernetes配置Pod水平自动扩展

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
简介: 干货教程!教你如何在K8S上实现根据CPU等实际使用量与用户的期望值进行比对,实现部署的自动扩展和缩减! 介 绍 Kubernetes有一个强大的功能,它能在运行的服务上进行编码并配置弹性伸缩。如果没有弹性伸缩功能,就很难适应部署的扩展和满足SLAs。

干货教程!教你如何在K8S上实现根据CPU等实际使用量与用户的期望值进行比对,实现部署的自动扩展和缩减! 


介 绍

Kubernetes有一个强大的功能,它能在运行的服务上进行编码并配置弹性伸缩。如果没有弹性伸缩功能,就很难适应部署的扩展和满足SLAs。这一功能称为Horizontal Pod Autoscaler (HPA)。

为什么使用HPA

使用HPA,您可以根据资源的使用情况或者自定义的指标,实现部署的自动扩展和缩减,让部署的规模接近于实际服务的负载。

HPA可以为您的服务带来两个直接的帮助:

  1. 在需要计算和内存资源时提供资源,在不需要时释放它们

  2. 按需增加/降低性能以实现SLA

HPA工作原理

HPA会根据监测到的CPU/内存利用率(资源指标),或基于第三方指标应用程序(如Prometheus、Datadog等)提供的自定义指标,自动调整副本控制器、部署或者副本集合的pods数量(定义最小和最大pods数)。HPA是一种控制回路,它的周期由Kubernetes的controller manager –horizontal-pod-autoscaler-sync-period标志控制(默认值是30s)。

HPA定义

HPA是Kubernetes中弹性伸缩API组下的一个API资源。当前稳定的版本是autoscaling/v1,它只提供了对CPU自动缩放的支持。如果您想额外获得对内存和自定义指标的支持,可以使用Beta版本autoscaling/v2beta1。

您可以在HPA API对象中看到更多信息:https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object

在一般情况下HPA是由kubectl来提供支持的。可以使用kubectl进行创建、管理和删除:

创建HPA:

  • 带有manifest: kubectl create -f <HPA_MANIFEST>

  • 没有manifest(只支持CPU):kubectl autoscale deployment hello-world –min=2 --man=5 –-cpu-percent=50

获取hpa信息:

  • 基本信息: kubectl get hpa hello-world

  • 细节描述: kubectl describe hpa hello-world

删除hpa:

  • kubectl delete hpa hello-world

下面是一个HPA manifest定义的例子:

这里使用了autoscaling/v2beta1版本,用到了cpu和内存指标

  • 控制hello-world项目部署的自动缩放

  • 定义了副本的最小值1

  • 定义了副本的最大值10

  • 当满足时调整大小:

    CPU使用率超过50%

    内存使用超过100Mi

安 装

在HPA可以在Kubernetes集群上使用之前,有一些元素需要在系统中安装和配置。

需 求

检查确定Kubernetes集群服务正在运行并且至少包含了这些标志:

  • kube-api: requestheader-client-ca-file

  • kubelet: read-only-port 在端口10255

  • kube-controller: 可选,只在需要和默认值不同时使用

  • horizontal-pod-autoscaler-downscale-delay:”5m0s”

  • horizontal-pod-autoscaler-upscale-delay:”3m0s”

  • horizontal-pod-autoscaler-sync-period: “30s”

对于RKE,Kubernetes集群定义,请确定您已经在服务部分添加了这些行。如果要在Rancher v2.0.X UI中执行此操作,请打开”Cluster options”- “Edit as YAML”并添加下面的定义:

要部署指标服务,您的Kubernetes集群必须要正确配置和部署。

注意:在部署和测试示例时,本文使用的是Rancher v2.0.6以及k8s v1.10.1集群

资源指标

如果HPA想要使用资源指标,那么就需要用到metrics-server包了,它在Kubernetes集群中的kube-system命名空间里。

按照下面的步骤实现:

  1. 配置kubectl连接到正确的Kubernetes集群

  2. 克隆metrics-server的Github仓库:git clone https://github.com/kubernetes-incubator/metrics-server

  3. 安装metrics-server包(假设Kubernetes升级到了1.8):kubectl create -f metrics-server/deply/1.8+/

  4. 检查metrics-server是否运行正常。在命名空间kube-system可以检查服务pod以及日志

  1. 检查是否可以从kubectl访问指标API:如果您要直接访问Kubernetes集群,请使用kubectl config的服务器URL,比如‘https://:6443’

如果您想通过Rancher访问Kubernetes集群,那么kubectl config的服务器URL就要像:https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>,即你还要在原本的

API路径后面加上/k8s/clusters/<CLUSTER_ID>

自定义指标(Prometheus)

自定义指标作为一种资源,可以由许多第三方应用程序提供。我们准备在演示中使用Prometheus。假设Prometheus已经部署在您的Kubernetes集群中了,它可以从pods、节点、命名空间等等地方获得正确的指标,我们将使用Prometheus url,http://prometheus.mycompany.io,它公开于端口80。

Prometheus可以在Rancher v2.0目录中部署。如果在Kubernetes集群上没有运行,那么就在Rancher目录中部署它。

如果HPA想要使用Prometheus中的自定义指标,那么Kubernetes集群上的kube-system命名空间则需要用到k8s-prometheus-adapter。为了方便k8s-prometheus-adapter的安装,我们将使用banzai-charts提供的Helm chart。

通过下面的步骤可以使用这一chart:

  1. 在k8s集群上初始化helm
  1. 从Github仓库克隆banzai-charts:
  1. 安装prometheus-adapter,指定具体的Prometheus URL和端口
  1. 检查prometheus-adapter是否运行正常。检查服务pod和日志是在kube-system命名空间下
  1. 检查指标API是否可以从kubectl进行访问:直接访问Kubernetes集群,那么kubectl config的服务器URL就比如https://<K8s_URL>:6443

如果是从Rancher进行访问,那么kubectl config的服务器URL就是https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>,需要加上后缀/k8s/clusters/<CLUSTER_ID>

ClusterRole和ClusterRoleBinding

默认情况下,HPA将尝试通过用户的system:anonymous读取(系统的和自定义的)指标。用户需要定义view-resource-metrics以及view-custom-metrics,而ClusterRole和ClusterRoleBinding将它们分配给system:anonymous来打开对指标的读取访问。

要实现这一点,需要下面的步骤:

  1. 配置kubectl正确连接到k8s集群

  2. 复制ClusterRole和ClusterRoleBinding文件:

在Kubernetes集群上创建它们(如果你想使用自定义指标的话):

服务部署

为了让HPA正常工作,服务部署应该要有容器的资源请求定义。

我们用一个hello-world的例子来测试一下HPA是否正常工作。

我们根据下面步骤进行,第一步,正确配置kubectl连接到k8s集群,第二步,复制hello-world的部署文件。

  1. 在k8s集群上部署它
  1. 为资源或者自定义指标复制HPA

  2. 资源指标:

``` apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: hello-world namespace: default spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: hello-world minReplicas: 1 maxReplicas: 10 metrics:

  • type: Resource resource:name: cpu targetAverageUtilization: 50

  • type: Resource resource: name: memory targetAverageValue: 1000Mi

  • 自定义指标(和资源指标一样,不过需要添加自定义的cpu_system指标)

  1. 获得HPA信息和描述,并且检查资源指标是否已经显示出来:

资源指标:

自定义指标:

  1. 给我们的服务产生负载,进行弹性伸缩的测试。这里可以使用各种各样的工具(产生负载),不过这里我们使用https://github.com/rakyll/hey 向hello-world服务发出http请求,并观察弹性伸缩是否正常工作

  2. 观察自动的扩缩容

  • 资源指标:

  • 当cpu利用率达到目标比例时,自动扩展到2个pods

当cpu使用率达到目标值horizontal-pod-autoscaler-upscale-delay默认超过3分钟时,扩展到3个pods:

当cpu使用率降到目标值horizontal-pod-autoscaler-downscale-delay默认超过5分钟时,缩小到1个pods:

自定义指标:

  • 当cpu利用率达到目标时扩展到2个pods:

当cpu_system利用率限制达到目标值,扩展到3个pods:

当cpu利用率限制达到目标值horizontal-pod-autoscaler-upscale-delay超过3分钟(默认),扩展到4个pods:

当所有的指标都低于目标值horizontal-pod-autoscaler-downscale-delay 超过5分钟,自动缩小到1个pods:

总 结

我们看到了如何在Rancher上使用Kubernetes HPA来进行部署的弹性扩缩容。这是一个非常出色好用的功能,可以让部署的规模适应于实际的服务负载并且实现服务SLA。

我们还看到,如何在kube-controller上对horizontal-pod-autoscaler-downscale-delay (默认5分钟)和 horizontal-pod-autoscaler-upscale-delay (默认3分钟) 进行参数化,调整扩缩容的反应。

对于我们的自定义指标,我们在例子cpu_system中进行了展示,不过我们还可以使用所有导出给Prometheus的指标,并了解当前服务的性能,比如http_request_number、http_response_time等等。

为了让之后HPA更容易使用,我们现在正努力将metric-server作为插件集成到RKE集群部署中。它现在已经包含在RKE v0.1.9-rc2中进行测试,目前还尚未得到官方的支持。它会在RKE v0.1.9版本中得到支持。

本文转移开源中国-如何为Kubernetes配置Pod水平自动扩展

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
7天前
|
弹性计算 调度 数据中心
阿里云 ACK One 注册集群云上弹性:扩展业务新利器
随着企业数字化转型深入,传统IDC数据中心因物理容量限制,难以实现动态扩容,缺乏弹性能力。阿里云ACK One注册集群凭借其高度灵活性和丰富资源选择,成为解决此问题的最佳方案。通过与阿里云资源的整合,ACK One不仅实现了计算资源的按需扩展,提高了资源利用率,还通过按需付费模式降低了成本,使企业能够更高效地应对业务增长和高峰需求。
|
1月前
|
存储 Kubernetes Docker
【赵渝强老师】Kubernetes中Pod的基础容器
Pod 是 Kubernetes 中的基本单位,代表集群上运行的一个进程。它由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。基础容器负责维护 Pod 的网络空间,对用户透明。文中附有图片和视频讲解,详细介绍了 Pod 的组成结构及其在网络配置中的作用。
【赵渝强老师】Kubernetes中Pod的基础容器
|
23天前
|
Prometheus Kubernetes 监控
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
深入探索Kubernetes中的Pod自动扩展(Horizontal Pod Autoscaler, HPA)
|
1月前
|
运维 Kubernetes Shell
【赵渝强老师】K8s中Pod的临时容器
Pod 是 Kubernetes 中的基本调度单位,由一个或多个容器组成,包括业务容器、基础容器、初始化容器和临时容器。临时容器用于故障排查和性能诊断,不适用于构建应用程序。当 Pod 中的容器异常退出或容器镜像不包含调试工具时,临时容器非常有用。文中通过示例展示了如何使用 `kubectl debug` 命令创建临时容器进行调试。
|
1月前
|
Kubernetes 调度 容器
【赵渝强老师】K8s中Pod中的业务容器
Pod 是 Kubernetes 中的基本调度单元,由一个或多个容器组成。除了业务容器,Pod 还包括基础容器、初始化容器和临时容器。本文通过示例介绍如何创建包含业务容器的 Pod,并提供了一个视频讲解。示例中创建了一个名为 &quot;busybox-container&quot; 的业务容器,并使用 `kubectl create -f firstpod.yaml` 命令部署 Pod。
|
7天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
28天前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
61 1
|
2月前
|
JSON Kubernetes 容灾
ACK One应用分发上线:高效管理多集群应用
ACK One应用分发上线,主要介绍了新能力的使用场景
|
2月前
|
Kubernetes 持续交付 开发工具
ACK One GitOps:ApplicationSet UI简化多集群GitOps应用管理
ACK One GitOps新发布了多集群应用控制台,支持管理Argo CD ApplicationSet,提升大规模应用和集群的多集群GitOps应用分发管理体验。
|
2月前
|
Kubernetes Ubuntu Linux
Centos7 搭建 kubernetes集群
本文介绍了如何搭建一个三节点的Kubernetes集群,包括一个主节点和两个工作节点。各节点运行CentOS 7系统,最低配置为2核CPU、2GB内存和15GB硬盘。详细步骤包括环境配置、安装Docker、关闭防火墙和SELinux、禁用交换分区、安装kubeadm、kubelet、kubectl,以及初始化Kubernetes集群和安装网络插件Calico或Flannel。
199 4