本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
App Mesh 擴展疑難排解
重要
支援終止通知：2026 年 9 月 30 日， AWS 將停止支援 AWS App Mesh。2026 年 9 月 30 日之後，您將無法再存取 AWS App Mesh 主控台或 AWS App Mesh 資源。如需詳細資訊，請參閱此部落格文章從 遷移 AWS App Mesh 至 Amazon ECS Service Connect
本主題詳細說明您在 App Mesh 擴展時可能遇到的常見問題。
虛擬節點/虛擬閘道擴展超過 50 個複本時，連線失敗且容器運作狀態檢查失敗
徵狀
當您為虛擬節點/虛擬閘道擴展 Amazon ECS 任務、Kubernetes Pod 或 Amazon EC2 執行個體等複本數量超過 50 時，Envoy 容器運作狀態檢查會開始失敗。傳送流量至虛擬節點/虛擬閘道的下游應用程式會開始看到 HTTP 狀態碼 的請求失敗503。
Resolution
App Mesh 每個虛擬節點/虛擬閘道的 Envoy 數量的預設配額為 50。當執行中的 Envoys 數量超過此配額時，新的和目前正在執行的 Envoys 無法以 gRPC 狀態碼 8() 連線至 App Mesh 的 Envoy 管理服務RESOURCE_EXHAUSTED。您可以提高此配額。如需詳細資訊，請參閱App Mesh 服務配額。
如果您的問題仍未解決，請考慮開啟 GitHub 問題
當虛擬服務後端水平向外擴展或向內擴展503時，請求會失敗
徵狀
當後端虛擬服務水平向外擴展或向內擴展時，來自下游應用程式的請求會失敗，並顯示HTTP 503狀態碼。
Resolution
App Mesh 建議數種方法來緩解故障案例，同時水平擴展應用程式。如需如何防止這些失敗的詳細資訊，請參閱 App Mesh 最佳實務。
如果您的問題仍未解決，請考慮開啟 GitHub 問題
在負載增加的情況下，Envoy 容器因隔離故障而當機
徵狀
在高流量負載下，Envoy 代理會因為分段錯誤 (Linux 結束碼 ) 而當機139。Envoy 程序日誌包含如下所示的陳述式。
Caught Segmentation fault, suspect faulting address 0x0"Resolution
Envoy 代理可能已違反作業系統的預設 nofile ulimit，即程序一次可以開啟的檔案數量限制。此違規是由於流量導致更多連線，這會消耗額外的作業系統通訊端。若要解決此問題，請增加主機作業系統上的 ulimit nofile 值。如果您使用的是 Amazon ECS，可以透過任務定義的資源限制設定上的 Ulimit 設定來變更此限制。 https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definition_limits
如果您的問題仍未解決，請考慮開啟 GitHub 問題
預設資源的增加不會反映在服務限制中
徵狀
增加 App Mesh 資源的預設限制後，當您查看服務限制時，不會反映新值。
Resolution
雖然目前未顯示新的限制，但客戶仍然可以執行這些限制。
如果您的問題仍未解決，請考慮開啟 GitHub 問題
應用程式因為大量的運作狀態檢查呼叫而當機。
徵狀
啟用虛擬節點的作用中運作狀態檢查後，運作狀態檢查呼叫的數量會增加。應用程式由於對應用程式進行的運作狀態檢查呼叫量大幅增加而當機。
Resolution
啟用作用中運作狀態檢查時，下游 （用戶端） 的每個 Envoy 端點都會將運作狀態請求傳送至上游叢集 （伺服器） 的每個端點，以做出路由決策。因此，運作狀態檢查請求的總數為 number of client Envoys * number of server Envoys * active health check frequency。
若要解決此問題，請修改運作狀態檢查探查的頻率，這會降低運作狀態檢查探查的總量。除了主動運作狀態檢查之外，App Mesh 允許將極端值偵測設定為被動運作狀態檢查的方法。使用極端值偵測來設定何時根據連續5xx回應移除特定主機。
如果您的問題仍未解決，請考慮開啟 GitHub 問題
