精华内容
下载资源
问答
  • k8s弹性伸缩
    千次阅读
    2020-08-11 11:07:24

    按照伸缩粒度,分为服务伸缩和节点伸缩

    1. 服务伸缩
      k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA, addon resizer 和 HPA。
      此外,各大云厂商也积极贡献提供了多种伸缩组件,例如阿里云提供的 cronHPA。
      在服务粒度的伸缩中,依据执行触发时机不同,可分为:立即执行,定时执行和预测性执行
      1.1 立即执行
      立即执行又细分为垂直伸缩和水平伸缩
      1.1.2 垂直伸缩
      k8s 中的垂直伸缩一般是指调整 Pod 的内存和 CPU 配额
      可用工具:k8s 官方 autoscaler 包中有两个类型的垂直伸缩组件:VPA(vertical pod autoscaler) 和 addon resizer:
      addon resizer
      可以根据集群节点数量来动态地调整某个其他 deployment 中的 pod 的配额。
      addon resizer 周期性地查看集群节点数量,然后计算出监控的 pod 需要分配的内存和 CPU,如果 pod 的实际 pod 配额和所需配额超过某个阈值,则会修改 deployment 并触发生成新的 pod。addon resizer 的这种特性决定了它用来伸缩与集群规模密切相关的服务。一般, addon resizer 用来伸缩部署在集群内的 heapster, metrics-server, kube-state-metrics等监控组件。
      VPA
      设置 VPA 后,它能够自动为 pod 设定 request 和 limit 配额值,然后动态地将 pod 调度到合适的节点上去。
      VPA 在 k8s 中定义类型为 VerticalPodAutoscaler 的 CRD,为每个需要开启垂直弹性伸缩功能的 deployment 创建一个 custom resource,然后 VPA 会定期查看对应 pod 的资源使用情况,结合历史数据,自动调整 pod 的配额。
      VPA controller 由三部分组成。
      Recommender:它监视当前和过去的资源消耗,并基于此提供容器的cpu和内存请求的推荐值。
      Updater:它检查哪个托管的pod设置了正确的资源,如果没有,则杀死它们,以便它们的控制器可以用更新后的请求重新创建它们。
      Admission Plugin:它在新pod上设置正确的资源请求(由于Updater的活动,它们的控制器只是创建或重新创建了这些请求)。
      使用 VPA 监控 deployment 时,它并不会去改变 deployment 的配置,而是使用 admission plugin 以类似 pre hook 的方式
      在创建 pod 时动态为其配置配额值。
      使用 VPA 之前需要注意以下问题:
      VPA 默认会从 metrics server 中采集历史数据,因此使用 VPA 之前,需要配置好 metrics server。VPA 也支持从 prometheus 中采集历史数据,不过需要额外的配置。
      VPA 在伸缩调整过程中,是通过重启 pod 来使调整生效的,因此基础架构不同,可能会引起服务闪断,需要具体分析服务是否可接受使用 VPA 扩容有上限,具体受 pod 所在宿主机影响。为 pod 分配的资源无法超过宿主机的大小。如果 recommender 计算出的 pod 所需资源超过节点可用资源,将导致 pod 一直 pending。这点可与通过与 cluster autoscaler 共同使用来部分解决。VPA 目前不应与基于内存和 CPU 监控的水平Pod自动调度器(HPA)一起使用,否则可能产生预期外的行为。
      1.1.3 水平伸缩
      根据观察到的CPU使用率(或使用自定义指标支持,基于某些其他应用程序提供的指标)
      自动缩放 replication 控制器,deployment,副本集或状态集中的 pod 数量。
      Horizontal Pod Autoscaler 是 k8s 内置的水平伸缩控制器
      使用 HPA 一般需要先搭建 metrics server,metrics server的搭建及使用将另起一篇文章专门讲述
      HPA 实现为Kubernetes API资源和控制器。资源决定控制器的行为。控制器定期(默认为 15 秒)调整复制控制器或部署中的副本数量,以使所观察到的平均CPU利用率与用户指定的目标相匹配
      1.2 定时伸缩
      kubernetes 官方并没有提供定时伸缩相关的组件,但是其原理并不难,只需按照设定的时间调用 kubernetes 的 API 即可。
      1.3 预测性伸缩
      目前暂无成熟的技术方案。

    2. 节点伸缩
      节点伸缩分为垂直伸缩、水平伸缩、定时伸缩(目前暂无成熟方案,本文不介绍)
      2.1 垂直伸缩
      与 kubernetes 本身关系不大,其功能主要取决于厂商。例如,厂商是否支持主机的升降配,以及升降配过程中是否需要重启主机等。如果需要重启主机,那么在进行伸缩之前,我们需要先把节点上的 pod 驱逐到其他主机。但是如果我们是由于机器资源不够用而扩容的话,这样会加剧资源不够用的情况,造成更大的 pending 状态的 pod。因此,如果如果厂商不支持不重启就能扩容的话,不建议采用这种方式进行节点扩容。
      2.2 水平伸缩
      CA(Cluster Autoscaler) 是 kubernetes 官方的节点水平伸缩组件。
      它可以在下列条件之一为真时自动调整Kubernetes集群的大小:
      集群中有 pod 由于资源不足而一直 pending
      集群中有些节点在很长一段时间内没有得到充分利用,且其上的 pod 可以被调度到其他节点上。
      cluster autoscaler 虽然是 kubernetes 官方标准,但是由于其对云厂商依赖较深,因此具体使用方法,功能以及限制以云厂商具体实现为准。目前支持以下云厂商: Google Cloud Platform, AWS, AliCloud, Azure, BaiduCloud。
      以 AliCloud 为例,默认单个用户按量付费实例的配额是30台,单个VPC的路由表限额是50条;且每个可用区的同一类型的实例库存容量波动很大,如果短时间内大量购买同一区同一配置的实例,很容易出现库存不足导致扩容失败。建议在伸缩组中配置多种同规格的实例类型,提高节点伸缩成功率。
      实际使用中,一般为 node 建立多个 node group,专门配置几个 group 来启用弹性伸缩应对突发流量进行扩缩容。主要的 group 并不进行扩缩容,来避免扩缩容导致对大范围的服务的影响。
      此外,节点水平伸缩能否成功实施,与调度策略密切相关。kubernetes 在为 pod 选择可分配节点时,
      是采用 LeastRequestedPriority 策略,简单来说就是就是尽可能把资源打散,把 pod 分配到资源利用率低的节点。这样会倒是有一批利用率较低,但未到缩容阈值的节点,因此会导致无法成功缩容,资源利用率低。因此实际使用时,需要调整 kubernetes 调度策略,来达到最优的结果。

    参考文章:https://segmentfault.com/a/1190000021545907

    更多相关内容
  • k8s弹性伸缩

    2021-06-21 10:01:22
    本课程主要包含k8s集群的安装,k8s各 种资源详细介绍和使用,k8s各种扩展组件的部署和使用,k8s核心功能弹性伸缩演示,k8s持久化存储,k8s代码自动发布,让你真正的能够让你的业务在k8s中落地运行!
  • k8s弹性伸缩概念以及测试用例 本文原文出处:https://juejin.im/post/5c82367ff265da2d85330d4f 弹性伸缩式k8s中的一大亮点功能,当负载大的时候,你可以对应用进行扩容,提升pod的副本数来应对大量的流量,当负载小...

    k8s弹性伸缩概念以及测试用例

    本文原文出处:https://juejin.im/post/5c82367ff265da2d85330d4f

    弹性伸缩式k8s中的一大亮点功能,当负载大的时候,你可以对应用进行扩容,提升pod的副本数来应对大量的流量,当负载小的时候可以对应用进行缩容,以避免资源浪费。也可以让应用自动的进行扩容和缩容,这一功能有用。例如当微博出现了一个话题时,这个时候人们都去访问,此时他的服务器将无法处理大量的流量访问,这个时候就需要扩容,而当这个话题不在新鲜时,人们的访问流量也就是降下来了,那么就需要对服务器进行缩容处理,来自动适应流量需求。

    scale命令:扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量

    # 语法
    kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)
    # 将名为foo中的pod副本数设置为3。
    kubectl scale --replicas=3 rs/foo
    kubectl scale deploy/nginx --replicas=30
    # 将由“foo.yaml”配置文件中指定的资源对象和名称标识的Pod资源副本设为3
    kubectl scale --replicas=3 -f foo.yaml
    # 如果当前副本数为2,则将其扩展至3。
    kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
    # 设置多个RC中Pod副本数量
    kubectl scale --replicas=5 rc/foo rc/bar rc/baz

    k8s提供了scale和autoscale来进行扩容和缩容。

    1320926-20190909181524667-517629446.png
    现在对go-deployment进行扩容,结果如图

    1320926-20190909181544717-1630625175.png

    当访问量减少了就进行缩容
    1320926-20190909181602153-475968462.png
    现在我不想手动的进行扩容和缩容了,我想实现让它当访问流量大的时候自动扩容,当访问流量小的时候自动缩容。这个时候autoscale出现了,利用他我们就可以实现自动扩容和缩容。

    # 语法
    kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
    # 使用 Deployment “foo”设定,使用默认的自动伸缩策略,指定目标CPU使用率,使其Pod数量在2到10之间
    kubectl autoscale deployment foo --min=2 --max=10
    # 使用RC“foo”设定,使其Pod的数量介于1和5之间,CPU使用率维持在80%
    kubectl autoscale rc foo --max=5 --cpu-percent=80

    到目前为止,k8s一共提供了2个不同维度的AutoScaler。如下图:

    1320926-20190909181623817-957871637.png

    k8s把弹性伸缩分为两类:

    • 资源维度:保障集群资源池大小满足整体规划,当集群内的资源不足以支撑产出新的pod时,就会触发边界进行扩容
    • 应用维度:保障应用的负载处在预期的容量规划内

    对应两种伸缩策略:

    • 水平伸缩
      • 集群维度:自动调整资源池规模(新增/删除Worker节点)
      • Pod维度:自动调整Pod的副本集数量
    • 垂直伸缩
      • 集群维度:不支持
      • Pod维度:自动调整应用的资源分配(增大/减少pod的cpu、内存占用)

    其中最为成熟也是最为常用的伸缩策略就是HPA(水平Pod伸缩),所以下面以它为例来重点分析,官方文档在此:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

    缩容扩容的基本流程为三大步骤:

    1.采集监控指标

    2.聚合监控指标,判断是否需要执行缩扩容

    3.执行缩容扩容操作

    HPA水平缩容扩容架构图
    1320926-20190909181648673-1140632238.png

    HPA的监控指标

    根据官方文档的描述,HPA是使用巡检(Control Loop)的机制来采集Pod资源使用情况的,默认采集间隔为15s,可以通过Controller Manager(Master节点上的一个进程)的--horizontal-pod-autoscaler-sync-period参数来手动控制。

    目前HPA默认采集指标的实现是Heapster,它主要采集CPU的使用率;beta版本也支持自定义的监控指标采集,但尚不稳定,不推荐使用

    因此可以简单认为,HPA就是通过CPU的使用率作为监控指标的。

    聚合算法

    采集到CPU指标后,k8s通过下面的公式来判断需要扩容多少个pod

    desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

    ceil表示向上取整,举个实际例子,假设某个服务运行了4个Pod,当前的CPU使用率为50%,预期的CPU使用率为25%,那么满足预期的实际Pod数量就是4 * (50% / 25%) = 8个,即需要将Pod容量扩大一倍,增加4个Pod来满足需求。

    当然上述的指标并不是绝对精确的,首先,k8s会尽可能的让指标往期望值靠近,而不是完全相等,其次HPA设置了一个容忍度(tolerance)的概念,允许指标在一定范围内偏离期望值,默认是0.1,这就意味着如果你设置调度策略为CPU预期使用率 = 50%,实际的调度策略会是小于45%或者大于55%进行缩扩容,HPA会尽力把指标控制在这个范围内(容忍度可以通过--horizontal-pod-autoscaler-tolerance来调整)

    需要注意的是:

    • 一是k8s做出决策的间隔,它不会连续地执行扩缩容动作,而是存在一定的cd,目前扩容动作的cd为3分钟,缩容则为5分钟
    • 二是k8s针对扩容做了一个最大限制,每次扩容的pod数量不会大于当前副本数量的2倍。

    转载于:https://www.cnblogs.com/jasonboren/p/11493347.html

    展开全文
  • 简介上一批文章写了,基于CPU指标的弹性伸缩,资源指标只包含CPU、内存,一般来说也够了。但如果想根据自定义指标:如请求qps/5xx错误数来实现HPA,就需要使用自定义指标了,目前比较成熟的实现是 Prometheus Custom ...

    简介

    上一批文章写了,基于CPU指标的弹性伸缩,资源指标只包含CPU、内存,一般来说也够了。但如果想根据自定义指标:如请求qps/5xx错误数来实现HPA,就需要使用自定义指标了,目前比较成熟的实现是 Prometheus Custom Metrics。自定义指标由Prometheus来提供,再利用k8s-prometheus-adpater聚合到apiserver,实现和核心指标(metric-server)同样的效果。

    2440b22c1178fd5bfa9f405105d9df06.png

    下面我们就来演示基于prometheus监控自定义指标实现k8s pod基于qps的弹性伸缩

    这里已经部署好prometheus环境

    准备扩容应用

    部署一个应用,且应用需要允许被prometheus采集数据

    apiVersion: apps/v1

    kind: Deployment

    metadata:

    labels:

    app: metrics-app

    name: metrics-app

    spec:

    replicas: 3

    selector:

    matchLabels:

    app: metrics-app

    template:

    metadata:

    labels:

    app: metrics-app

    annotations:

    prometheus.io/scrape: "true"# 设置允许被prometheus采集

    prometheus.io/port: "80"# prometheus 采集的端口

    prometheus.io/path: "/metrics"# prometheus 采集的路径

    spec:

    containers:

    - image: metrics-app

    name: metrics-app

    ports:

    - name: web

    containerPort: 80

    resources:

    requests:

    cpu: 200m

    memory: 256Mi

    readinessProbe:

    httpGet:

    path: /

    port: 80

    initialDelaySeconds: 3

    periodSeconds: 5

    livenessProbe:

    httpGet:

    path: /

    port: 80

    initialDelaySeconds: 3

    periodSeconds: 5

    ---

    apiVersion: v1

    kind: Service

    metadata:

    name: metrics-app

    labels:

    app: metrics-app

    spec:

    ports:

    - name: web

    port: 80

    targetPort: 80

    selector:

    app: metrics-app

    应用部署之后,通过prometheus web端验证是否已经自动发现

    5e13fccd2e3af69a3f19dab84b62e393.png

    验证指标能否正常采集

    7f3411f027bd9b4921978f6ba937b15b.png

    这样我们部署的扩容应用就准备完成了,接下来的内容就是HPA如何获取其qps进行扩容的配置了

    部署 Custom Metrics Adapter

    prometheus采集到的metrics并不能直接给k8s用,因为两者数据格式不兼容,还需要另外一个组件(k8s-prometheus-adpater),将prometheus的metrics 数据格式转换成k8s API接口能识别的格式,转换以后,因为是自定义API,所以还需要用Kubernetes aggregator在主APIServer中注册,以便直接通过/apis/来访问。

    prometheus-adapter GitHub地址:https://github.com/DirectXMan12/k8s-prometheus-adapter

    该 PrometheusAdapter 有一个稳定的Helm Charts,我们直接使用,这里使用helm 3.0版本,使用微软云的镜像

    先准备下helm环境(如已有可忽略):

    wget https://get.helm.sh/helm-v3.0.0-linux-amd64.tar.gz

    tar zxvf helm-v3.0.0-linux-amd64.tar.gz

    mv linux-amd64/helm /usr/bin/

    helm repo add stable http://mirror.azure.cn/kubernetes/charts

    helm repo update

    helm repo list

    部署prometheus-adapter,指定prometheus地址:

    # helm install prometheus-adapter stable/prometheus-adapter --namespace kube-system --set prometheus.url=http://prometheus.kube-system,prometheus.port=9090

    # helm list -n kube-system

    验证部署成功

    # kubectl get pods -n kube-system

    NAME READY STATUS RESTARTS AGE

    prometheus-adapter-86574f7ff4-t9px4 1/1 Running 0 65s

    确保适配器注册到APIServer:

    # kubectl get apiservices |grep custom

    # kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1"

    创建HPA策略

    我们配置的扩容规则策略为每秒QPS超过0.8个就进行扩容

    [root@k8s-master-02 ~]# cat app-hpa-v2.yml

    apiVersion: autoscaling/v2beta2

    kind: HorizontalPodAutoscaler

    metadata:

    name: metrics-app-hpa

    namespace: default

    spec:

    scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: metrics-app

    minReplicas: 1

    maxReplicas: 10

    metrics:

    - type: Pods

    pods:

    metric:

    name: http_requests_per_second

    target:

    type: AverageValue

    averageValue: 800m# 800m 即0.8个/秒,如果是阀值设置为每秒10个,这里的值就应该填写10000m

    [root@k8s-master-02 ~]# kubectl apply -f app-hpa-v2.yml

    配置prometheus自定义指标

    当创建好HPA还没数据,因为适配器还不知道你要什么指标(http_requests_per_second),HPA也就获取不到Pod提供指标,接下来我们就要解决监控值没有正常获取的问题,即配置自定义指标

    [root@k8s-master-02 ~]# kubectl get hpa

    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE

    metrics-app-hpa Deployment/metrics-app /800m 1 10 3 36s

    ConfigMap在default名称空间中编辑prometheus-adapter ,并seriesQuery在该rules: 部分的顶部添加一个新的配置:(获取该服务的所有pod 2分钟之内的http_requests监控值并计算平均值,然后相加对外提供数据)

    [root@k8s-master-02 ~]# kubectl edit cm prometheus-adapter -n kube-system

    apiVersion: v1

    data:

    config.yaml: |

    rules:

    - seriesQuery: 'http_requests_total{kubernetes_namespace!="",kubernetes_pod_name!=""}'

    resources:

    overrides:

    kubernetes_namespace: {resource: "namespace"}

    kubernetes_pod_name: {resource: "pod"}

    name:

    matches: "^(.*)_total"

    as: "${1}_per_second"

    metricsQuery: 'sum(rate(<<.series>>{<<.labelmatchers>>}[2m])) by (<<.groupby>>)'

    ……

    配置好之后,因为adapter pod不支持配置动态加载,所以我们修改了配置,需要删除一下pod,让他重新加载一个新的生效配置

    [root@k8s-master-02 ~]# kubectl delete pod prometheus-adapter-86574f7ff4-t9px4 -n kube-system

    删除pod重新生成配置之后,大约一两分钟在观察hpa的值就正常了

    [root@k8s-master-02 ~]# kubectl get hpa

    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE

    metrics-app-hpa Deployment/metrics-app 416m/800m 1 10 2 17m

    验证基于自定义指标的扩容

    接下来通过压测验证扩容缩容

    [root@k8s-master-02 ~]# kubectl get svc

    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

    kubernetes ClusterIP 10.0.0.1 443/TCP 84d

    metrics-app ClusterIP 10.0.0.80 80/TCP 3d2h

    [root@k8s-master-02 ~]# ab -n 100000 -c 100 http://10.0.0.80/metrics

    压测过程中观察hpa和pod状态发现pod已经自动扩容到了10个pod

    [root@k8s-master-02 ~]# kubectl get hpa

    NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE

    metrics-app-hpa Deployment/metrics-app 289950m/800m 1 10 10 38m

    [root@k8s-master-02 ~]# kubectl get pods

    NAME READY STATUS RESTARTS AGE

    metrics-app-7674cfb699-2gznv 1/1 Running 0 40s

    metrics-app-7674cfb699-2hk6r 1/1 Running 0 40s

    metrics-app-7674cfb699-5926q 1/1 Running 0 40s

    metrics-app-7674cfb699-5qgg2 1/1 Running 0 2d2h

    metrics-app-7674cfb699-9zkk4 1/1 Running 0 25s

    metrics-app-7674cfb699-dx8cj 1/1 Running 0 56s

    metrics-app-7674cfb699-fmgpp 1/1 Running 0 56s

    metrics-app-7674cfb699-k9thm 1/1 Running 0 25s

    metrics-app-7674cfb699-wzxhk 1/1 Running 0 2d2h

    metrics-app-7674cfb699-zdbtg 1/1 Running 0 40s

    停止压测一段时间之后,pod数量就会根据HPA策略自动缩容成1个,说明我们的配置是成功的

    喜欢 (0)or分享 (0)

    展开全文
  • 5: k8s弹性伸缩 k8s弹性伸缩,需要附加插件heapster监控 使用heapster监控 heapster通过apiserver查询节点信息 heapster向node节点cadvisor获取监控数据 heapster将数据写入influxdb数据库中 grafana冲数据库中取出...

    7. k8s弹性伸缩

    k8s弹性伸缩,需要附加插件heapster监控

    • 使用heapster监控
      • heapster通过apiserver查询节点信息
      • heapster向node节点cadvisor获取监控数据
      • heapster将数据写入influxdb数据库中
      • grafana冲数据库中取出数据进行出图
      • dashboard调用grafana的图进行展示

    7.1 安装heapster监控

    7.1.1 上传并导入镜像,打标签

    ls *.tar.gz
    for n in `ls *.tar.gz`;do docker load -i $n ;done
    
    docker tag docker.io/kubernetes/heapster_grafana:v2.6.0 10.0.0.11:5000/heapster_grafana:v2.6.0
    docker tag  docker.io/kubernetes/heapster_influxdb:v0.5 10.0.0.11:5000/heapster_influxdb:v0.5
    docker tag docker.io/kubernetes/heapster:canary 10.0.0.11:5000/heapster:canary
    

    7.1.2 master节点上传heapster配置文件

    修改配置文件:
    #heapster-controller.yaml
        spec:
          nodeName: 10.0.0.13
          containers:
          - name: heapster
            image: 10.0.0.11:5000/heapster:canary
            imagePullPolicy: IfNotPresent
            
    #influxdb-grafana-controller.yaml
        spec:
          nodeName: 10.0.0.13
          containers:
    
    全部创建
    kubectl create -f .
    
    [root@k8s-master monitor]# kubectl get pod -n kube-system 
    NAME                                           READY     STATUS    RESTARTS   AGE
    heapster-mnd99                                 1/1       Running   0          17s
    influxdb-grafana-p2vhh                         2/2       Running   0          17s
    kube-dns-32943122-3jv34                        4/4       Running   4          5h
    kubernetes-dashboard-latest-3467346521-jlx3v   1/1       Running   1          3h
    

    7.1.3 打开dashboard验证是否监控

    [root@k8s-master monitor]# systemctl restart kube-apiserver.service
    在这里插入图片描述

    7.2 弹性伸缩

    7.2.1 修改rc的配置文件

    [root@k8s-master deployment]# cat k8s_deploy.yml 
    apiVersion: extensions/v1beta1          #扩展版的
    kind: Deployment                #资源类型
    metadata:                               #资源属性
      name: nginx-deployment        #资源的名称
    spec:
      replicas: 3                   #副本数
      minReadySeconds: 60   #滚动升级间隔
      template:
        metadata:           #模板
          labels:
            app: nginx              #容器的标签
        spec:
          containers:
          - name: nginx             #容器的名称
            image: 10.0.0.11:5000/nginx:1.13        #容器所使用的镜像
            ports:
            - containerPort: 80             #容器对外开放的端口
            resources:                      #资源限制
              limits:                       #最大
                cpu: 100m           #cpu时间片
              requests:                     #最小
                cpu: 100m
    
    创建deployment资源        
    kubectl create  -f k8s_deploy.yaml
    
    创建service资源	
    kubectl expose deployment nginx-deployment --port=80 --target-port=80 --type=NodePort
    
    --port:指定service端口
    --target-port:指定容器端口
    --type:指定的服务类型,默认clusterip
    

    7.2.2 创建弹性伸缩规则

    创建hpa资源	
    [root@k8s-master deployment]# kubectl autoscale deployment nginx-deployment --max=10 --min=1 --cpu-percent=5
    deployment "nginx-deployment" autoscaled
    
    --max:最多扩容到多少台
    --min:最少缩容到多少台
    --cpu-percent:cpu使用率达到百分之十进行扩容
    

    在这里插入图片描述

    7.2.3 压力测试

    [root@k8s-master deployment]# yum install httpd-tools.x86_64 
    
    [root@k8s-node-2 ~]# ab -n 1000000 -c 20 http://10.0.0.12:16410/index.html
    

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    7.2.4 导出hpa配置

    kubectl get horizontalpodautoscaler --output=yaml
    在这里插入图片描述

    展开全文
  • 这节,将学习弹性的将服务部署到多个节点上。 检查 检查部署情况 kubectl get deployments $ kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE mynode 1/1 1 1 10m READY 显示当前/所需副本的比率 UP-...
  • k8s弹性伸缩(HPA)

    2021-12-17 06:29:01
    在kubernetes中,我们使用pod对外提供服务。这时候,我们需要以下两种情形需要关注: pod因为不明原因挂掉,导致服务不可用 ...那么今天就来介绍一下在k8s 1.6中的弹性伸缩的实施 k8s是kubernetes的官方简...
  • 一、什么是弹性伸缩Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或Deployment对应的Pod,根据观察到的CPU使用量与用户的阈值进行比对,做出是否需要增减实例数量的决策。controller...
  • Kubernetes(k8s)的弹性伸缩

    千次阅读 2020-07-02 21:46:00
    1、什么是K8s弹性伸缩? 答:Hpa(全称叫做Horizontal Pod Autoscaler),Horizontal Pod Autoscaler的操作对象是Replication Controller、ReplicaSet或者Deployment对应的Pod(k8s中可以控制Pod的是rc、rs、...
  • 前言弹性伸缩介绍Metrics Server聚合 API安装HPA(弹性伸缩实验)缩放间隙基于内存弹性伸缩 弹性伸缩介绍 在使用中我们使用一条 kubectl scale 命令可以来实现 Pod 的扩缩容功能,但是这个毕竟是完全手动操作的,要...
  • K8s基础之HPA弹性伸缩

    2021-06-26 09:52:11
    HPA弹性伸缩1、概念2、创建测试deployment和service3、创建HPA4、网站压测5、验证HPA效果 1、概念 HPA全称是Horizontal Pod Autoscaler,翻译成中文是POD水平自动伸缩,HPA可以基于CPU利用率对replication ...
  • K8S是一个使用 Docker 容器进行编排的系统,主要围绕 pods 进行工作。 Pods 是 k8s 生态中最小的调度单位,可以包含一个或多个容器。 k8s是一个开源的容器集群管理系统,可以实现容器集群的自动化部署、自动扩缩容、...
  • 简介:混合云K8s容器化应用弹性伸缩实战1. 前提条件本最佳实践的软件环境要求如下:应用环境:①容器服务ACK基于专有云V3.10.0版本。②公共云云企业网服务CEN。③公共云弹性伸缩组服务ESS。配置条件:1)使用专有云...
  • 访问k8s中应用的方式: 第一种:NodePort类型(该种方式必须在svc配置文件中声明是nodeport类型) type:NodePort ports: -port:80 targetPort:80 此时有两种访问方式: 1、woker1节点的ip+servcie...
  • 企业运维实战--k8s学习笔记14.HPA自动弹性伸缩HPA实例查看监控-CPU、MEMHPA实例监控CPUHPA实例监控CPU+MEM HPA实例查看监控-CPU、MEM HPA(Horizontal Pod Autoscaler)Pod自动弹性伸缩K8S通过对Pod中运行的容器...
  • 弹性扩缩容,发现没有。整个的框架就是流量,服务器。服务器挂了,自动拉起一个镜像。过载了就弹性扩缩容。
  • k8s使用keda监听mq进行弹性伸缩容器

    千次阅读 2022-03-30 11:54:50
    1,在k8s集群上执行apply 下面的yaml文件,新建了ScaledObject 就可以了 1,监控MQ的队例长度与扩容数量的yaml文件内容 apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-xxx-xxx-consumer...
  • Kubernetes自动弹性伸缩可以根据业务流量,自动增加或减少服务。这一功能在实际的业务场景中十分重要。在本文中,我们将了解Kubernetes如何针对应用产生的自定义指标实现自动伸缩。 为什么需要自定义指标? 应用程序...
  • Ansible自动化部署K8S集群 一、Ansible自动化部署K8S集群 1.1 Ansible介绍 Ansible是一种IT自动化工具。它可以配置系统,部署软件以及协调更高级的IT任务,例如持续部署,滚动更新。Ansible适用于管理企业IT基础...
  • autoscaling/v2beta1 2.1 metrics-server安装 2.2 限制CPU和MEM 2.3 自定义metric 前言 HPA(Horizontal Pod Autoscaler)Pod自动弹性伸缩K8S通过对Pod中运行的容器各项指标(CPU占用、内存占用、网络请求量)的...
  • Kubernetes(k8s) Pod 弹性伸缩详解与使用

    千次阅读 2019-04-26 10:54:13
    Kubernetes HPA(Horizontal Pod Autoscaling)Pod水平自动伸缩,通过此功能,只需简单的配置,集群便可以利用监控指标(cpu使用率等)自动的扩容或者缩容服务中Pod数量,当业务需求增加时,系统将为您无缝地自动增加...
  • 弹性伸缩这种功能,不是很多系统都已经实现了,我们直接用就行了吗,为什么还需要个指南呢。 因为。。。。我们先来看看都有哪些相关知识点吧。。。 弹性伸缩涉及到各种软硬件,各色调度平台,策略和系统,其本身...
  • 通过设置k8s中的dns服务可以直接解析service的名字,得到对应service的ip,可以实现服务在集群内部互相访问。 创建dns的rc,注意修改 - --kube-master-url=http://192.168.1.5:8080 执行kubectl create -...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,329
精华内容 2,531
关键字:

k8s弹性伸缩