IT博客汇
  • 首页
  • 精华
  • 技术
  • 设计
  • 资讯
  • 扯淡
  • 权利声明
  • 登录 注册

    k8s_安装14_vpa_hpa

    C1G发表于 2024-05-17 10:33:25
    love 0

    Vertical Pod Autoscaler ( VPA )

    Vertical Pod Autoscaler ( VPA )会自动调整 Pod 的 CPU 和内存属性,被称为纵向扩展。
    VPA可以给出服务运行所适合的CPU和内存配置,省去估计服务占用资源的时间,更合理的使用资源。
    https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/
    https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

    VPA 与 HPA
    从根本上来说,VPA 和 HPA 之间的区别在于它们的扩展方式。HPA 通过添加或删除pod进行扩展,从而水平扩展容量。然而,VPA 通过增加或减少现有 Pod 容器内的 CPU 和内存资源来进行扩展,从而垂直扩展容量

    VPA 的组成部分
    VPA 部署具有三个主要组件:VPA Recommender、VPA Updater和VPA Admission Controller。让我们看一下每个组件的作用。VPA Recommender:

    监控资源利用率并计算目标值。
    查看指标历史记录、OOM 事件和 VPA 部署规范并建议公平请求。根据定义的限制请求比例提高/降低限制。
    VPA 更新程序:

    驱逐那些需要新资源限制的 Pod。
    如果定义了“updateMode: Auto”,则实现推荐器建议的任何内容。
    VPA 准入控制器:

    每当 VPA 更新程序逐出并重新启动 Pod 时,都会在新 Pod 启动之前更改 CPU 和内存设置(使用 Webhook)。
    当 Vertical Pod Autoscaler 设置为“Auto”的 updateMode 时,如果需要更改 Pod 的资源请求,则驱逐 Pod。由于 Kubernetes 的设计,修改正在运行的 pod 的资源请求的唯一方法是重新创建 pod。

    流程说明

    vpa 连接检查 pod 在运行过程中占用的资源,默认间隔为10s一次
    当发现 pod 资源占用到达阈值时,vpa会尝试更改分配的内存或cpu
    vpa尝试更新部署组件中的pod资源定义
    pod重启,新资源将应用于创建出来的实例

    使用注意

    同一个 deployment,不能同时使用 hpa 和 vpa。 但是,您可以在自定义和外部指标上使用VPA和HPA。
    vpa 更新资源会导致 pod 重建、重启、甚至重新调度
    Auto模式中的VPA 只能用于在控制器(例如部署)下运行的pod,后者负责重新启动已删除的pod。 在Auto模式下,没有在任何控制器下运行的pod的模式下使用VPA 将导致删除该pod并且不会重新创建该pod。
    vpa 使用 admission webhook ,需要确保与其他 webhook 不冲突
    vpa的性能没有在大型集群中测试过
    vap建议值可能超过实际资源上限(例如节点大小,可用大小,可用配额),从而导致pod处于pending无法被调度
    多个 vpa 同时配置同一个pod会造成未定义的行为
    vpa不支持扩展控制器

    已知的限制

    每当 VPA 更新 Pod 资源时,都会重新创建 Pod,这会导致重新创建所有正在运行的容器。Pod 可以在不同的节点上重新创建。
    VPA 无法保证它驱逐或删除以应用建议(在Auto和Recreate模式下配置时)的 pod 将成功重新创建。通过将 VPA 与Cluster Autoscaler结合使用可以部分解决这个问题。
    VPA 不会更新不在控制器下运行的 Pod 的资源。
    目前,Vertical Pod Autoscaler不应与CPU 或内存上的Horizontal Pod Autoscaler (HPA)一起使用。但是,您可以在自定义和外部指标上将 VPA 与 HPA结合使用。
    VPA 准入控制器是一个准入 Webhook。如果您将其他准入 Webhook 添加到集群中,则分析它们如何交互以及它们是否可能相互冲突非常重要。准入控制器的顺序由 API 服务器上的标志定义。
    VPA 会对大多数内存不足事件做出反应,但并非在所有情况下都会做出反应。
    VPA 性能尚未在大型集群中进行测试。
    VPA 建议可能会超出可用资源(例如节点大小、可用大小、可用配额)并导致Pod 处于挂起状态。通过将 VPA 与Cluster Autoscaler结合使用可以部分解决这个问题。
    与同一 Pod 匹配的多个 VPA 资源具有未定义的行为。
    从1.27 版本动态调整容器CPU和内存资源限制,无需重启应用程序

    安装

    git clone https://github.com/kubernetes/autoscaler.git
    cd autoscaler/vertical-pod-autoscaler/deploy
    sed -i 's/Always/IfNotPresent/g'  recommender-deployment.yaml
    sed -i 's/Always/IfNotPresent/g'  admission-controller-deployment.yaml
    sed -i 's/Always/IfNotPresent/g'  updater-deployment.yaml

    准备image

    cat *.yaml|grep image:|sed -e 's/.*image: //'|sort|uniq   
    registry.k8s.io/autoscaling/vpa-admission-controller:1.0.0
    registry.k8s.io/autoscaling/vpa-recommender:1.0.0
    registry.k8s.io/autoscaling/vpa-updater:1.0.0
    
    使用k8s.mirror.nju.edu.cn替换registry.k8s.io
    docker pull k8s.mirror.nju.edu.cn/autoscaling/vpa-admission-controller:1.0.0
    docker pull k8s.mirror.nju.edu.cn/autoscaling/vpa-recommender:1.0.0
    docker pull k8s.mirror.nju.edu.cn/autoscaling/vpa-updater:1.0.0
    
    docker tag k8s.mirror.nju.edu.cn/autoscaling/vpa-admission-controller:1.0.0 repo.k8s.local/registry.k8s.io/autoscaling/vpa-admission-controller:1.0.0
    docker tag k8s.mirror.nju.edu.cn/autoscaling/vpa-recommender:1.0.0 repo.k8s.local/registry.k8s.io/autoscaling/vpa-recommender:1.0.0
    docker tag k8s.mirror.nju.edu.cn/autoscaling/vpa-updater:1.0.0 repo.k8s.local/registry.k8s.io/autoscaling/vpa-updater:1.0.0
    
    docker push repo.k8s.local/registry.k8s.io/autoscaling/vpa-admission-controller:1.0.0
    docker push repo.k8s.local/registry.k8s.io/autoscaling/vpa-recommender:1.0.0
    docker push repo.k8s.local/registry.k8s.io/autoscaling/vpa-updater:1.0.0

    替换yaml中image地址为私仓

    #测试
    sed -n "/image:/{s/image: registry.k8s.io/image: repo.k8s.local\/registry.k8s.io/p}" *.yaml
    
    #替换
    sed -i "/image:/{s/image: registry.k8s.io/image: repo.k8s.local\/registry.k8s.io/}" *.yaml
    
    #重新验证
    cat *.yaml|grep image:|sed -e 's/.*image: //'|sort|uniq   

    安装

    cd autoscaler/vertical-pod-autoscaler/hack
    安装脚本安装之前保证你的K8S集群的metrics-server已安装,并且openssl升级到1.1.1或更高版本
    ./vpa-up.sh

    deployment.apps/vpa-recommender created
    Generating certs for the VPA Admission Controller in /tmp/vpa-certs.
    Generating RSA private key, 2048 bit long modulus
    ..................................+++
    .....................................................+++
    e is 65537 (0x10001)
    unknown option -addext
    req [options] <infile >outfile
    where options  are
     -inform arg    input format - DER or PEM
     -outform arg   output format - DER or PEM
     -in arg        input file
     -out arg       output file
     -text          text form of request
     -pubkey        output public key
     -noout         do not output REQ
     -verify        verify signature on REQ
     -modulus       RSA modulus
     -nodes         don't encrypt the output key
     -engine e      use engine e, possibly a hardware device
     -subject       output the request's subject
     -passin        private key password source
     -key file      use the private key contained in file
     -keyform arg   key file format
     -keyout arg    file to send the key to
     -rand file:file:...
                    load the file (or the files in the directory) into
                    the random number generator
     -newkey rsa:bits generate a new RSA key of 'bits' in size
     -newkey dsa:file generate a new DSA key, parameters taken from CA in 'file'
     -newkey ec:file generate a new EC key, parameters taken from CA in 'file'
     -[digest]      Digest to sign with (see openssl dgst -h for list)
     -config file   request template file.
     -subj arg      set or modify request subject
     -multivalue-rdn enable support for multivalued RDNs
     -new           new request.
     -batch         do not ask anything during request generation
     -x509          output a x509 structure instead of a cert. req.
     -days          number of days a certificate generated by -x509 is valid for.
     -set_serial    serial number to use for a certificate generated by -x509.
     -newhdr        output "NEW" in the header lines
     -asn1-kludge   Output the 'request' in a format that is wrong but some CA's
                    have been reported as requiring
     -extensions .. specify certificate extension section (override value in config file)
     -reqexts ..    specify request extension section (override value in config file)
     -utf8          input characters are UTF8 (default ASCII)
     -nameopt arg    - various certificate name options
     -reqopt arg    - various request text options
    
    ERROR: Failed to create CA certificate for self-signing. If the error is "unknown option -addext", update your openssl version or deploy VPA from the vpa-release-0.8 branch.
    deployment.apps/vpa-admission-controller created

    openssl 没升级出错

    customresourcedefinition.apiextensions.k8s.io/verticalpodautoscalercheckpoints.autoscaling.k8s.io created
    customresourcedefinition.apiextensions.k8s.io/verticalpodautoscalers.autoscaling.k8s.io created
    clusterrole.rbac.authorization.k8s.io/system:metrics-reader created
    clusterrole.rbac.authorization.k8s.io/system:vpa-actor created
    clusterrole.rbac.authorization.k8s.io/system:vpa-status-actor created
    clusterrole.rbac.authorization.k8s.io/system:vpa-checkpoint-actor created
    clusterrole.rbac.authorization.k8s.io/system:evictioner created
    clusterrolebinding.rbac.authorization.k8s.io/system:metrics-reader created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-actor created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-status-actor created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-checkpoint-actor created
    clusterrole.rbac.authorization.k8s.io/system:vpa-target-reader created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-target-reader-binding created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-evictioner-binding created
    serviceaccount/vpa-admission-controller created
    serviceaccount/vpa-recommender created
    serviceaccount/vpa-updater created
    clusterrole.rbac.authorization.k8s.io/system:vpa-admission-controller created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-admission-controller created
    clusterrole.rbac.authorization.k8s.io/system:vpa-status-reader created
    clusterrolebinding.rbac.authorization.k8s.io/system:vpa-status-reader-binding created
    deployment.apps/vpa-updater created
    deployment.apps/vpa-recommender created
    Generating certs for the VPA Admission Controller in /tmp/vpa-certs.
    Generating RSA private key, 2048 bit long modulus (2 primes)
    .........+++++
    ...........................................................................................................................................+++++
    e is 65537 (0x010001)
    Generating RSA private key, 2048 bit long modulus (2 primes)
    ................................................+++++
    ...................+++++
    e is 65537 (0x010001)
    Signature ok
    subject=CN = vpa-webhook.kube-system.svc
    Getting CA Private Key
    Uploading certs to the cluster.
    secret/vpa-tls-certs created
    Deleting /tmp/vpa-certs.
    deployment.apps/vpa-admission-controller created
    service/vpa-webhook created

    kubectl -n kube-system get pods|grep vpa

    kubectl get po -n kube-system

    vpa-admission-controller-55f6c45765-k7w5c    1/1     Running   0               112s
    vpa-recommender-7d974b6444-dhwrk             1/1     Running   0               114s
    vpa-updater-5ff957f8cf-q2hnw                 1/1     Running   0               114s

    kubectl get customresourcedefinition|grep verticalpodautoscalers

    verticalpodautoscalers.autoscaling.k8s.io             2024-01-02T09:48:59Z

    删除

    请注意,如果您停止在群集中运行VPA,则VPA已修改的pod的资源请求将不会更改,但任何新pod将获取控制器中定义的资源(即部署或复制),而不是根据先前的建议由VPA。
    要停止在群集中使用Vertical Pod Autoscaling:
    如果在GKE上运行,请清除在先决条件中创建的角色绑定:

    kubectl delete clusterrolebinding myname-cluster-admin-binding

    删除VPA组件:

    ./hack/vpa-down.sh

    VPA实例

    ​ 安装后,系统已准备好为您的 pod 推荐和设置资源请求。为了使用它,您需要为要自动计算资源需求的每个控制器插入一个Vertical Pod Autoscaler资源。这将是最常见的Deployment。VPA有三种运行模式

    "Auto":VPA 在创建 pod 时分配资源请求,并使用首选更新机制在现有 pod 上更新它们。目前这相当于"Recreate"(见下文)。一旦 pod 请求的免重启(“就地”)更新可用,它可能会被该"Auto"模式用作首选的更新机制。注意: VPA 的此功能是实验性的,可能会导致您的应用程序停机,当目前运行的pod的资源达不到VPA的推荐值,就会执行pod驱逐,重新部署新的足够资源的服务
    "Recreate":VPA 在创建 Pod 时分配资源请求,并在现有 Pod 上更新它们,当请求的资源与新建议有很大差异时(尊重 Pod 中断预算,如果定义)。这种模式应该很少使用,只有当您需要确保在资源请求发生变化时重新启动 Pod 时。否则,更喜欢这种"Auto"模式,一旦它们可用,就可以利用重新启动免费更新。注意: VPA 的此功能是实验性的,可能会导致您的应用程序停机
    "Initial":VPA 仅在创建 pod 时分配资源请求,以后不会更改它们
    "Off":VPA 不会自动更改 Pod 的资源需求。这些建议是经过计算的,并且可以在 VPA 对象中进行检查。这种模式仅获取资源推荐值,但是不更新Pod。

    注意

    需要至少两个健康的 Pod 才能工作
    默认最小内存分配为250MiB
    无论指定了什么配置,VPA 都会分配250MiB的最小内存,虽然这个默认值可以在全局层面进行修改,但对于消耗较少内存的应用程序来说,是比较浪费资源的。
    不建议在生产中用自动模式“Auto”来运行 VPA,updateMode 模式设置为 "Off",仅获取资源推荐值。

    注意vpa版本为 autoscaling.k8s.io/v1

    kubectl api-resources |grep autoscaling

    horizontalpodautoscalers           hpa                autoscaling/v2                         true         HorizontalPodAutoscaler
    verticalpodautoscalercheckpoints   vpacheckpoint      autoscaling.k8s.io/v1                  true         VerticalPodAutoscalerCheckpoint
    verticalpodautoscalers             vpa                autoscaling.k8s.io/v1                  true         VerticalPodAutoscaler

    查看资源

    kubectl get vpa -n test -w
    kubectl top pod -n test

    创建死循环持续访问

    测试原有的openresty服务

    kubectl exec -it pod/test-pod-0 -n test -- /bin/sh  -c 'while true; do curl -k http://svc-openresty.test.svc:31080; done '

    apache ab压测

    压力不够,制作一个apache ab压测镜像

    mkdir alpine_apachebench
    vi Dockerfile

    FROM alpine
    RUN apk update                \
    && apk add apache2-utils  \
    && rm -rf /var/cache/apk/*

    创建后推送私仓

    cd ..
    docker build -f alpine_apachebench/Dockerfile -t apachebench:v1 .
    docker tag apachebench:v1 repo.k8s.local/library/apachebench:v1
    docker push repo.k8s.local/library/apachebench:v1

    用docker进入容器进行压测

    docker run -it --rm apachebench:v1
    wget http://192.168.244.5:80/showvar
    ab -n 10000 -c 100 http://192.168.244.5:80/showvar
    ab -t 120 -c 100 http://192.168.244.5:80/showvar

    k8s中临时测试容器

    kubectl run busybox --image repo.k8s.local/library/apachebench:v1 --restart=Never --rm -it busybox -- sh
    wget http://svc-openresty.test.svc:31080/showvar
    ab -n 10000 -c 100 http://svc-openresty.test.svc:31080/showvar

    使用官方测试镜像测试

    wget https://k8s.io/examples/application/php-apache.yaml

    cat php-apache.yaml|grep image:
    使用k8s.mirror.nju.edu.cn替换registry.k8s.io

    docker pull k8s.mirror.nju.edu.cn/hpa-example
    docker tag k8s.mirror.nju.edu.cn/hpa-example:latest repo.k8s.local/registry.k8s.io/hpa-example:latest
    docker push repo.k8s.local/registry.k8s.io/hpa-example:latest
    sed -i "/image:/{s/image: registry.k8s.io/image: repo.k8s.local\/registry.k8s.io/}" php-apache.yaml

    kubectl apply -f php-apache.yaml -n test
    kubectl get pod -n test
    kubectl get svc -n test

    apachebench进行测试

    kubectl run busybox --image repo.k8s.local/library/apachebench:v1 --restart=Never --rm -it busybox -- sh
    wget -O index.html http://php-apache.test.svc 
    ab -n 10000 -c 100 http://php-apache.test.svc/

    kubectl top pod -n test

    NAME                                     CPU(cores)   MEMORY(bytes)           
    php-apache-86b74c667b-pb6cg              199m         110Mi      

    get vpa -n test vpa-test-php-apache

    NAME                  MODE   CPU    MEM     PROVIDED   AGE
    vpa-test-php-apache   Auto   247m   100Mi   True       14m

    kubectl describe vpa -n test vpa-test-php-apache

    Name:         vpa-test-php-apache
    Namespace:    test
    Labels:       app.kubernetes.io/instance=vpa
    Annotations:  <none>
    API Version:  autoscaling.k8s.io/v1
    Kind:         VerticalPodAutoscaler
    Metadata:
      Creation Timestamp:  2024-01-03T06:33:54Z
      Generation:          1
      Resource Version:    15495088
      UID:                 8b2df56f-88be-4201-b9fb-e42fa4eac284
    Spec:
      Resource Policy:
        Container Policies:
          Container Name:  php-apache
          Max Allowed:
            Cpu:     700m
            Memory:  100Mi
          Min Allowed:
            Cpu:     100m
            Memory:  20Mi
      Target Ref:
        API Version:  apps/v1
        Kind:         Deployment
        Name:         php-apache
      Update Policy:
        Update Mode:  Auto
    Status:
      Conditions:
        Last Transition Time:  2024-01-03T06:34:04Z
        Status:                True
        Type:                  RecommendationProvided
      Recommendation:
        Container Recommendations:
          Container Name:  php-apache
          Lower Bound:
            Cpu:     100m
            Memory:  100Mi
          Target:
            Cpu:     247m
            Memory:  100Mi
          Uncapped Target:
            Cpu:     247m
            Memory:  262144k
          Upper Bound:
            Cpu:     700m
            Memory:  100Mi
    Events:          <none>

    如果你看 Recommendation 推荐部分,可以看到如下所示的一些信息:
    Target:这是 VPA 在驱逐当前 Pod 并创建另一个 Pod 时将使用的真实值。
    Lower Bound:这反映了触发调整大小的下限,如果你的 Pod 利用率低于这些值,则 VPA 会将其逐出并缩小其规模。
    Upper Bound:这表示下一次要触发调整大小的上限。如果你的 Pod 利用率高于这些值,则 VPA 会将其驱逐并扩大其规模。
    Uncapped target:如果你没有为 VPA 提供最小或最大边界值,则表示目标利用率。

    kubectl top pod -n test

    NAME                                     CPU(cores)   MEMORY(bytes)              
    php-apache-86b74c667b-mnpdw              494m         76Mi            
    php-apache-86b74c667b-q2qwj              496m         64Mi  

    replicas: 改成2后,查看pod,其中资源限制已自动修改从200m改到494m,完成扩容

          resources:
            limits:
              cpu: 494m
            requests:
              cpu: 247m
              memory: 100Mi

    ==============

    HPA 水平自动伸缩

    负责调整 pod 的副本数量来实现。是最常用的弹性伸缩组件
    解决的是业务负载波动较大的问题
    依赖 metrics-server 组件收集 pod 上的 metrics,然后根据预先设定的伸缩策略决定扩缩容 pod
    metrics-server 默认只支持基于 cpu、memory 监控指标伸缩策略
    如果要使用自定义指标(比如 QPS)作为伸缩策略,需要额外安装 prometheus-adapter,将自定义指标转换为 k8s apiserver可以识别的指标
    HPA-Controller 在k8s默认的 controller-manager 中已经安装
    Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路(它不是一个连续的过程)。间隔由 kube-controller-manager 的 –horizontal-pod-autoscaler-sync-period 参数设置(默认间隔为 15秒)
    缩容要超过一定冷却器(默认5min)-horizontal-pod-autoscaler-cpu-initialization-period

    在 kubernetes 1.9 之后,支持hpa自动扩展 statefulset ,水平 Pod 自动扩缩不适用于无法扩缩的对象(例如:DaemonSet。)

    扩缩比例

    期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

    例 1: 某个 deployment 中当前 replicas 设置为 2,CPU request 值为 100m(desiredMetricValue),当前从 metric server 得到的 CPU metric 为 200m(currentMetricValue)
    100m,代表 0.1 个 CPU
    则:desiredReplicas = 2 ( 200 / 100 ) = 4,即运行的 Pod 数量会翻倍,ratio = 2
    如果当前 CPU metric 为 50m
    则:desiredReplicas = 2
    ( 50 / 100 ) = 1,即运行的 Pod 数量减半,ratio = 0.5
    当 ratio 计算出来与 1 接近时,则不会变化,以防止出现过度扩展或者收缩,默认变化小于 0.1(tolerance)时(即 ratio 计算出来大于 0.9 小于 1.1)不会变动。
    我们可以通过–horizontal-pod-autoscaler-tolerance 改变这个默认值。
    当指定了 targetAverageValue 或者 targetAverageUtilization 值 ,计算 currentMetricValue 时会把得到的结果对目标(比如 deployment)中所有的 Pod 的数量取平均值。
    在计算平均值时,正在停止或者失败的 Pod 不记入 Pod 数量。这里会计算两次平均值。
    在第一次计算平均值时,不是 ready 状态和缺少 metric 的 Pod不记入Pod 总数。
    在第二次计算平均值时,不是 ready 状态和缺少 metric 的 Pod记入Pod 总数。
    用两次计算平均值算出对应的调整比率(ratio),如果第二次算出的 ratio 反转了 scale 方向,或者处于 tolerance 之内则放弃 scale,否则按第二次算出的 ratio 进行调整。
    如果在 HPA 中指定多个目标 metric,则对每个 metric 重复上述计算过程,最后取 desiredReplicas 最大的值做为调整值。
    最后,scale up 会尽快进行,而 scale down 会逐步进行,默认间隔为 5 分钟,可以通过–horizontal-pod-autoscaler-downscale-stabilization flag 更改设置。
    在 5 分钟之内,每隔 15 秒计算一次 scale down 的值,最后取所有结果中最大的值做为这次 scale down 的最终值。

    metrics 的分类

    最新版 HPA:autoscaling/v2beta1,有四种类型的 metrics

    Resource:支持k8s所有系统资源,包括cpu、memory。一般只用cpu,memory不准确。
    Pods:由 pod 自身提供的自定义 metrics 数据
    Object:监控指标部署由 pod 本身的服务提供,比如 Ingress
    External:来自外部系统的自定义指标

    autoscaling api 版本

    k8s 1.23 起 autoscaling/v2beta2 正式GA ,需改用autoscaling/v2,不支持autoscaling/v1

    hpa

    vi hpa.yaml

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: hpa-test-openresty
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: openresty
      minReplicas: 1
      maxReplicas: 3
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50

    kubectl apply -f hpa.yaml

    测试

    kubectl exec -it pod/test-pod-0 -n test -- curl -k http://svc-openresty.test.svc:31080
    kubectl exec -it pod/test-pod-0 -n test -- /bin/sh  -c 'while true; do curl -k http://svc-openresty.test.svc:31080; done '
    
    kubectl get hpa -n test -w
    kubectl top pod -n test 

    命行修改

    kubectl autoscale deployment php-apache -ntest –cpu-percent=50 –min=1 –max=4
    kubectl get autoscale deployment php-apache -ntest
    命令创建了一个叫“php-apache”的 HPA,与 deployment 的名称相同
    我们为 deployment “php-apache”创建了 HPA,replicas 变动范围是最小 1,最大 4。目标 CPU 利用率(utilization)为 50%。上面我们设定 CPU request 值为 200m,所以转发为目标平均 CPU 值为 100m
    命令只能运行一次,重复运行会报“AlreadyExists”错误
    Error from server (AlreadyExists): horizontalpodautoscalers.autoscaling "php-apache" already exists

    kubectl delete hpa/php-apache -n test

    查看 HPA “php-apache”
    kubectl get hpa/php-apache -n test

    NAME                  REFERENCE                    TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
    php-apache            Deployment/php-apache        <unknown>/50%   1         4         0          7s

    apachebench进行测试

    kubectl run busybox --image repo.k8s.local/library/apachebench:v1 --restart=Never --rm -it busybox -- sh
    wget -O index.html http://php-apache.test.svc 
    ab -n 1000 -c 100 http://php-apache.test.svc/

    kubectl get hpa/hpa-test-php-apache -n test
    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
    hpa-test-php-apache Deployment/php-apache 0%/50% 1 3 1 10m

    kubectl exec -it pod/test-pod-0 -n test — /bin/sh -c ‘while true; do curl -k http://php-apache.test.svc/; done ‘

    kubectl get hpa/hpa-test-php-apache -n test

    kubectl get hpa/hpa-test-php-apache -n test
    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
    hpa-test-php-apache Deployment/php-apache 75%/50% 1 8 3 12m

    kubectl get hpa/hpa-test-php-apache -n test
    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
    hpa-test-php-apache Deployment/php-apache 56%/50% 1 8 5 13m

    kubectl get hpa/hpa-test-php-apache -n test
    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
    hpa-test-php-apache Deployment/php-apache 42%/50% 1 8 6 13m

    基于官方镜像创建1~8个副本,扩容每30秒创建2个pod,缩容每分种缩一个,会先缩新创建的
    vi hpa.yaml

    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    metadata:
      name: hpa-test-php-apache
    spec:
      scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: php-apache
      minReplicas: 1
      maxReplicas: 8
      metrics:
      - type: Resource
        resource:
          name: cpu
          target:
            type: Utilization
            averageUtilization: 50
      behavior:
        scaleDown:
          #selectPolicy: Disabled
          stabilizationWindowSeconds: 60
          policies:
          - type: Percent
            value: 20
            periodSeconds: 60
          - type: Pods
            value: 1
            periodSeconds: 60
        scaleUp:
          stabilizationWindowSeconds: 0
          policies:
          - type: Percent
            value: 20
            periodSeconds: 30
          - type: Pods
            value: 2
            periodSeconds: 30
          selectPolicy: Max

    The post k8s_安装14_vpa_hpa first appeared on C1G军火库.



沪ICP备19023445号-2号
友情链接