kubernetes中文手册
  • 前言
    • 序言
  • 云原生
    • 云原生(Cloud Native)的定义
    • 云原生的设计哲学
    • Kubernetes 的诞生
    • Kubernetes 与云原生应用概览
    • 云原生应用之路 —— 从 Kubernetes 到云原生
    • 定义云原生应用
      • OAM
        • Workload
        • Component
        • Trait
        • Application Scope
        • Application Configuration
      • Crossplane
    • 云原生编程语言
      • 云原生编程语言 Ballerina
      • 云原生编程语言 Pulumi
    • 云原生的未来
  • 快速入门
    • 云原生新手入门指南
    • Play with Kubernetes
    • 快速部署一个云原生本地实验环境
    • 使用 Rancher 在阿里云上部署 Kubenretes 集群
  • 概念与原理
    • Kubernetes 架构
      • 设计理念
      • Etcd 解析
      • 开放接口
        • CRI - Container Runtime Interface(容器运行时接口)
        • CNI - Container Network Interface(容器网络接口)
        • CSI - Container Storage Interface(容器存储接口)
      • 资源对象与基本概念解析
    • Pod 状态与生命周期管理
      • Pod 概览
      • Pod 解析
      • Init 容器
      • Pause 容器
      • Pod 安全策略
      • Pod 的生命周期
      • Pod Hook
      • Pod Preset
      • Pod 中断与 PDB(Pod 中断预算)
    • 集群资源管理
      • Node
      • Namespace
      • Label
      • Annotation
      • Taint 和 Toleration(污点和容忍)
      • 垃圾收集
    • 控制器
      • Deployment
      • StatefulSet
      • DaemonSet
      • ReplicationController 和 ReplicaSet
      • Job
      • CronJob
      • Horizontal Pod Autoscaling
        • 自定义指标 HPA
      • 准入控制器(Admission Controller)
    • 服务发现与路由
      • Service
      • 拓扑感知路由
      • Ingress
        • Traefik Ingress Controller
      • Kubernetes Service API
        • Service API 简介
    • 身份与权限控制
      • ServiceAccount
      • 基于角色的访问控制(RBAC)
      • NetworkPolicy
    • 网络
      • Kubernetes 中的网络解析 —— 以 flannel 为例
      • Kubernetes 中的网络解析 —— 以 calico 为例
      • 具备 API 感知的网络和安全性管理开源软件 Cilium
        • Cilium 架构设计与概念解析
    • 存储
      • Secret
      • ConfigMap
        • ConfigMap 的热更新
      • Volume
      • 持久化卷(Persistent Volume)
      • Storage Class
      • 本地持久化存储
    • 集群扩展
      • 使用自定义资源扩展 API
      • 使用 CRD 扩展 Kubernetes API
      • Aggregated API Server
      • APIService
      • Service Catalog
    • 多集群管理
      • 多集群服务 API(Multi-Cluster Services API)
      • 集群联邦(Cluster Federation)
    • 资源调度
      • 服务质量等级(QoS)
  • 用户指南
    • 用户指南概览
    • 资源对象配置
      • 配置 Pod 的 liveness 和 readiness 探针
      • 配置 Pod 的 Service Account
      • Secret 配置
      • 管理 namespace 中的资源配额
    • 命令使用
      • Docker 用户过渡到 kubectl 命令行指南
      • kubectl 命令概览
      • kubectl 命令技巧大全
      • 使用 etcdctl 访问 Kubernetes 数据
    • 集群安全性管理
      • 管理集群中的 TLS
      • kubelet 的认证授权
      • TLS Bootstrap
      • 创建用户认证授权的 kubeconfig 文件
      • IP 伪装代理
      • 使用 kubeconfig 或 token 进行用户身份认证
      • Kubernetes 中的用户与身份认证授权
      • Kubernetes 集群安全性配置最佳实践
    • 访问 Kubernetes 集群
      • 访问集群
      • 使用 kubeconfig 文件配置跨集群认证
      • 通过端口转发访问集群中的应用程序
      • 使用 service 访问群集中的应用程序
      • 从外部访问 Kubernetes 中的 Pod
      • Cabin - Kubernetes 手机客户端
      • Lens - Kubernetes IDE/桌面客户端
      • Kubernator - 更底层的 Kubernetes UI
    • 在 Kubernetes 中开发部署应用
      • 适用于 Kubernetes 的应用开发部署流程
      • 迁移传统应用到 Kubernetes 中 —— 以 Hadoop YARN 为例
      • 使用 StatefulSet 部署用状态应用
  • 最佳实践
    • 最佳实践概览
    • 在 CentOS 上部署 Kubernetes 集群
      • 创建 TLS 证书和秘钥
      • 创建 kubeconfig 文件
      • 创建高可用 etcd 集群
      • 安装 kubectl 命令行工具
      • 部署 master 节点
      • 安装 flannel 网络插件
      • 部署 node 节点
      • 安装 kubedns 插件
      • 安装 dashboard 插件
      • 安装 heapster 插件
      • 安装 EFK 插件
    • 生产级的 Kubernetes 简化管理工具 kubeadm
      • 使用 kubeadm 在 Ubuntu Server 16.04 上快速构建测试集群
    • 服务发现与负载均衡
      • 安装 Traefik ingress
      • 分布式负载测试
      • 网络和集群性能测试
      • 边缘节点配置
      • 安装 Nginx ingress
      • 安装配置 DNS
        • 安装配置 Kube-dns
        • 安装配置 CoreDNS
    • 运维管理
      • Master 节点高可用
      • 服务滚动升级
      • 应用日志收集
      • 配置最佳实践
      • 集群及应用监控
      • 数据持久化问题
      • 管理容器的计算资源
    • 存储管理
      • GlusterFS
        • 使用 GlusterFS 做持久化存储
        • 使用 Heketi 作为 Kubernetes 的持久存储 GlusterFS 的 external provisioner
        • 在 OpenShift 中使用 GlusterFS 做持久化存储
      • GlusterD-2.0
      • Ceph
        • 用 Helm 托管安装 Ceph 集群并提供后端存储
        • 使用 Ceph 做持久化存储
        • 使用 rbd-provisioner 提供 rbd 持久化存储
      • OpenEBS
        • 使用 OpenEBS 做持久化存储
      • Rook
      • NFS
        • 利用 NFS 动态提供 Kubernetes 后端存储卷
    • 集群与应用监控
      • Heapster
        • 使用 Heapster 获取集群和对象的 metric 数据
      • Prometheus
        • 使用 Prometheus 监控 Kubernetes 集群
        • Prometheus 查询语言 PromQL 使用说明
      • 使用 Vistio 监控 Istio 服务网格中的流量
    • 分布式追踪
      • OpenTracing
    • 服务编排管理
      • 使用 Helm 管理 Kubernetes 应用
      • 构建私有 Chart 仓库
    • 持续集成与发布
      • 使用 Jenkins 进行持续集成与发布
      • 使用 Drone 进行持续集成与发布
    • 更新与升级
      • 手动升级 Kubernetes 集群
      • 升级 dashboard
    • 扩展控制器
      • OpenKruise
        • 原地升级
    • 安全策略
      • 开放策略代理(OPA)
      • 云原生安全
  • 服务网格
    • 服务网格(Service Mesh)
    • 企业级服务网格架构
      • 服务网格基础
      • 服务网格技术对比
      • 服务网格对比 API 网关
      • 采纳和演进
      • 定制和集成
      • 总结
    • Istio
      • 使用 Istio 前需要考虑的问题
      • Istio 中 sidecar 的注入规范及示例
      • 如何参与 Istio 社区及注意事项
      • Istio 免费学习资源汇总
      • Sidecar 的注入与流量劫持
      • Envoy Sidecar 代理的路由转发
      • Istio 如何支持虚拟机
      • Istio 支持虚拟机的历史
    • Envoy
      • Envoy 的架构与基本术语
      • Envoy 作为前端代理
      • Envoy mesh 教程
  • 领域应用
    • 领域应用概览
    • 微服务架构
      • 微服务中的服务发现
      • 使用 Java 构建微服务并发布到 Kubernetes 平台
        • Spring Boot 快速开始指南
    • 大数据
      • Spark 与 Kubernetes
        • Spark standalone on Kubernetes
        • 运行支持 Kubernetes 原生调度的 Spark 程序
    • Serverless 架构
      • 理解 Serverless
      • FaaS(函数即服务)
        • OpenFaaS 快速入门指南
      • Knative
    • 边缘计算
    • 人工智能
    • 可观察性
  • 开发指南
    • 开发指南概览
    • SIG 和工作组
    • 开发环境搭建
      • 本地分布式开发环境搭建(使用 Vagrant 和 Virtualbox)
    • 单元测试和集成测试
    • client-go 示例
      • client-go 中的 informer 源码分析
    • Operator
      • operator-sdk
    • kubebuilder
      • 使用 kubebuilder 创建 operator 示例
    • 高级开发指南
    • 社区贡献
    • Minikube
  • 社区及生态
    • 云原生计算基金会(CNCF)
      • CNCF 章程
      • CNCF 特别兴趣小组(SIG)说明
      • 开源项目加入 CNCF Sandbox 的要求
      • CNCF 中的项目治理
      • CNCF Ambassador
    • 认证及培训
      • 认证 Kubernetes 服务提供商(KCSP)说明
      • 认证 Kubernetes 管理员(CKA)说明
  • 附录
    • 附录说明
    • Kubernetes 中的应用故障排查
    • Kubernetes 相关资讯和情报链接
    • Docker 最佳实践
    • Kubernetes 使用技巧
    • Kubernetes 相关问题记录
    • Kubernetes 及云原生年度总结及展望
      • Kubernetes 与云原生 2017 年年终总结及 2018 年展望
      • Kubernetes 与云原生 2018 年年终总结及 2019 年展望
    • CNCF 年度报告解读
      • CNCF 2018 年年度报告解读
      • CNCF 2020 年年度报告解读
