對 Azure 容器執行個體中的常見問題進行疑難排解

本文說明如何排解管理或部署容器到 Azure 容器執行個體的常見問題。另見常見問題。

如果你需要更多支援，請參考 Azure 入口網站中的「幫助+支援」選項。

容器群組部署期間的問題

命名慣例

當你定義容器規格時，某些參數需要遵守命名限制。下表顯示容器群組屬性的具體要求。欲了解更多資訊，請參閱 Azure 架構中心的命名慣例及 Azure 資源的命名規則與限制。

Scope	長度	大小寫	有效字元	建議模式	範例
容器名稱¹	1-63	小寫	英數字元，以及除第一個或最後一個字元外可出現在任何位置的連字號	`<name>-<role>-container<number>`	`web-batch-container1`
貨櫃港口	介於1至65535之間	Integer	整數介於1到65535之間	`<port-number>`	`443`
DNS 名稱標籤	5-63	不區分大小寫	英文字母、數字，以及除第一個或最後一個字元外可出現在任何位置的連字號	`<name>`	`frontend-site1`
環境變數	1-63	不區分大小寫	字母數字，且除首尾字元外，其他處皆為（_）	`<name>`	`MY_VARIABLE`
磁碟區名稱	5-63	小寫	英數字元，以及可出現在除第一個或最後一個字元之外任何位置的連字號。不可包含連續兩個連字號。	`<name>`	`batch-output-volume`

¹當容器群組名稱未與容器執行個體分開指定時，也適用此限制，例如使用 az container create 命令部署作業。

映像檔的作業系統版本不受支援

如果你指定了 Azure 容器執行個體不支援的映像檔，OsVersionNotSupported就會回傳錯誤。錯誤內容如下，其中 {0} 是你嘗試部署的映像檔名稱：

{
  "error": {
    "code": "OsVersionNotSupported",
    "message": "The OS version of image '{0}' is not supported."
  }
}

此錯誤最常見於部署以半年通道 1709 或 1803 版為基礎的 Windows 映像時，因為這些版本不受支援。關於 Azure 容器執行個體中支援的 Windows 映像，請參閱常見問題。

無法拉取圖片

如果 Azure 容器執行個體一開始無法拉取你的映像檔，它會重新嘗試以節省時間。如果映像拉取操作持續失敗，ACI 最終會失敗部署，屆時可能會出現 Failed to pull image 錯誤。

要解決這個問題，請刪除容器實例並重新嘗試部署。確認該映像檔存在登錄檔，且你正確輸入了映像檔名稱。

Important

ACI 僅支援在使用 Azure Container Registry（ACR）搭配私有端點與管理身份時，從私有登錄檔（沒有公共 IP 的註冊檔）拉取映像檔。即使 ACI 與登錄檔之間設定了虛擬網路連線，也不支援從非 ACR 私有登錄檔拉取映像檔。如果你需要使用私人登錄檔，請將映像檔遷移到 ACR，並設定一個有管理身份的私有端點。欲了解更多資訊，請參閱虛擬網路情境與資源 - 不支援的網路情境。

若無法拉取影像，az container show 的輸出會顯示以下事件：

"events": [
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "Pulling",
    "type": "Normal"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:19+00:00",
    "lastTimestamp": "2017-12-21T22:57:00+00:00",
    "message": "Failed to pull image \"mcr.microsoft.com/azuredocs/aci-hellowrld\": rpc error: code 2 desc Error: image t/aci-hellowrld:latest not found",
    "name": "Failed",
    "type": "Warning"
  },
  {
    "count": 3,
    "firstTimestamp": "2017-12-21T22:56:20+00:00",
    "lastTimestamp": "2017-12-21T22:57:16+00:00",
    "message": "Back-off pulling image \"mcr.microsoft.com/azuredocs/aci-hellowrld\"",
    "name": "BackOff",
    "type": "Normal"
  }
],

資源無法使用錯誤

由於 Azure 中區域資源負載不同，嘗試部署容器實例時可能會收到以下錯誤：

The requested resource with 'x' CPU and 'y.z' GB memory is not available in the location 'example region' at this moment. Please retry with a different resource request or in another location.

這個錯誤表示由於你嘗試部署的區域負載過重，容器指定的資源當時無法分配。請採用以下一項或多項緩解措施來協助解決您的問題。

請確認你的容器部署設定符合 Azure 容器執行個體區域可用性中定義的參數
為容器指定較低的 CPU 和記憶體設定值
部署到不同的 Azure 區域
稍後部署

容器群組執行期間的問題

容器在沒有明確使用者操作的情況下發生了一次單獨重啟

容器群組可能會在沒有明確使用者輸入的情況下重新啟動，其原因大致可分為兩大類。首先，容器可能會因應用程式程序崩潰而重啟。 ACI 服務建議應用可觀察性解決方案，如 Application Insights SDK、容器群組指標及容器群組日誌，以找出應用程式出現問題的原因。其次，客戶可能會因維護作業而遇到由 ACI 基礎結構觸發的重新啟動。為了提升應用程式的可用性，可以在一個入口元件（如 Application Gateway 或 Traffic Manager）背後運行多個容器群組。

