你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure 容器应用 中的 Azure Functions 概述

Azure Functions 在 Azure 容器应用 上提供一个完全托管的无服务器托管环境，结合了 Azure Functions 的事件驱动功能和 Container Apps 的功能。 这些功能包括基于 Kubernetes 的编排、由 Kubernetes 事件驱动自动扩展（KEDA）驱动的内置自动扩展、DAPR 集成、GPU 工作负载支持、边车支持、虚拟网络（VNet）连接以及版本管理。

当你希望函数与其他容器化应用（如微服务、API 或网站）并行运行时，这种方法非常有用。 当你需要自定义依赖或想扩展到零以降低成本时，将函数应用容器化也能提供帮助。 对于像AI推理这样计算密集型任务，Container Apps支持通过无服务器GPU和专用工作负载配置文件的GPU托管。

作为 Azure 容器应用 的一个集成功能，你可以通过调用 Microsoft.App Resource provider 和设置kind=functionappaz containerapp create，直接将 Azure Functions 容器镜像部署到 Azure 容器应用。 以这种方式创建的应用可以访问所有Azure 容器应用功能。 在 Azure 门户中，设置时选择“Optimize for Azure Functions”选项。 更多信息请参见 部署与设置。

主要优势

容器应用托管模型基于容器化工作负荷的灵活性和Azure Functions的事件驱动性质。 它提供了以下主要优势：

下表帮助你比较容器应用功能与 灵活消费计划的功能。

功能 / 特点 容器应用 弹性消耗计划
缩放到零 ✅ 是（通过 KEDA） ✅ 是
最大横向扩展 1,000 （默认值 10，可配置） 1,000
Always on 实例 ✅ 是（通过 minReplicas） ✅ 是（通过始终就绪的实例）
VNet 集成 ✅ 是 ✅ 是
自定义容器支持 ✅ 是的（自带图像） ❌ 有限（没有自带容器）
GPU 支持 ✅ 是（通过无服务器 GPU 专用工作负载配置文件） ❌ 否
内置功能 容器应用功能支持。 例如，KEDA、Dapr、多修订、mTLS、sidecar、入口控制等 仅限函数的功能
计费模式 容器应用定价：消耗计划（vCPU、内存、请求）和专用计划（基于工作负载配置文件） 执行时间 + 始终就绪实例

有关容器应用上的 Functions 与 Flex 消耗计划以及所有其他计划和托管类型的完整比较，请参阅 Functions 缩放和托管选项。

方案

容器应用上的Azure Functions非常适合各种用例，尤其是在需要事件驱动执行、容器灵活性或与其他服务的安全集成时：

  • 业务线 API：将自定义库、包和 API 与 Azure Functions 一起打包，用于业务线的应用程序。
  • 迁移与现代化： 将本地遗留和/或单体应用迁移到容器上的云原生微服务。
  • 事件驱动处理：通过使用 Azure Functions 编程模型处理来自事件网格、服务总线、Event Hubs 及其他事件源的事件。
  • AI和GPU工作负载： 处理视频、图像、文字稿及其他需要GPU资源的计算密集型工作负载。 有关详细信息，请参阅 Azure 容器应用中使用无服务器 GPU。
  • Microservices：将Azure Functions与其他容器应用托管服务集成。
  • 自定义容器：使用自定义运行时或挎斗打包函数。
  • 专用应用：使用 VNet 和内部入口保护仅限内部使用的函数。
  • .NET Aspire： .NET Aspire 与 Azure Functions 的集成使你可以开发、调试和协调Azure Functions .NET项目作为.NET Aspire应用主机的一部分。 阅读更多关于Azure Functions with .NET Aspire的详细信息
  • General Functions：运行任何受支持的标准Azure Functions方案（例如计时器、文件处理、数据库触发器）。

部署和设置

要在 Azure 容器应用 上部署 Azure Functions，请将函数应用打包为自定义容器镜像，并像部署其他容器应用一样部署，但有一个关键区别。 使用Azure CLI、Azure 资源管理器模板或Bicep时，设置该kind=functionapp属性。 有关详细步骤和示例，请参见 “创建函数应用”。

