有关 Azure 容器实例的常见问题解答

可在 Azure 容器实例上部署的容器映像的最大大小为 15 GB。 根据部署时的确切可用性，你也许可以部署更大的映像，但不能保证映像大小更大。

容器映像的大小会影响部署所需的时间，因此，一般情况下，我们会尽可能地保留较小的容器映像。

由于部署速度的主要决定因素之一是映像大小，因此请找到减小大小的办法。 删除不需要的层，或者减小映像中的层大小（选择较精简的基础 OS 映像）。 例如，如果运行 Linux 容器，请考虑使用 Alpine 作为基础映像，而不是使用完整的 Ubuntu Server。 同样，对于 Windows 容器，请尽可能地使用 Nano Server 基础映像。

你还应查看 Azure 容器映像中预缓存映像的列表（通过列出缓存的映像 API 获取）。 你也许可以切换出某个预缓存映像的映像层。

有关如何减少容器启动时间，请参阅更详细的指南。

• Nano Server：sac2016、10.0.14393.3568 或更新版本
• Windows Server Core：ltsc2016、10.0.14393.3568 或更新版本

• Nano Server：1809、10.0.17763.1040 或更新版本
• Windows Server Core：ltsc2019、1809、10.0.17763.1040 或更新版本
• Windows：1809、10.0.17763.1040 或更新版本

使用符合要求的最小映像。 对于 Linux，可以使用 runtime-alpine .NET Core 映像，从 .NET Core 2.1 版本开始就已支持此映像。 对于 Windows，如果使用完整的 .NET Framework，则需要使用 Windows Server Core 映像（仅限运行时的映像，例如 4.7.2-windowsservercore-ltsc2016）。 仅限运行时的映像较小，但不支持需要 .NET SDK 的工作负载。

ACI 支持从 ACR 和其他第三方容器注册表（如 DockerHub）拉取映像。 ACI 支持从 ACR 和其他第三方 OCI 兼容容器注册表（如 DockerHub）拉取映像，而这些注册表具有向 Internet 公开的终结点。

1. 确定当前正在使用的 Windows 基础映像。

   如果要直接从 Microsoft 容器注册表 (MCR) 进行拉取，则该映像名称是基础映像。

   如果使用的是专用注册表，则需要查看 Dockerfile 来标识基础映像，该映像将在“FROM”行后进行声明。

2. 从 Windows Server 2019 中选择要使用的新基础映像。 下面是 Azure 容器实例上常用 Windows Server 2016 映像的一些示例，以及有关 Windows Server 2019 替换映像的建议。

   Windows Server 2016 映像	建议的 Windows Server 2019 映像
   mcr.microsoft.com/windows/servercore/iis	mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
   mcr.microsoft.com/windows/servercore:ltsc2016	mcr.microsoft.com/windows/servercore:ltsc2019

   若要了解详细信息，请阅读映像发现。

   备注

   若要获得有关如何选择新基础映像的帮助，请创建 Azure 支持票证。

3. 按照有关如何在 Azure 容器实例中更新容器的操作指南操作，更新 ACI 容器组以使用新的基础映像。

   如果将 MCR 用于容器注册表，则可将 MCR 映像名称直接传递到容器组映像参数中。

   如果使用专用容器注册表，请按照将容器升级到 Windows 操作系统的新版本中的步骤操作。 确保更新容器组的映像注册表参数（如果更改了这些参数）。

这实际上取决于工作负荷。 请从较小的数量着手，并测试容器的性能如何。 监视 CPU 和内存资源用量，然后根据在容器中部署的进程类型增加核心或内存。

另外，请务必检查所部署到的区域的资源可用性，以确定每个容器组的可用 CPU 核心数和内存上限。

Azure 容器实例旨在用作无服务器按需容器服务，因此，我们希望你专注于开发容器，而不用考虑基础结构！ 对于那些有好奇心的或者想要比较性能的客户，可以在采用各种 SKU 的 Azure VM 集（主要是 F 和 D 系列）上运行 ACI。 我们会持续开发和优化服务，预计这种情况将来会改变。

在某些情况下是可以提高的。 有关当前的配额以及可以请求提高的限制，请参阅配额和限制一文。

还不可以。 目前这些数字是容器组的上限。 如有具体的要求和请求，请联系 Azure 支持部门。

此处发布了当前推出的区域。 如果你在特定的区域需要满足某项要求，请联系 Azure 支持部门。