容器會持續退出和重啟（沒有長時間執行的程序）

容器群組預設的重啟政策是 「永遠」，因此容器群組中的容器在完成後都會重新啟動。如果你打算執行任務型容器，可能需要把這個設定改成 OnFailure 或 Never 。如果你設定 OnFailure ，卻仍看到持續重啟，可能是容器中執行的應用程式或腳本有問題。

附註

Never重新啟動政策只會在容器成功退出且代碼為 0 時才會阻止重新啟動。如果容器以非零的出口代碼退出，平台仍可能重新啟動它。欲了解更多資訊，請參閱「非零退出碼的重新啟動行為」。

當您執行沒有長時間執行的處理程序的容器群組時，若使用 Ubuntu 或 Alpine 這類映像，可能會看到容器群組反覆結束並重新啟動。透過 EXEC 連線無法運作，因為容器沒有任何程序來維持它的存活狀態。為了解決這個問題，可以在你的容器群組部署中加入像以下範例的 start 指令，以保持容器運作。

## Deploying a Linux container
az container create -g MyResourceGroup --name myapp --image ubuntu --command-line "tail -f /dev/null"

## Deploying a Windows container
az container create -g myResourceGroup --name mywindowsapp --os-type Windows --image mcr.microsoft.com/windows/servercore:ltsc2019
 --command-line "ping -t localhost"

容器執行個體 API 與 Azure 入口網站包含一個restartCount屬性。要檢查容器的重啟次數，你可以在 Azure CLI 中使用 az container show 指令。在以下為簡潔而截斷的輸出範例中，你可以看到輸出末尾的 restartCount 特性。

...
 "events": [
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:06+00:00",
     "lastTimestamp": "2017-11-13T21:20:06+00:00",
     "message": "Pulling: pulling image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Pulled: Successfully pulled image \"myregistry.azurecr.io/aci-tutorial-app:v1\"",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Created: Created container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   },
   {
     "count": 1,
     "firstTimestamp": "2017-11-13T21:20:14+00:00",
     "lastTimestamp": "2017-11-13T21:20:14+00:00",
     "message": "Started: Started container with id bf25a6ac73a925687cafcec792c9e3723b0776f683d8d1402b20cc9fb5f66a10",
     "type": "Normal"
   }
 ],
 "previousState": null,
 "restartCount": 0
...
}

附註

大多數 Linux 發行版的容器映像檔會將 shell（如 bash）設為預設指令。由於 shell 本身並非長期服務，這些容器在預設的 Always restart 政策設定時會立即退出並陷入重啟循環。

容器啟動時間很長

影響 Azure 容器執行個體容器啟動時間的三大主要因素是：

影像尺寸
影像位置
快取影像

Windows 映像尚有其他注意事項。

圖像尺寸

如果你的容器啟動時間很長，但最終成功了，先從容器圖片的大小開始。因為 Azure 容器執行個體會按需拉取你的容器映像，所以你看到的啟動時間直接與它的大小有關。

你可以透過 docker images Docker CLI 中的指令查看容器映像的大小：

docker images

REPOSITORY                                    TAG       IMAGE ID        CREATED          SIZE
mcr.microsoft.com/azuredocs/aci-helloworld    latest    7367f3256b41    15 months ago    67.6MB

保持圖片大小小的關鍵是確保最終影像中不包含執行時不需要的內容。其中一種做法是使用多階段建構。多階段建置讓你很容易確保最終映像只包含應用程式所需的工件，而非建置時所需的額外內容。

映像位置

另一種減少映像拉取對容器啟動時間影響的方法是，將容器映像放在你打算部署容器實例的同一區域的 Azure Container Registry 中。這縮短了容器映像所需的網路路徑，顯著縮短下載時間。

快取影像

Azure 容器執行個體採用快取機制，幫助加速基於常見 Windows 基礎映像（包括nanoserver:1809、、 servercore:ltsc2019和 servercore:1809）建置的容器啟動時間。 ubuntu:1604 和 alpine:3.6 等常用的 Linux 映像也會被快取。無論是 Windows 還是 Linux 映像，都避免使用該latest標籤。請參閱 Container Registry 的影像標籤最佳實務以獲得指引。若要取得快取映像檔和標籤的最新清單，請使用 List Cached Images API。

附註

在 Azure 容器執行個體中使用基於 Windows Server 2019 的映像仍處於預覽階段。

Windows 容器的網路準備速度變慢

在初始建立時，Windows 容器可能長達 30 秒（或極少數情況下更久）沒有進出連線。如果你的容器應用程式需要網路連線，請加入延遲與重試邏輯，讓 30 秒建立網路連線。初始設定完成後，容器網路應該會正常恢復。

無法連接底層的 Docker API，也無法執行特權容器