az containerapp create \
  --resource-group $RESOURCE_GROUP_NAME \
  --name $CONTAINER_APP_NAME \
  --environment $ENVIRONMENT_NAME \
  --image mcr.microsoft.com/k8se/quickstart-functions:latest \
  --ingress external \
  --target-port 80 \
  --kind functionapp \
  --query properties.outputs.fqdn

该命令返回函数应用的URL。 复制此 URL 并将其粘贴到 Web 浏览器中。

在 Azure 门户中，创建容器应用时选择“Optimize for Azure Functions”选项，以使用 Azure Functions 配置。

创建为 Azure Functions 预配置的容器应用时的 Azure 门户截图。

支持所有标准部署方法，包括：

有关详细步骤和示例，请参阅官方入门文档。

定价和计费

Azure 容器应用上的Azure Functions遵循与Azure 容器应用相同的定价模型。 计费基于您为环境选择的计划类型，可以是按需型或专属型。

  • 消耗计划：此无服务器计算选项仅针对应用在运行时使用的资源计费。
  • 专用计划：此选项提供定制计算资源，并根据分配给每个工作负载配置文件的实例进行计费。

你选择的计划决定了计费计算的方式。 环境中的不同应用程序可以使用不同的计划。

账单详情：

  • 在容器应用中使用Azure Functions编程模型无需额外付费。
  • Durable Functions和其他高级模式在同一容器应用定价模型中受支持和计费。 有关详细的计费机制和示例，请参阅 Azure 容器应用 中的计费 文档。

事件驱动的扩展

Azure Functions on Container Apps 支持Azure Functions中所有主要语言运行时，包括 C#、JavaScript / TypeScript（Node.js）、Python、Java、PowerShell 以及自定义容器（自带镜像）。

在 Azure 容器应用 上运行的 Azure Functions 会根据事件源自动配置缩放规则，因此在默认体验下无需手动定义 KEDA 缩放规则。 这就是为什么 Azure 门户中的“添加缩放规则”按钮已针对容器应用上的 Functions 禁用的原因。 但是，仍可以定义最小和最大副本计数，以建立缩放边界，并保持对资源分配的控制。

如果您需要提供自己的缩放规则，可以使用 allowScalingRuleOverride 来选择不采用平台生成的规则。 有关详细信息，请参阅覆盖容器应用中 Azure Functions 的自动生成 KEDA 缩放规则。

该平台会自动将 Functions 触发器参数（来自 host.json 配置或触发器特性）转换为相应的 KEDA 缩放器参数。 有关 Functions 触发器配置如何映射到 KEDA 缩放参数的详细参考，请参阅 Azure Functions KEDA 缩放映射。

在容器应用中支持所有标准 Azure Functions 触发器和绑定，但有以下例外：

  • Blob 存储触发自动缩放：仅当将Event Grid作为源时才有效。 详细了解如何通过事件订阅触发 Azure 函数来处理 blob 容器
  • Durable Functions 自动扩展：仅支持 Microsoft SQL Server 和 Durable Task Scheduler 存储提供商。 欲了解更多信息，请参见“Deploy Durable Functions with SQL Server”。
  • 自动缩放不支持以下情况：
    • Azure Cache for Redis
    • Azure SQL

对于允许使用托管标识的触发器和绑定，支持使用托管标识。 它们也可用于：

对于不支持的触发器，请使用固定副本计数（即在 Azure 容器应用 上的 Azure Functions 中设置 minReplicas > 0）。 有关详细信息，请参阅 Functions 开发人员指南。

可扩展性和性能

默认情况下，容器应用上的Azure Functions会根据使用 KEDA 的事件自动缩放。 你仍然可以设置最小/最大副本数来控制扩展行为。 您还可以使用 allowScalingRuleOverride 来提供自定义缩放规则。

  • Event 驱动的缩放：根据事件网格、服务总线或 HTTP 等触发器自动缩放。
  • 缩放到零：空闲应用缩放到零，以节省成本。
  • 冷启动控制：了解如何减少 Azure 容器应用 上的冷启动时间。
  • 并发：每个实例可以并行处理多个事件。
  • 大规模：每个应用横向扩展到 1,000 个实例（默认值为 10）。
  • GPU 支持：使用 GPU 支持的节点运行计算密集型工作负荷，例如 AI 推理。

