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 资源提供程序,并在调用 az containerapp create 时设置 kind=functionapp,将 Azure Functions 容器镜像直接部署到 Azure 容器应用。 以这种方式创建的应用可以访问所有 Azure 容器应用功能。 在 Azure 门户中,设置时选择“Optimize for Azure Functions”选项。 更多信息请参见 部署与设置

主要优势

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

  • Azure Functions 作为容器运行,并使用自定义依赖项和语言堆栈。
  • 缩减到零并扩展到 1,000 个实例,使用 KEDA。
  • 使用完整的 VNet 集成保护网络
  • 容器应用的功能包括多版本、流量分割、DAPR集成可观测组件
  • 统一容器应用环境 ,用于与微服务、API 和后台作业一起运行 Functions。

下表可帮助你比较容器应用上的函数与弹性消耗计划的功能特性。

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

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

情境

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

  • 业务线应用程序 API: 使用 Azure Functions 为业务线应用程序打包自定义库、包和 API。
  • 迁移与现代化: 将本地遗留和/或单体应用迁移到容器上的云原生微服务。
  • 事件驱动处理:通过使用 Azure Functions 编程模型处理来自事件网格、服务总线、Event Hubs 及其他事件源的事件。
  • AI和GPU工作负载: 处理视频、图像、文字稿及其他需要GPU资源的计算密集型工作负载。
  • 微服务: 将 Azure Functions 与其他容器应用托管服务集成。
  • 自定义容器: 使用自定义运行时或 sidecars 打包函数。
  • 专用应用: 使用 VNet 和内部入口保护仅限内部的函数。
  • Aspire:Aspire与Azure Functions的集成使你能够开发、调试和协调Azure Functions项目,作为Aspire AppHost的一部分。 有关更多信息,请参阅 在 AppHost 中设置 Azure 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 门户中创建已为 Azure Functions 预先配置的容器应用时的截图。

支持所有标准部署方法,包括:

  • Azure CLI
  • Azure 门户
  • ARM 模板/ Bicep
  • CI/CD 管道(例如 GitHub Actions、Azure Pipelines)

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

定价和计费

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 停用平台生成的规则。 有关详细信息,请参阅 替代为 Container Apps 上的 Azure Functions 自动生成的 KEDA 缩放规则

平台会自动将 Functions 的触发器参数(从 host.json 配置或触发器属性)转换为适当的 KEDA 缩放器参数。 有关 Functions 触发器配置如何映射到 KEDA 缩放参数的详细参考,请参阅 Azure Functions KEDA 缩放映射

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

  • Blob 存储触发器自动缩放:仅在将事件网格用作源时才有效。 详细了解如何通过事件订阅触发 Azure 函数来处理 blob 容器
  • Durable Functions 自动扩展:仅支持 Microsoft SQL Server 和 Durable Task Scheduler 存储提供商。
  • 自动缩放不支持以下情况:
    • Azure Cache for Redis
    • Azure SQL

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

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

可扩展性和性能

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

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

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

网络和安全性

在 Container Apps 上的 Azure Functions 使用 Container Apps 的 网络功能安全功能

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

监视和日志记录

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

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

环境变量

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

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

注意事项

在 Azure 容器应用中使用 Azure Functions 时,请记住以下其他注意事项:

  • 自动扩展的入口要求:要启用基于事件的自动扩展,请 在公开或容器应用内部环境中启用入口。

  • 强制存储账户:所有部署在容器应用中的函数应用必须关联到存储账户。 这个存储账户管理触发器、日志和状态。 查看 存储帐户指南 ,了解最佳做法。

  • 多修订存储:使用多个活动修订进行部署时,请为每个修订分配专用存储帐户。 使用专用存储帐户有助于防止冲突并确保适当的隔离。 或者,如果不需要并发修订,请考虑使用默认单一修订模式进行简化管理。

  • 多修订触发器:如果对基于拉取的触发器使用多修订模式,请为每个修订使用不同的事件源以避免与竞争使用者相关的冲突。 使用Azure 队列存储、Azure 事件中心、Azure 服务总线或Durable Functions触发器的函数是基于拉取的触发器的示例。

  • 冷启动延迟:当容器应用在空闲期间缩小到零时,处于非活动状态后的第一个请求会经历冷启动。 详细了解 如何减少冷启动时间

  • 应用洞察集成:要监控和诊断你的函数应用,可以将其连接到应用洞察。 更多信息请参见 Application Insights 与函数的集成

  • 函数代理:不支持。 对于 API 网关方案,请改为与 Azure API 管理集成。

  • 部署槽位:测试槽和生产槽不可用。 使用 蓝绿部署策略 实现零停机发布。

  • 函数访问密钥:不支持使用门户生成 Functions 访问密钥。 请考虑使用 Azure 密钥保管库 来存储密钥。 还可以使用以下选项来保护生产中的 HTTP 终结点:

  • 手动缩放规则配置:Azure 门户上的“添加缩放规则”按钮对于容器应用上托管的 Azure Functions 禁用,因为缩放规则是根据事件源自动配置的。 此设置中不需要手动 KEDA 规则定义。

提交反馈

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

后续步骤/进一步资源

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