協助改善此頁面
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要提供此使用者指南，請選擇位於每個頁面右窗格的 GitHub 上的編輯此頁面連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
機器學習 (ML) 的容量區塊可讓您指定未來日期保留 GPU 執行個體，以支援短期 ML 工作負載。如需詳細資訊，請參閱《Amazon EC2 Linux 執行個體使用者指南》中的 ML 容量區塊。
考量事項
重要
-
容量區塊僅適用於特定 Amazon EC2 執行個體類型和 AWS 區域。如需相容性資訊，請參閱《Amazon EC2 Linux 執行個體使用者指南》中的使用容量區塊先決條件。
-
容量區塊目前無法與 Karpenter 搭配使用。
-
如果您在容量保留變成作用中之前建立自我管理節點群組，請將所需的容量設定為
0。 -
為了能有足夠的時間正常耗盡節點，建議您在容量區塊保留結束前預留 30 分鐘以上，排程擴展至零。
-
為了讓您的 Pod 正常耗盡，建議您如範例步驟所述設定 AWS 節點終止處理常式。
搭配自我管理節點使用容量區塊
您可以將容量區塊與 Amazon EKS 搭配使用，藉此佈建和擴展您的自我管理節點。下列步驟提供一般範例概觀。 AWS CloudFormation 範本範例未涵蓋生產工作負載中所需的每個層面。一般而言，您也需要引導指令碼將節點加入叢集、指定 Amazon EKS 加速 AMI，以及適當的執行個體描述檔以加入叢集。如需詳細資訊，請參閱建立自我管理的 Amazon Linux 節點。
-
建立適用於工作負載的啟動範本。如需詳細資訊，請參閱「Amazon EC2 Auto Scaling 使用者指南」的使用容量區塊處理機器學習工作負載。
請確定
LaunchTemplateData包含下列項目：-
InstanceMarketOptions並將MarketType設為"capacity-block" -
CapacityReservationSpecification: CapacityReservationTarget將CapacityReservationId設定為容量區塊cr-（例如：)02168da1478b509e0 -
IamInstanceProfile將Arn設定為適用的iam-instance-profile-arn -
ImageId設定為適用的image-id -
InstanceType設定為支援容量區塊的執行個體類型 （例如：p5.48xlarge) -
SecurityGroupIds設定為適用的 IDs （例如：sg-05b1d815d1EXAMPLE) -
UserData設定為自我管理節點群組適用的使用者資料以下是 CloudFormation 範本的摘錄，該範本會建立以容量區塊為目標的啟動範本。
NodeLaunchTemplate: Type: "aws::EC2::LaunchTemplate" Properties: LaunchTemplateData: InstanceMarketOptions: MarketType: "capacity-block" CapacityReservationSpecification: CapacityReservationTarget: CapacityReservationId: "cr-02168da1478b509e0" IamInstanceProfile: Arn: iam-instance-profile-arn ImageId: image-id InstanceType: p5.48xlarge KeyName: key-name SecurityGroupIds: - sg-05b1d815d1EXAMPLE UserData: user-data由於容量區塊為區域性，因此您必須在進行保留的可用區域中傳遞子網路。
-
-
使用啟動範本建立自我管理節點群組。如果您在容量保留變成作用中之前執行此操作，請將所需的容量設定為
0。建立節點群組時，請確定您只為保留容量的可用區域指定個別子網路。以下是範例 CloudFormation 範本，您可以在建立適用於工作負載的範例 CloudFormation 範本時參考。此範例會取得上一個步驟中顯示之
AWS::Amazon EC2::LaunchTemplate資源Version的LaunchTemplateId和 。這個範例也會取得在相同範本中其他位置宣告的DesiredCapacity、MaxSize、MinSize和VPCZoneIdentifier值。NodeGroup: Type: "AWS::AutoScaling::AutoScalingGroup" Properties: DesiredCapacity: !Ref NodeAutoScalingGroupDesiredCapacity LaunchTemplate: LaunchTemplateId: !Ref NodeLaunchTemplate Version: !GetAtt NodeLaunchTemplate.LatestVersionNumber MaxSize: !Ref NodeAutoScalingGroupMaxSize MinSize: !Ref NodeAutoScalingGroupMinSize VPCZoneIdentifier: !Ref Subnets Tags: - Key: Name PropagateAtLaunch: true Value: !Sub ${ClusterName}-${NodeGroupName}-Node - Key: !Sub kubernetes.io/cluster/${ClusterName} PropagateAtLaunch: true Value: owned -
成功建立節點群組之後，請務必記錄所建立節點群組的
NodeInstanceRole。您需要此項目，以確保節點群組擴展時，新節點會加入叢集，且 Kubernetes 能夠辨識節點。如需詳細資訊，請參閱建立自我管理 Amazon Linux 節點中 AWS Management Console 的指示。 -
建議您根據容量區塊的保留時間，為 Auto Scaling 群組建立排程擴展政策。如需詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的為 Amazon EC2 Auto Scaling 排程擴展。
在容量區塊結束時間的 30 分鐘前，您保留的所有執行個體都可以使用。屆時仍在執行的執行個體將會開始終止。為了能有足夠的時間正常耗盡節點，建議您在容量區塊保留結束前預留 30 分鐘以上，排程擴展至零。
如果您想要在容量保留變成 時改為手動擴展
Active，則需要在容量區塊保留的開始時間更新 Auto Scaling 群組所需的容量。然後，您還需要在容量區塊保留結束前預留 30 分鐘以上手動縮減規模。 -
節點群組現在已準備好排程工作負載和 Pod。
-
為了讓您的 Pod 正常耗盡，建議您設定 AWS 節點終止處理常式。此處理常式將能夠使用 EventBridge 監看來自 Amazon EC2 Auto Scaling 的「ASG 縮減」生命週期事件，並允許 Kubernetes 控制平面在執行個體無法使用之前採取必要的動作。否則，您的 Pod 和 Kubernetes 物件將卡在待定狀態。如需詳細資訊，請參閱 GitHub 上的 AWS 節點終止處理常式
。 如果您未設定節點終止處理常式，建議您在達到 30 分鐘的時段之前開始手動耗盡 Pod，以便有足夠的時間正常耗盡。
