Azure 容器应用常见问题解答 (FAQ)

否，无权访问 Kubernetes API。

是的。

有关详细信息，请参阅计费页。

是的。 使用 Azure CLI，运行 az containerapp github-action -h 来查看选项。 使用 Azure 门户，转到容器应用下的“持续部署”窗口。

Azure 容器应用会将 URL 解码，以保护应用免遭 URL 混淆攻击。 包含编码部分的请求 URL（例如 http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123）将作为 http://mysite.com/archive/http%3A/mysite.com/archive/123 发送到应用。

对于纯消耗环境，不支持快速路由，但支持按如下方式配置的有限 UDR。 UDR 配置必须具有为 Azure.<REGION_NAME> 服务标记配置的路由，且“下一个跃点”为“Internet”。 此外，必须配置 NSG 文档中的规则，以使纯消耗环境正常运行。 这些限制不适用于工作负荷配置文件。对于全功能 UDR 和 ExpressRoute 支持，请使用工作负荷配置文件环境。

Azure 容器应用不会将客户数据移动或存储到部署区域之外。

在 Azure 门户中请求增加配额，并选择 Azure 容器应用作为提供程序。

在请求增加配额时，请记住以下事项：

• 缩放应用和环境：可以增加许多不同的配额。 使用这些说明来帮助确定你的需求：

  • 增加每个环境的应用和核心：允许在环境和/或更密集的应用中运行更多应用。 如果工作负载可以部署在同一网络和安全边界内，则建议使用。
  • 增加环境：如果工作负载需要网络或安全边界，则建议使用。 注意：如果请求涉及增加环境级别配额，则可能需要详细的业务上下文。 当你请求对区域环境配额进行更改时，应该请求对全局环境配额进行相应的更改。

• 区域：对增加请求的审批因 Azure 区域中可用的计算容量而异。

• 特定计算要求：平台支持每个容器应用 4 GB。 内存限制替代值是按具体情况评估的。

• 缩放的业务原因：如果平台限制阻碍了工作负载需求，则可能有资格请求增加配额。 缩放限制替代值是按具体情况评估的。

每个 Dapr 功能都会进行全面评估，以确保它对在 Azure 容器应用环境中运行微服务的客户产生积极影响，同时提供最佳体验。

Dapr 的 alpha API 的可用性没有保证且不受 Microsoft 支持。

尽管完全支持第 1 层组件，但也会尽最大努力支持第 2 层组件。 了解详细信息。

Dapr 的典型发布时间线是在 Dapr OSS 发布后最多六周。 只有在经过严格的测试后，Azure 容器应用中才会提供最新的 Dapr 版本。 向所有区域推出可能需要两周或更长的时间。

可以通过 Azure 容器应用 GitHub 存储库提交功能请求。 请确保在功能请求标题中包含“Dapr”。

无 Docker 部署让你无需在代码中定义 Dockerfile 即可部署应用程序。 相反，容器应用云生成功能使用 Buildpack 将你本地计算机上的源代码转换为容器映像。 此选项使用 Azure 容器应用默认注册表。

你遇到了一项无 Docker 部署的已知问题。 重试可能会解决此问题。 如果遇到此问题，请开启 GitHub 问题，以便我们的团队可以进行调查。

需要在 Azure 容器应用上为所有 .NET 应用启用数据保护。 有关详细信息，请参阅在 Azure 容器应用上部署和缩放 ASP.NET Core 应用。

容器应用支持四个 LTS JDK 版本：JDK 8、JDK 11、JDK 17 和 JDK 21。 对于源代码生成，默认版本为 JDK 17。 对于 JAR 文件生成，JDK 版本是从 JAR 中的文件位置 META-INF\MANIFEST.MF 读取的，但如果指定的版本不可用，则使用默认的 JDK 版本 17。

可以配置 JDK 版本以通过生成环境变量替代默认版本。

Maven

可以通过生成环境变量自定义 Java 映像生成。

将 containerapp up 与无 Docker 代码库结合使用时，请使用 --location 参数，以便应用程序在美国东部以外的位置运行。