标签: autoscaling

我最近开始使用ECS.我能够在ECR中部署容器映像,并为具有CPU /内存限制的容器创建任务定义.我的用例是每个容器都是一个长期运行的应用程序(没有网络服务器,不需要端口映射).容器将按需一次生成,并一次按需删除1.

我能够创建一个包含N个服务器实例的集群.但我希望服务器实例能够自动向上/向下扩展.例如,如果群集中没有足够的CPU /内存,我想要创建一个新实例.

如果有一个实例没有运行容器,我希望缩小/删除该特定实例.这是为了避免在其中运行任务的服务器实例自动缩小终止.

需要哪些步骤才能实现这一目标？

我想根据SQS队列的大小来扩展AWS Fargate容器。看来我只能根据容器的CPU或内存使用量进行扩展。有没有一种方法可以创建根据队列大小进行横向扩展和纵向扩展的策略？有人能够根据其他cloudwatch指标进行扩展吗？

我想配置自动缩放与博托使用缩放策略和指标报警,而不是现在,他们即将过时触发.我已成功创建启动配置和Auto Scaling组,但在创建扩展策略和度量标准警报时遇到问题.如果有人可以提供某些示例的链接,或者提供一些示例,那将非常感激.

我目前正在使用两个扩展策略,这些策略附加到我的自动缩放组:A

1. 在调用CloudWatch警报时调用的向上扩展策略.此CloudWatch警报使用CPUUtilization指标,并在CPU上触发超过80%.
2. 另一种是缩小策略,在调用其他CloudWatch警报时调用该策略.此CloudWatch警报使用CPUUtilization指标,并在CPU低于50%时触发.

这种方法的副作用是当我的ASG实例空闲(完全按比例缩小,没有处理发生)时,我的ASG处于警报状态.

有没有办法以不同的方式设置它,以便我的ASG不处于持续警报状态？

以下是我的CloudFormation模板中的一部分警报:

"ScaleUpPolicy" : {
  "Type" : "AWS::AutoScaling::ScalingPolicy",
  "Properties" : {
    "AdjustmentType" : "ChangeInCapacity",
    "AutoScalingGroupName" : { "Ref" : "WebApplicationASG" },
    "Cooldown" : "1",
    "ScalingAdjustment" : "1"
  }
},
"CPUAlarmHigh": {
  "Type": "AWS::CloudWatch::Alarm",
  "Properties": {
    "EvaluationPeriods": "1",
    "Statistic": "Average",
    "Threshold": "80",
    "AlarmDescription": "Alarm if CPU too high or metric disappears indicating instance is down",
    "Period": "60",
    "AlarmActions": [ { "Ref": "ScaleUpPolicy" } ],
    "Namespace": "AWS/EC2",
    "Dimensions": [ {
      "Name": "AutoScalingGroupName",
      "Value": { "Ref": "WebApplicationASG" }
    } …

场景:我正在运行AWS自动缩放组(ASG),并且我在terraform应用期间更改了关联的启动配置.ASG不受影响.

如何在ASG中重新创建实例(即,逐个替换它们以进行滚动替换),然后基于更改的/新的启动配置？

我尝试过:使用terraform 污染,可以标记要在下一次应用中销毁和重新创建的资源.但是,我不想污染自动缩放组(这是一种资源,在这种情况下不是单个实例),而是单个实例.有没有方法可以玷污单个实例,还是我在想错误的方向？

我正在使用CloudFormation模板,该模板会根据我的请求调出尽可能多的实例,并希望等到它们完成初始化(通过用户数据),然后才能认为堆栈创建/更新已完成.

期望

创建或更新堆栈应等待来自所有新创建的实例的信号,以确保其初始化完成.

如果任何创建的实例无法初始化,我不希望将堆栈创建或更新视为成功.

现实

CloudFormation似乎只在等待首次创建堆栈时的实例信号.更新堆栈并增加实例数似乎忽略了信令.更新操作非常快速地成功完成,而实例仍在初始化.

由于更新堆栈而创建的实例可能无法初始化,但更新操作已经被认为是成功的.

问题

使用CloudFormation,我如何才能使现实符合预期？

我想要在创建堆栈时,以及更新堆栈时应用的相同行为.

类似的问题

我发现只有以下问题符合我的问题:Autoscaling组中的UpdatePolicy无法正常用于AWS CloudFormation更新

它已经开放一年,但没有得到答案.

我正在创建另一个问题,因为我需要添加更多信息,而且我不确定这些细节是否与该问题中的作者相匹配.

再现

为了演示此问题,我在此AWS文档页面上的Auto Scaling Group标题下创建了一个模板,其中包括信令.

创建的模板已经过调整,如下所示:

• 它使用Ubuntu AMI(在区域内ap-northeast-1).该cfn-signal命令已经过引导,并在考虑到此更改时根据需要进行调用.
• 新参数指示在自动缩放组中启动的实例数.
• 在发信号之前添加了2分钟的睡眠时间,以模拟初始化时花费的时间.

这是模板,保存到template.yml:

Parameters:
  DesiredCapacity:
    Type: Number
    Description: How many instances would you like in the Auto Scaling Group?

Resources:
  AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      AvailabilityZones: !GetAZs ''
      LaunchConfigurationName: !Ref LaunchConfig
      MinSize: !Ref DesiredCapacity
      MaxSize: !Ref DesiredCapacity
    CreationPolicy:
      ResourceSignal:
        Count: !Ref DesiredCapacity
        Timeout: PT5M
    UpdatePolicy:
      AutoScalingScheduledAction:
        IgnoreUnmodifiedGroupSizeProperties: true …

以下是我在表格中设置的参数:

以下是我对容量的看法.

为什么它仍然是25个写入单位？它不应该下降到5个写入单位(最小设置)？

我想在我的GKE上运行CronJob,以便每天执行批处理操作.理想的情况是我的集群在作业未运行时扩展到0个节点,并且每次满足计划时动态扩展到1个节点并在其上运行作业.

我首先尝试通过使用kubernetes doc 中的一个简单的CronJob来实现这一点,它只打印当前时间并终止.

我首先使用以下命令创建了一个集群:

gcloud container clusters create $CLUSTER_NAME \
    --enable-autoscaling \
    --min-nodes 0 --max-nodes 1 --num-nodes 1 \
    --zone $CLUSTER_ZONE

然后,我创建了一个CronJob,其中包含以下描述:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: Never

作业计划每小时运行一次,并在终止前打印当前时间.

首先,我想创建具有0个节点的集群,但设置--num-nodes 0结果是错误的.为什么会这样？请注意,我可以在创建集群后手动将集群缩小到0个节点.

其次,如果我的群集有0个节点,则不会调度作业,因为群集不会自动扩展到1个节点,而是会出现以下错误:

无法安排pod:没有可用于安排pod的节点.

第三,如果我的集群有1个节点,则作业正常运行但在此之后,集群不会缩小到0个节点,而是保留1个节点.我让我的集群运行两个连续的工作,并没有在两者之间缩小.我假设一小时应该足够长,以便群集这样做.

我错过了什么？

嗨，大家好，

我已经部署了一个基于 kubeadm 的 Kubernetes 集群，为了基于自定义指标执行 Horizo​​ntalPodAutoscaling，我已经通过 Helm 部署了 prometheus-adpater。

现在，我想编辑 prometheus-adpater 的配置，因为我是 Helm 的新手，我不知道该怎么做。那么你能指导我如何编辑部署的舵图吗？

根据K8s文档，为了避免副本属性的抖动，stabilizationWindowSeconds可以使用

当用于扩展的指标持续波动时，稳定窗口用于限制副本的波动。自动缩放算法使用稳定窗口来考虑过去计算的期望状态以防止缩放。

当指标表明目标应该缩小时，算法会查看先前计算的所需状态并使用指定间隔中的最高值。

据我从文档中了解到，具有以下 hpa 配置：

  horizontalPodAutoscaler:
    enabled: true
    minReplicas: 2
    maxReplicas: 14
    targetCPUUtilizationPercentage: 70
    behavior:
      scaleDown:
        stabilizationWindowSeconds: 1800
        policies:
          - type: Pods
            value: 1
            periodSeconds: 300
      scaleUp:
        stabilizationWindowSeconds: 60
        policies:
          - type: Pods
            value: 2
            periodSeconds: 60

如果在过去 1800 秒（30 分钟）内的任何时间 hpa 计算出的目标 Pod 数量等于 7 个 Pod，则不应缩减我的部署规模（假设从 7 个 Pod 减少到 6 个 Pod）。但我仍在观察部署中副本的抖动。

我在文档中误解了什么以及如何避免连续扩大/缩小 1 个 Pod？

库伯内特v1.20

高性能PA说明：

CreationTimestamp:                                     Thu, 14 Oct 2021 12:14:37 +0200
Reference:                                             Deployment/my-deployment
Metrics:                                               ( current / …