这使得容器应用非常适合突发和稳定状态工作负荷。 若要了解详细信息，请参阅 在 Azure 容器应用

网络和安全性

Azure Functions on Container Apps 使用 Container Apps 网络和安全功能：

  • VNet 集成：通过内部终结点和专用数据库安全地访问专用资源。
  • 管理身份：通过系统分配或用户分配的身份与Azure服务进行身份验证。 你不需要管理秘密或连接字符串。
  • Dapr 支持：通过 Dapr sidecar 启用发布/订阅、状态管理和保护服务调用。 有关详细信息，请参阅 Dapr 提供支持的微服务 API。
  • 入口和 TLS：使用 TLS/mTLS、自定义域公开安全 HTTP 终结点，或将其保留在内部。
  • 环境隔离：函数共享容器应用的环境边界，以实现安全、有范围的通信。

监视和日志记录

Azure Functions on Container Apps 集成了 Azure 可观测性工具用于性能跟踪和问题诊断：

  • Application Insights：提供请求、依赖项、异常和自定义跟踪的遥测数据。 有关详细信息，请参阅 Monitor Azure Functions。
  • Log Analytics：捕捉容器生命周期和扩展事件，如FunctionsScalerInfo条目。 欲了解更多信息，请参见 Azure 容器应用 中的应用日志。
  • 自定义日志记录：支持结构化输出的标准框架（如 ILogger 和控制台日志记录）。
  • 集中式监视：容器应用环境为所有应用提供统一的仪表板和警报。

环境变量

在容器应用上运行Azure Functions有权访问系统提供的环境变量。 环境变量 CONTAINER_NAME 会自动设置为函数应用的副本名称。 在多副本场景中，使用该变量进行日志记录、关联和调试。

有关系统提供的环境变量的完整列表，请参阅 Azure 容器应用 中的环境变量。

注意事项

在Azure 容器应用上使用Azure Functions时，请记住以下其他注意事项：

  • 自动扩展的入口要求：要启用基于事件的自动扩展，请 在公开或容器应用内部环境中启用入口。
  • 强制存储账户：所有部署在容器应用中的函数应用必须关联到存储账户。 这个存储账户管理触发器、日志和状态。 查看存储帐户指南，了解最佳做法。
  • 多修订存储：使用多个活动修订进行部署时，请为每个修订分配专用存储帐户。 使用专用存储帐户有助于防止冲突并确保适当的隔离。 或者，如果不需要同时进行多个版本修订，可以考虑使用默认的单版本修订模式，以简化管理。
  • 多修订触发器：如果对基于拉取的触发器使用多修订模式，请为每个修订使用不同的事件源以避免与竞争使用者相关的冲突。 使用Azure 队列存储、Azure 事件中心、Azure 服务总线或Durable Functions触发器的函数是基于拉取的触发器的示例。
  • 冷启动延迟：当容器应用在空闲期间缩放至零实例时，空闲后收到的第一个请求会经历一次冷启动。 详细了解如何缩短冷启动时间。
  • 应用洞察集成：要监控和诊断你的函数应用，可以将其连接到应用洞察。 更多信息请参见 Application Insights 与函数的集成。
  • Functions 代理：不支持。 对于 API 网关方案，请改为与Azure API 管理集成。
  • 部署槽位：测试槽和生产槽不可用。 使用蓝绿部署策略实现零故障时间发布。
  • 函数访问密钥：不支持使用门户生成 Functions 访问密钥。 请考虑使用 Azure 密钥保管库 来存储密钥。 还可以使用以下选项来保护生产中的 HTTP 终结点：
  • 配额和资源限制：容器应用环境对每个区域的内存、CPU 和实例数量都有默认限制。 有关详细信息，请参阅环境限制和默认配额。 如果工作负载需要更多资源，可以请求增加配额。
  • 手动缩放规则配置：在 Azure 门户中，“添加缩放规则”按钮被禁用，因为托管在容器应用上的 Azure Functions 会根据事件源自动配置缩放规则。 此设置中不需要手动 KEDA 规则定义。

提交反馈

向 Azure 容器应用 GitHub 存储库提交问题或功能请求。

后续步骤/其他资源

若要继续使用容器应用上的Azure Functions进行学习和构建，请浏览以下资源：

  • Last updated on