目前，容器或容器组不可缩放。 如果需要运行更多实例，请使用我们的 API 进行自动化，并创建更多请求以在服务中创建容器组。

可以在所选 Azure 虚拟网络中部署容器组，并将专用 IP 委托给容器组，以在 VNet 中跨 Azure 资源路由流量。 有关 Azure 容器实例的网络方案和限制，请参阅虚拟网络方案和资源。

是的，ACI 服务保留以下服务功能端口：22、1025-1027、3389-3399、9999、19000、19080、19390、19100、20000-30000、49152-65534。 请避免在容器组定义中使用这些端口。

容器组 IP 地址在创建或删除后可能会发生更改。 建议不要让应用程序代码依赖于容器组的 IP 地址。 如果想维护静态 IP 地址，还建议使用 NAT 网关或应用程序网关。

计算的容器组持续时间从我们开始提取你的第一个容器映像（对于新部署）或重启容器组（如果已部署）开始，到容器组停止为止。 请参阅容器实例定价中的详细信息。

停止整个容器组后，计量器将停止运行。 只要容器组中的容器正在运行，我们就会保留资源，以防需要再次启动容器。

机密计算是由机密计算联盟 (CCC) 定义的一个行业术语。CCC 是专业定义机密计算并加速其采用的基金会。 CCC 定义机密计算，如下所示：通过在基于硬件的受信任执行环境 (TEE) 中执行计算来保护使用中的数据。 ACI 机密容器引入了基于硬件的保护、代码完整性和受信任执行环境 (TEE) 验证。 机密容器应用最新的机密计算硬件，使客户无需进行任何修改即可部署其现有的应用程序，同时可利用基于硬件的数据保护。 代码完整性和 TEE 验证是通过机密计算强制策略的证明来实现的，该策略在部署时会附加到容器组。 如果容器组的任何属性与机密计算强制策略的属性不同，则环境将无法启动，以确保 TEE 不会遭到入侵。

机密容器可用于各种弹性工作负载，尤其适用于需要强大数据保护保证的工作负载。 这些工作负载的一些示例包括机器学习工作负载，后者利用包含个人数据的数据集或被视为知识产权的算法。 医疗保健客户可以使用它来分析患者数据和开展相关研究。 金融服务客户可以使用它进行信用分析风险计算和投资组合平衡。

可以通过 Azure CLI 使用 confcom 扩展来生成机密计算强制策略。 有关详细信息，请参阅 confcom 扩展。

机密容器不支持基于 GPU 的 ACI 容器部署、Windows 容器、可用性区域和专用实例。

在公开预览期间，Azure 容器实例上的机密容器仅在选定区域中可用。 此处发布了当前推出的区域。

与标准 SKU 容器组相比，Azure 容器实例上的机密容器确实需要额外付费。 有关详细信息，请参阅定价页。

ACI 现成容器是一项新功能，它支持客户在未使用的 Azure 容量上运行可中断的容器化工作负载，与常规优先级 ACI 容器相比，价格折扣最高为 70%。

当 Azure 的剩余容量不足且客户按每秒内存/核心使用量计费时，可能会抢占 ACI 现成容器。 借助 ACI 现成容器，现在可以运行容器化工作负载，例如批处理、蒙特卡罗模拟、开发/测试工作负载和可并行化脱机工作负载，这些工作负载可以容忍 Azure 上的中断，而成本只是传统 ACI 定价的一小部分。 此产品/服务面向想要运行无严格可用性要求的可中断工作负载的客户。

现成容器不支持基于 GPU 的 ACI 容器部署、可用性区域、对具有公共 IP 的 ACI 部署的支持以及具有专用 IP 的自定义虚拟网络后的 ACI 部署。

所有客户的默认配额为 10 个 vCPU 核心和 10 个容器组。

当系统要求填写请求的详细信息时，客户可以通过选择为 ACI 现成容器产品/服务添加的问题类型“服务和订阅限制（配额）”和新配额类型“StandardSpotCores”来提交支持请求，以增加现成容器的容量。

在公开预览期间，Azure 容器实例 (ACI) 现成容器仅在所选区域中可用。 有关详细信息，请参阅资源和区域可用性。

ACI 现成容器以折扣价格提供，并在常规优先级 ACI 容器基础上提供最高 70% 的折扣。 每个区域每月的折扣会有所不同。 有关详细信息，请参阅定价页。

后续步骤

• 详细了解 Azure 容器实例。
• 排查 Azure 容器实例中的常见问题