Amazon ECS 服務節流邏輯

Amazon ECS 服務排程器包含的邏輯，可在任務重複啟動失敗的情況下，針對服務任務啟動的頻率進行調節。

如果服務的工作重複無法進入狀RUNNING態 (從STOPPED狀態直接進行)，則後續重新啟動嘗試之間的時間會逐漸增加，最多可達 27 分鐘。PENDING此最長期間將來可能會有所變更。此行為能降低失敗的任務對 Amazon ECS 叢集資源或 Fargate 基礎設施成本所造成的影響。如果您的服務啟動了限流邏輯，您會收到以下的服務事件訊息：

(service service-name) is unable to consistently start tasks successfully.

Amazon ECS 永遠不會阻止失敗的服務重試。除了增加重新啟動的時間間隔，它也不會嘗試對其進行任何修改。服務限流邏輯沒有任何可供使用者調校的參數。

如果您更新服務使用新的任務定義，您的服務就會立即回復到正常、非調節的狀態。如需詳細資訊，請參閱 使用主控台更新 Amazon ECS 服務。

以下是啟動此邏輯的一些常見原因。我們建議您採取手動動作來解決此問題：

• 您的叢集中缺乏裝載任務的資源，例如連接埠、記憶體或 CPU 單位。在這種情況下，您也會看到「資源不足服務事件訊息」。

• Amazon ECS 容器代理程式無法提取您的任務 Docker 映像檔。這可能是因為錯誤的容器映像名稱、映像、或標籤，或缺乏私有登錄檔身分驗證或許可。在這種情況下，您也會在「CannotPullContainerError停止的任務錯誤」中看到 。

• 您的容器執行個體磁碟空間不足以建立容器。在這種情況下，您也會在「CannotCreateContainerError停止的任務錯誤」中看到 。如需詳細資訊，請參閱 Amazon ECS 中的泊塢視API error (500): devmapper窗疑難排解。

重要

到達 RUNNING 狀態之後停止的任務不會啟動限流邏輯或相關聯的服務事件訊息。例如，假設服務的 Elastic Load Balancing 運作狀態檢查失敗導致任務標示為運作狀態不佳，而 Amazon ECS 取消註冊並停止了任務。這樣並不會觸發限流。即使任務的容器指令立即以非零結束代碼結束，任務仍已轉換為 RUNNING 狀態。因為指令錯誤而立即失敗的任務不會觸發限流或服務事件訊息。