由 GitBook 提供支持
在本页
  • HPA解析
  • Metrics支持
  • 使用kubectl管理
  • 什么是 Horizontal Pod Autoscaling?
  • Horizontal Pod Autoscaler 如何工作?
  • API Object
  • 在 kubectl 中支持 Horizontal Pod Autoscaling
  • 滚动更新期间的自动扩缩容
  • 支持多个 metric
  • 支持自定义 metric
  • 前提条件
  • 参考
  1. 概念与原理
  2. 控制器

Horizontal Pod Autoscaling

上一页CronJob下一页自定义指标 HPA

最后更新于3年前

应用的资源使用率通常都有高峰和低谷的时候,如何削峰填谷,提高集群的整体资源利用率,让service中的Pod个数自动调整呢?这就有赖于Horizontal Pod Autoscaling了,顾名思义,使Pod水平自动缩放。这个Object(跟Pod、Deployment一样都是API resource)也是最能体现kubernetes之于传统运维价值的地方,不再需要手动扩容了,终于实现自动化了,还可以自定义指标,没准未来还可以通过人工智能自动进化呢!

HPA属于Kubernetes中的autoscaling SIG(Special Interest Group),其下有两个feature:

Kubernetes自1.2版本引入HPA机制,到1.6版本之前一直是通过kubelet来获取监控指标来判断是否需要扩缩容,1.6版本之后必须通过API server、Heapseter或者kube-aggregator来获取监控指标。