Azure 容器執行個體不會直接開放對底層容器群組基礎設施的存取權限。這包括存取容器執行時、協調技術，以及執行特權容器操作。想了解 ACI 支援哪些操作，請參考 REST 參考文件。如果缺少什麼，請在 ACI 回饋論壇提出申請。

容器群組的 IP 位址可能因埠口不匹配而無法存取

Azure 容器執行個體尚未支援像一般 Docker 配置那樣的埠映射。如果你發現容器群組的 IP 位址在理應可存取時卻無法存取，請確認你已將容器映像設定為接聽與你在容器群組中使用 ports 屬性公開的連接埠相同的連接埠。

如果您想確認 Azure 容器執行個體是否能接聽您在容器映像中設定的連接埠，可以測試部署會公開該連接埠的 aci-helloworld 映像。另外也要執行 aci-helloworld 應用程式，讓它在該連接埠上監聽。 aci-helloworld 接受一個可選的環境變數 PORT 來覆蓋它所監聽的預設 80 埠。例如，要測試埠 9000，建立容器群組時設定環境變數：

設定容器群組來暴露埠 9000，並將埠號當作環境變數的值傳遞。範例格式是針對 Bash shell 設計的。如果你偏好其他 shell，例如 PowerShell 或命令提示字元，則需要相應調整變數指派。
```
az container create --resource-group myResourceGroup \
--name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld \
--ip-address Public --ports 9000 \
--environment-variables 'PORT'='9000'
```
在指令輸出 az container create中找到容器群組的 IP 位址。尋找 ip 的值。
容器成功配置後，請在瀏覽器中瀏覽容器應用程式的 IP 位址與埠號，例如： 192.0.2.0:9000。

你應該會看到網頁應用程式顯示的「Welcome to Azure 容器執行個體！」訊息。

使用完容器後，請使用 az container delete 指令將其移除：

az container delete --resource-group myResourceGroup --name mycontainer

機密容器群組部署期間的問題

使用自訂 CCE 政策時的政策錯誤

自訂的 CCE 政策必須由 Azure CLI confcom 擴充功能產生。在產生政策前，請確保你 ARM 範本中指定的所有屬性皆有效，且符合你預期在機密計算政策中所代表的條件。需要驗證的屬性包括容器映像、環境變數、卷掛載和容器指令。

政策中缺少雜湊值

Azure CLI confcom 擴充功能會使用你本地機器上的快取映像檔，這些影像可能與遠端可用的影像不符，導致政策驗證時出現層層不匹配。請確保移除所有舊的映像檔，並將最新的容器映像檔拉回本地環境。一旦確定你擁有最新的 SHA 後，你應該重新建立 CCE 政策。

程序/容器終止，出口代碼：139

此退出碼是因為 Ubuntu 22.04 版本的基礎映像限制而產生。建議使用不同的底鏡像來解決這個問題。

貨櫃出口代碼

當 Azure 容器執行個體中的容器終止時，平台會回報一個退出代碼，說明程序停止的原因。你可以透過使用 az container show 指令檢查容器事件，或在 Azure 入口網站的容器>事件中查看出口代碼。

下表說明您可能遇到的常見出口代碼：

退出代碼	Description
0	該過程順利完成。沒有發生錯誤。
1	該流程因一般申請錯誤而終止。請查看你的申請日誌以獲得更多細節。
137	該程序被強制終止（SIGKILL）。此狀況通常發生在容器超過記憶體限制時。考慮增加容器的記憶體配置。
139	該程序遇到分段錯誤（SIGSEGV）。此錯誤可能由基礎映像限制引起，例如 Ubuntu 22.04。請嘗試使用不同的基底映像檔。
7147	平台優雅地透過發送終止訊號關閉了貨櫃。此程式碼與容器事件中的「正在終止容器（由平台起始）」訊息相對應。
7148	平台強行終止貨櫃。此狀況通常表示容器在收到初始終止訊號後未能及時回應。此程式碼也對應容器事件中的「Killing container（平台啟動）」訊息。

平台發起的終止（結束代碼 7147 和 7148）

出口代碼7147和7148是來自底層基礎設施的月台出口代碼。你可能不一定會直接在容器細節中看到這些代碼，但它們會和容器事件中出現的「殺死容器（平台啟動）」訊息相符。平台發起終止的常見原因包括：

基礎設施維護：平台在例行維護或負載平衡中重新定位您的容器。
資源限制：底層主機需要回收資源。
平台更新：基礎設施已更新，需要容器重啟。

這類中止情況在雲端環境中是可以預期的。為了提升應用程式的可用性，可以在一個入口元件（如 Application Gateway 或 Traffic Manager）背後運行多個容器群組。

欲了解更多關於平台發起終止的資訊，請參閱使用 Service Fabric 診斷常見程式碼套件錯誤。

下一步

學習如何取得容器日誌和事件，以協助除錯你的容器。

意見反應

此頁面對您有幫助嗎？

上次更新時間： 2026-07-26