如何在ECS中自動調整服務器？

Question

我最近開始使用ECS。我能夠在ECR中部署一個容器圖像，併爲具有CPU /內存限制的容器創建任務定義。我的用例是每個容器將是一個長時間運行的應用程序（不需要Web服務器，不需要端口映射）。集裝箱將按需求1生成，並一次按需刪除1。

我能夠創建一個具有N個服務器實例的集羣。但我希望能夠讓服務器實例自動擴展/縮小。例如，如果羣集中沒有足夠的CPU /內存，我想要創建一個新實例。

如果有一個沒有運行容器的實例，我希望該實例被縮小/刪除。這是爲了避免自動縮減終止正在運行任務的服務器實例。

需要採取哪些措施才能實現這一目標？

Answer 1

考慮到您已經創建了ECS集羣，AWS提供了關於Scaling cluster instances with CloudWatch Alarms的說明。

假設要縮放基於內存預留集羣，在較高的水平，你需要做到以下幾點：

1. 爲您自動縮放集團創建啓動配置。這
2. 創建一個Auto Scaling組，以便可以擴大和縮小羣集的大小。
3. 創建CloudWatch的警報規模集羣了，如果內存預留超過70％
4. 創建CloudWatch的警報規模集羣下來，如果內存預留下30％

因爲它更多我的專業，我寫了一個例子CloudFormation模板應該讓你開始對這個最：

Parameters: 
    MinInstances: 
    Type: Number 
    MaxInstances: 
    Type: Number 
    InstanceType: 
    Type: String 
    AllowedValues: 
     - t2.nano 
     - t2.micro 
     - t2.small 
     - t2.medium 
     - t2.large 
    VpcSubnetIds: 
    Type: String 

Mappings: 
    EcsInstanceAmis: 
    us-east-2: 
     Ami: ami-1c002379 
    us-east-1: 
     Ami: ami-9eb4b1e5 
    us-west-2: 
     Ami: ami-1d668865 
    us-west-1: 
     Ami: ami-4a2c192a 
    eu-west-2: 
     Ami: ami-cb1101af 
    eu-west-1: 
     Ami: ami-8fcc32f6 
    eu-central-1: 
     Ami: ami-0460cb6b 
    ap-northeast-1: 
     Ami: ami-b743bed1 
    ap-southeast-2: 
     Ami: ami-c1a6bda2 
    ap-southeast-1: 
     Ami: ami-9d1f7efe 
    ca-central-1: 
     Ami: ami-b677c9d2 

Resources: 
    Cluster: 
    Type: AWS::ECS::Cluster 
    Role: 
    Type: AWS::IAM::Role 
    Properties: 
     ManagedPolicyArns: 
     - arn:aws:iam::aws:policy/service-role/AmazonEC2ContainerServiceforEC2Role 
     AssumeRolePolicyDocument: 
     Version: 2012-10-17 
     Statement: 
      - 
      Effect: Allow 
      Action: 
       - sts:AssumeRole 
      Principal: 
       Service: 
       - ec2.amazonaws.com  
    InstanceProfile: 
    Type: AWS::IAM::InstanceProfile 
    Properties: 
     Path:/
     Roles: 
     - !Ref Role  
    LaunchConfiguration: 
    Type: AWS::AutoScaling::LaunchConfiguration 
    Properties: 
     ImageId: !FindInMap [EcsInstanceAmis, !Ref "AWS::Region", Ami] 
     InstanceType: !Ref InstanceType 
     IamInstanceProfile: !Ref InstanceProfile 
     UserData: 
     Fn::Base64: !Sub | 
      #!/bin/bash 
      echo ECS_CLUSTER=${Cluster} >> /etc/ecs/ecs.config 
    AutoScalingGroup: 
    Type: AWS::AutoScaling::AutoScalingGroup 
    Properties: 
     MinSize: !Ref MinInstances 
     MaxSize: !Ref MaxInstances 
     LaunchConfigurationName: !Ref LaunchConfiguration 
     HealthCheckGracePeriod: 300 
     HealthCheckType: EC2 
     VPCZoneIdentifier: !Split [",", !Ref VpcSubnetIds] 
    ScaleUpPolicy: 
     Type: AWS::AutoScaling::ScalingPolicy 
     Properties: 
     AdjustmentType: ChangeInCapacity 
     AutoScalingGroupName: !Ref AutoScalingGroup 
     Cooldown: '1' 
     ScalingAdjustment: '1' 
    MemoryReservationAlarmHigh: 
     Type: AWS::CloudWatch::Alarm 
     Properties: 
     EvaluationPeriods: '2' 
     Statistic: Average 
     Threshold: '70' 
     AlarmDescription: Alarm if Cluster Memory Reservation is to high 
     Period: '60' 
     AlarmActions: 
     - Ref: ScaleUpPolicy 
     Namespace: AWS/ECS 
     Dimensions: 
     - Name: ClusterName 
      Value: !Ref Cluster 
     ComparisonOperator: GreaterThanThreshold 
     MetricName: MemoryReservation 
    ScaleDownPolicy: 
     Type: AWS::AutoScaling::ScalingPolicy 
     Properties: 
     AdjustmentType: ChangeInCapacity 
     AutoScalingGroupName: !Ref AutoScalingGroup 
     Cooldown: '1' 
     ScalingAdjustment: '-1' 
    MemoryReservationAlarmLow: 
     Type: AWS::CloudWatch::Alarm 
     Properties: 
     EvaluationPeriods: '2' 
     Statistic: Average 
     Threshold: '30' 
     AlarmDescription: Alarm if Cluster Memory Reservation is to Low 
     Period: '60' 
     AlarmActions: 
     - Ref: ScaleDownPolicy 
     Namespace: AWS/ECS 
     Dimensions: 
     - Name: ClusterName 
      Value: !Ref Cluster 
     ComparisonOperator: LessThanThreshold 
     MetricName: MemoryReservation 

這將創建一個精英集羣，一個啓動配置，自動縮放集團，以及報警基礎上，ECS MEMOR Ÿ預訂。

現在我們可以進入有趣的討論。

爲什麼我們不能根據CPU利用率進行擴展和內存預留？

簡短的回答是你完全可以但是你很可能會爲此付出很多。 EC2有一個已知屬性，當您創建一個實例時，您至少需要支付1小時，因爲部分實例小時數按整小時收費。爲什麼這是相關的，想象你有多個警報。假設您有一堆當前正在閒置的服務，並且您將填充羣集。 「CPU警報」會縮小羣集，或者「內存警報」會擴大羣集。其中一種可能會使集羣擴展到不再觸發報警的程度。冷卻時間結束後，另一個警報將撤銷它的最後一個動作，在下一次冷卻後，動作可能會重新進行。因此，創建實例然後在其他冷卻時間中重複銷燬。

在對此進行了一番思考之後，我想到的策略是使用基於CPU利用率的Application Autoscaling for ECS Services以及基於集羣的內存預留。所以如果一個服務運行的很熱，一個額外的任務將被添加來共享負載。這將緩慢填充羣集內存預留容量。當內存滿了時，集羣會擴大。當服務正在冷卻時，服務將開始關閉任務。隨着羣集上的內存預留量下降，羣集將被縮小。

CloudWatch警報的閾值可能需要根據您的任務定義進行試驗。原因在於，如果您將擴展閾值設置得過高，當內存消耗完後可能無法擴展，然後在自動縮放執行另一項任務時，會發現沒有足夠的內存可用實例在集羣中，因此無法放置其他任務。