对于1.6以前版本中开启自定义HPA请参考。

HPA解析

Horizontal Pod Autoscaling仅适用于Deployment和ReplicaSet,在v1版本中仅支持根据Pod的CPU利用率扩缩容,在v1alpha版本中,支持根据内存和用户自定义的metric扩缩容。

如果你不想看下面的文章可以直接看下面的示例图,组件交互、组件的配置、命令示例,都画在图上了。

Horizontal Pod Autoscaling由API server和controller共同实现。

Metrics支持

在不同版本的API中,HPA autoscale时可以根据以下指标来判断:

  • autoscaling/v1

    • CPU

  • autoscaling/v1alpha1

    • 内存

    • 自定义metrics

      • kubernetes1.6起支持自定义metrics,但是必须在kube-controller-manager中配置如下两项:

        • --horizontal-pod-autoscaler-use-rest-clients=true

    • 多种metrics组合

      • HPA会根据每个metric的值计算出scale的值,并将最大的那个值作为扩容的最终结果。

使用kubectl管理

Horizontal Pod Autoscaling作为API resource也可以像Pod、Deployment一样使用kubeclt命令管理,使用方法跟它们一样,资源名称为hpa。

kubectl create hpa
kubectl get hpa
kubectl describe hpa
kubectl delete hpa

