AWS EC2 Auto Scaling 组：我得到了 Min 和 Max，但 Desired instances limit 的用途是什么？
AWS EC2 Auto Scaling Groups: I get Min and Max, but what's Desired instances limit for?
当您在 AWS EC2 中设置 Auto Scaling 组时，Min 和 Max 界限似乎有意义：
- 根据策略缩减到的最小实例数
- 根据策略扩展到的最大实例数
然而，我一直无法理解 Desired 到底要影响什么。
我一直只是将 Desired 设置为 Min，因为通常情况下，我想向亚马逊支付尽可能少的什一税，除非您需要一个实例来处理负载，否则它应该在Min 个实例。
我知道如果你使用 ElasticBeanstalk 并将 Min 设置为 1 并将 Max 设置为 2 它会将 Desired 设置为 2（当然！）--您不能为 Desired.
选择值
不同 Desired 个实例的用例是什么？它有何不同？当您期望 AWS 的规模低于您的 Desired 如果需要大于 Min?
将其视为滑动范围 UI 元素。
对于最小值和最大值，您正在设置实例缩放的下限。有了所需的容量，您就可以设置您当前希望悬停的实例计数。
示例：
您知道您的应用程序会因营销电子邮件或产品发布而承受沉重的负载……只需预先扩展您所需的容量即可：
aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown
以下是来自 AWS 支持的 "min, desired and max" 值的解释：
MIN: This will be the minimum number of instances that can run in your
auto scale group. If your scale down CloudWatch alarm is triggered,
your auto scale group will never terminate instances below this number
DESIRED: If you trip a CloudWatch alarm for a scale up event, then it
will notify the auto scaler to change it's desired to a specified
higher amount and the auto scaler will start an instance/s to meet
that number. If you trip a CloudWatch alarm to scale down, then it
will change the auto scaler desired to a specified lower number and
the auto scaler will terminate instance/s to get to that number.
MAX: This will be the maximum number of instances that you can run in
your auto scale group. If your scale up CloudWatch alarm stays
triggered, your auto scale group will never create instances more than
the maximum amount specified.
When you expect AWS to scale lower than your Desired if desired is
larger than Min?
当您根据某些 AutoScaling 策略设置 CloudWatch 警报时，会发生这种情况。每当触发该警报时，它都会将 DesiredCount 更新为配置中提到的任何内容。
例如，如果 AutoScalingGroup 配置具有 Min=1、Desired=3、Max=5，并且在 AutoScalingPolicy 上设置了一个警报，表示如果 CPU 使用率连续 10 分钟 <50%，则Remove 1 instances 那么每当触发警报时，它都会将实例计数减 1，直到 DesiredCount = MinCount。
经验教训：将 MinCount 设置为 > 0 或 = DesiredCount。这将确保当 mincount=0 和 CPU 使用率下降时应用程序不会关闭。
通俗地说，DesiredCapacity 值会在扩展和扩展事件中自动更新。
换句话说，
缩小或缩小是通过减小或增大 DesiredCapacity 值来完成的。
所需容量仅表示启动自动缩放时将出现/启动的实例数。这意味着如果所需容量 = 4，则 4 个实例将保持 运行 直到且除非任何放大或缩小事件触发。如果发生放大事件，实例数将上升到最大容量，如果发生缩小事件，实例数将下降到最小容量。
如有错误请指正，谢谢
"Desired" 是（必然）模棱两可的。
- 表示“初始”的实例数。为什么不直接 "initial" 呢？因为这个数字可能会因自动缩放事件而改变。
- 所以它意味着“当前”实例数。为什么不直接 "current" 呢？因为在自动缩放事件期间，实例将启动/终止。这些实例不计入 "current" 个实例。通过 "current"，用户期望 operate-able.
的实例
- 所以它意味着“目标”个实例。那为什么不 "target" 呢？我想 "target" 和 "desired"...
一样好（模棱两可）
我注意到当
时所需容量下降并且没有新实例出现
- 我将其中一个实例设置为备用。它保持 运行 但与 ELB 分离（当通过 ELB DNS 访问时，请求未转发到该特定实例）。 AWS 尚未启动任何新实例。相当理想的容量减少了 1.
- 当我更改实例状态（从备用状态）时，该实例再次附加到 ELB（该实例在通过 ELB DNS 访问时开始接收请求）。想要的容量增加了1，变成了2。
因此，似乎没有连接到 ELB 的实例不能超过由最小值和最大值设置的阈值限制，但所需容量会根据缩减或缩减事件的发生自动调整或更改。这绝对是我所不知道的。
这可能是让 AWS 知道这是给定时间点相应 ELB 所需容量的一种方式。
最小值和最大值是不言自明的，但在我将目标跟踪自动缩放策略附加到 ASG 之前，期望是令人困惑的，其中 CPU 利用率是目标指标。在这里，所需的实例根据目标 CPU 利用率进行了扩展和缩减。如果通过 cloudformation/manual 放置任何所需数量，ASG 将暂时创建与所需数量相同数量的实例。但稍后 ASG 策略将根据目标 CPU 利用率自动调整期望实例。
期望是我们最初的开始。它将根据 scale-in / scale-out.
变为最小值或最大值
我喜欢用滑块类比来理解这一点 -
将最小值和最大值视为屏幕上允许的最大亮度。在这种情况下，您可能不希望 min 为 0（旁注）。所需数量根据环境不断变化（在 ASG 的情况下，它取决于扩展策略）。
例如，如果以下检查每小时运行一次，这就是需要所需数量的地方。
if low_load(<CPU or Mem etc>) and desired_capacity>= min_capacity:
desired_capacity = desired_capacity-1
最大容量也可以理解为您希望根据 cloudwatch_alarm（或任何扩展策略）不断增加所需数量直至达到最大容量。
当您在 AWS EC2 中设置 Auto Scaling 组时，Min 和 Max 界限似乎有意义：
- 根据策略缩减到的最小实例数
- 根据策略扩展到的最大实例数
然而，我一直无法理解 Desired 到底要影响什么。
我一直只是将 Desired 设置为 Min，因为通常情况下，我想向亚马逊支付尽可能少的什一税，除非您需要一个实例来处理负载，否则它应该在Min 个实例。
我知道如果你使用 ElasticBeanstalk 并将 Min 设置为 1 并将 Max 设置为 2 它会将 Desired 设置为 2（当然！）--您不能为 Desired.
不同 Desired 个实例的用例是什么？它有何不同？当您期望 AWS 的规模低于您的 Desired 如果需要大于 Min?
将其视为滑动范围 UI 元素。
对于最小值和最大值，您正在设置实例缩放的下限。有了所需的容量，您就可以设置您当前希望悬停的实例计数。
示例： 您知道您的应用程序会因营销电子邮件或产品发布而承受沉重的负载……只需预先扩展您所需的容量即可：
aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown
以下是来自 AWS 支持的 "min, desired and max" 值的解释：
MIN: This will be the minimum number of instances that can run in your auto scale group. If your scale down CloudWatch alarm is triggered, your auto scale group will never terminate instances below this number
DESIRED: If you trip a CloudWatch alarm for a scale up event, then it will notify the auto scaler to change it's desired to a specified higher amount and the auto scaler will start an instance/s to meet that number. If you trip a CloudWatch alarm to scale down, then it will change the auto scaler desired to a specified lower number and the auto scaler will terminate instance/s to get to that number.
MAX: This will be the maximum number of instances that you can run in your auto scale group. If your scale up CloudWatch alarm stays triggered, your auto scale group will never create instances more than the maximum amount specified.
When you expect AWS to scale lower than your Desired if desired is larger than Min?
当您根据某些 AutoScaling 策略设置 CloudWatch 警报时，会发生这种情况。每当触发该警报时，它都会将 DesiredCount 更新为配置中提到的任何内容。
例如，如果 AutoScalingGroup 配置具有 Min=1、Desired=3、Max=5，并且在 AutoScalingPolicy 上设置了一个警报，表示如果 CPU 使用率连续 10 分钟 <50%，则Remove 1 instances 那么每当触发警报时，它都会将实例计数减 1，直到 DesiredCount = MinCount。
经验教训：将 MinCount 设置为 > 0 或 = DesiredCount。这将确保当 mincount=0 和 CPU 使用率下降时应用程序不会关闭。
通俗地说，DesiredCapacity 值会在扩展和扩展事件中自动更新。
换句话说，
缩小或缩小是通过减小或增大 DesiredCapacity 值来完成的。
所需容量仅表示启动自动缩放时将出现/启动的实例数。这意味着如果所需容量 = 4，则 4 个实例将保持 运行 直到且除非任何放大或缩小事件触发。如果发生放大事件，实例数将上升到最大容量，如果发生缩小事件，实例数将下降到最小容量。
如有错误请指正，谢谢
"Desired" 是（必然）模棱两可的。
- 表示“初始”的实例数。为什么不直接 "initial" 呢？因为这个数字可能会因自动缩放事件而改变。
- 所以它意味着“当前”实例数。为什么不直接 "current" 呢？因为在自动缩放事件期间，实例将启动/终止。这些实例不计入 "current" 个实例。通过 "current"，用户期望 operate-able. 的实例
- 所以它意味着“目标”个实例。那为什么不 "target" 呢？我想 "target" 和 "desired"... 一样好（模棱两可）
我注意到当
时所需容量下降并且没有新实例出现- 我将其中一个实例设置为备用。它保持 运行 但与 ELB 分离（当通过 ELB DNS 访问时，请求未转发到该特定实例）。 AWS 尚未启动任何新实例。相当理想的容量减少了 1.
- 当我更改实例状态（从备用状态）时，该实例再次附加到 ELB（该实例在通过 ELB DNS 访问时开始接收请求）。想要的容量增加了1，变成了2。
因此，似乎没有连接到 ELB 的实例不能超过由最小值和最大值设置的阈值限制，但所需容量会根据缩减或缩减事件的发生自动调整或更改。这绝对是我所不知道的。
这可能是让 AWS 知道这是给定时间点相应 ELB 所需容量的一种方式。
最小值和最大值是不言自明的，但在我将目标跟踪自动缩放策略附加到 ASG 之前，期望是令人困惑的，其中 CPU 利用率是目标指标。在这里，所需的实例根据目标 CPU 利用率进行了扩展和缩减。如果通过 cloudformation/manual 放置任何所需数量，ASG 将暂时创建与所需数量相同数量的实例。但稍后 ASG 策略将根据目标 CPU 利用率自动调整期望实例。
期望是我们最初的开始。它将根据 scale-in / scale-out.
变为最小值或最大值我喜欢用滑块类比来理解这一点 -
将最小值和最大值视为屏幕上允许的最大亮度。在这种情况下，您可能不希望 min 为 0（旁注）。所需数量根据环境不断变化（在 ASG 的情况下，它取决于扩展策略）。
例如，如果以下检查每小时运行一次，这就是需要所需数量的地方。
if low_load(<CPU or Mem etc>) and desired_capacity>= min_capacity:
desired_capacity = desired_capacity-1
最大容量也可以理解为您希望根据 cloudwatch_alarm（或任何扩展策略）不断增加所需数量直至达到最大容量。