有一点不同的是,可以直接使用kubectl autoscale直接通过命令行的方式创建Horizontal Pod Autoscaler。

用法如下:

kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS
[--cpu-percent=CPU] [flags] [options]

举个例子:

kubectl autoscale deployment foo --min=2 --max=5 --cpu-percent=80

为Deployment foo创建 一个autoscaler,当Pod的CPU利用率达到80%的时候,RC的replica数在2到5之间。

注意 :如果为ReplicaSet创建HPA的话,无法使用rolling update,但是对于Deployment来说是可以的,因为Deployment在执行rolling update的时候会自动创建新的ReplicationController。

什么是 Horizontal Pod Autoscaling?

利用 Horizontal Pod Autoscaling,kubernetes 能够根据监测到的 CPU 利用率(或者在 alpha 版本中支持的应用提供的 metric)自动的扩容 replication controller,deployment 和 replica set。

Horizontal Pod Autoscaler 作为 kubernetes API resource 和 controller 的实现。Resource 确定 controller 的行为。Controller 会根据监测到用户指定的目标的 CPU 利用率周期性得调整 replication controller 或 deployment 的 replica 数量。

Horizontal Pod Autoscaler 如何工作?

Horizontal Pod Autoscaler 由一个控制循环实现,循环周期由 controller manager 中的 --horizontal-pod-autoscaler-sync-period 标志指定(默认是 30 秒)。

在每个周期内,controller manager 会查询 HorizontalPodAutoscaler 中定义的 metric 的资源利用率。Controller manager 从 resource metric API(每个 pod 的 resource metric)或者自定义 metric API(所有的metric)中获取 metric。

  • 每个 Pod 的 resource metric(例如 CPU),controller 通过 resource metric API 获取 HorizontalPodAutoscaler 中定义的每个 Pod 中的 metric。然后,如果设置了目标利用率,controller 计算利用的值与每个 Pod 的容器里的 resource request 值的百分比。如果设置了目标原始值,将直接使用该原始 metric 值。然后 controller 计算所有目标 Pod 的利用率或原始值(取决于所指定的目标类型)的平均值,产生一个用于缩放所需 replica 数量的比率。 请注意,如果某些 Pod 的容器没有设置相关的 resource request ,则不会定义 Pod 的 CPU 利用率,并且 Aucoscaler 也不会对该 metric 采取任何操作。

  • 对于每个 Pod 自定义的 metric,controller 功能类似于每个 Pod 的 resource metric,只是它使用原始值而不是利用率值。

  • 对于 object metric,获取单个度量(描述有问题的对象),并与目标值进行比较,以产生如上所述的比率。

HorizontalPodAutoscaler 控制器可以以两种不同的方式获取 metric :直接的 Heapster 访问和 REST 客户端访问。

当使用直接的 Heapster 访问时,HorizontalPodAutoscaler 直接通过 API 服务器的服务代理子资源查询 Heapster。需要在集群上部署 Heapster 并在 kube-system namespace 中运行。

Autoscaler 访问相应的 replication controller,deployment 或 replica set 来缩放子资源。

Scale 是一个允许您动态设置副本数并检查其当前状态的接口。

API Object

Horizontal Pod Autoscaler 是 kubernetes 的 autoscaling API 组中的 API 资源。当前的稳定版本中,只支持 CPU 自动扩缩容,可以在autoscaling/v1 API 版本中找到。

在 alpha 版本中支持根据内存和自定义 metric 扩缩容,可以在autoscaling/v2alpha1 中找到。autoscaling/v2alpha1 中引入的新字段在autoscaling/v1 中是做为 annotation 而保存的。

在 kubectl 中支持 Horizontal Pod Autoscaling

Horizontal Pod Autoscaler 和其他的所有 API 资源一样,通过 kubectl 以标准的方式支持。

我们可以使用kubectl create命令创建一个新的 autoscaler。

我们可以使用kubectl get hpa列出所有的 autoscaler,使用kubectl describe hpa获取其详细信息。

最后我们可以使用kubectl delete hpa删除 autoscaler。

另外,可以使用kubectl autoscale命令,很轻易的就可以创建一个 Horizontal Pod Autoscaler。

例如,执行kubectl autoscale rc foo —min=2 —max=5 —cpu-percent=80命令将为 replication controller foo 创建一个 autoscaler,目标的 CPU 利用率是80%,replica 的数量介于 2 和 5 之间。

滚动更新期间的自动扩缩容

目前在Kubernetes中,可以通过直接管理 replication controller 或使用 deployment 对象来执行 滚动更新,该 deployment 对象为您管理基础 replication controller。

Horizontal Pod Autoscaler 仅支持后一种方法:Horizontal Pod Autoscaler 被绑定到 deployment 对象,它设置 deployment 对象的大小,deployment 负责设置底层 replication controller 的大小。

Horizontal Pod Autoscaler 不能使用直接操作 replication controller 进行滚动更新,即不能将 Horizontal Pod Autoscaler 绑定到 replication controller,并进行滚动更新(例如使用kubectl rolling-update)。

这不行的原因是,当滚动更新创建一个新的 replication controller 时,Horizontal Pod Autoscaler 将不会绑定到新的 replication controller 上。

支持多个 metric

Kubernetes 1.6 中增加了支持基于多个 metric 的扩缩容。您可以使用autoscaling/v2alpha1 API 版本来为 Horizontal Pod Autoscaler 指定多个 metric。然后 Horizontal Pod Autoscaler controller 将权衡每一个 metric,并根据该 metric 提议一个新的 scale。在所有提议里最大的那个 scale 将作为最终的 scale。

支持自定义 metric

注意: Kubernetes 1.2 根据特定于应用程序的 metric ,通过使用特殊注释的方式,增加了对缩放的 alpha 支持。

在 Kubernetes 1.6中删除了对这些注释的支持,有利于autoscaling/v2alpha1 API。 虽然旧的收集自定义 metric 的旧方法仍然可用,但是这些 metric 将不可供 Horizontal Pod Autoscaler 使用,并且用于指定要缩放的自定义 metric 的以前的注释也不在受 Horizontal Pod Autoscaler 认可。

Kubernetes 1.6增加了在 Horizontal Pod Autoscale r中使用自定义 metric 的支持。

您可以为autoscaling/v2alpha1 API 中使用的 Horizontal Pod Autoscaler 添加自定义 metric 。

Kubernetes 然后查询新的自定义 metric API 来获取相应自定义 metric 的值。

前提条件

为了在 Horizontal Pod Autoscaler 中使用自定义 metric,您必须在您集群的 controller manager 中将 --horizontal-pod-autoscaler-use-rest-clients 标志设置为 true。然后,您必须通过将 controller manager 的目标 API server 设置为 API server aggregator(使用--apiserver标志),配置您的 controller manager 通过 API server aggregator 与API server 通信。 Resource metric API和自定义 metric API 也必须向 API server aggregator 注册,并且必须由集群上运行的 API server 提供。

参考

  • [HPA说明 - kubernetes.io(https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/)

--api-server指向,也可以使用heapster来实现,通过在启动heapster的时候指定--api-server=true。查看

您可以使用 Heapster 实现 resource metric API,方法是将 --api-server 标志设置为 true 并运行 Heapster。 单独的组件必须提供自定义 metric API(有关自定义metric API的更多信息,可从 获得)。

kube-aggregator
kubernetes metrics
k8s.io/metrics repository
HPA详解 - kubernetes.io
自定义metrics开发 - github.com
Arbitrary/Custom Metrics in the Horizontal Pod Autoscaler#117
Monitoring Pipeline Metrics HPA API #118
Kubernetes autoscaling based on custom metrics without using a host port
horizontal-pod-autoscaler