问题描述

在日常运维 Azure Container Apps（ACA）时，可能会观察到副本重启、实例滚动更新或短暂连接中断等现象。遇到这类情况时，第一反应通常是平台异常，但实际也可能是底层平台正在执行例行升级或维护。

此时常见的疑问是：

• ACA 是否会通过 Service Health 提前通知每一次维护？
• 如果没有逐次通知，是否可以控制维护发生的时间？

根据官方文档，Azure Container Apps 是托管服务，平台和基础设施更新会定期自动执行。对于常规非关键维护，平台不会针对每次维护单独发送提前通知，而是通过滚动更新等方式尽量降低对业务的影响。可行的控制方式是：为 Container Apps Environment 配置 Planned Maintenance Window，将非关键更新尽量安排在业务低峰期开始。

问题解答

ACA 的维护更新主要分为两类：

1. 关键更新（Critical）
   ：涉及安全性和稳定性的紧急修复，可能在任何时间执行，不受维护窗口限制。
2. 非关键更新（Noncritical）
   ：包括例行安全补丁、Bug 修复和新功能引入。如果配置了维护窗口，这类更新只会在窗口内开始；如果没有配置，则可能在任意时间开始。

因此，维护窗口并不是“禁止维护”，而是控制非关键更新的开始时间。需要注意的是，维护可以保证在窗口内开始，但不保证一定在窗口内完成。

配置方法（Azure CLI）

示例：每周日 UTC 18:00 开始，持续 8 小时，对应北京时间周一凌晨 02:00 - 10:00。

az containerapp env maintenance-config add --resource-group <group name> --environment <environment name> --weekday Sunday --start-hour-utc 18 --duration 8

命令执行截图：

查看当前维护窗口：

az containerapp env maintenance-config list   --resource-group <group name>   --environment <environment name>

更新维护窗口：

az containerapp env maintenance-config update  --resource-group <group name>  --environment <environment name>--weekday Saturday   --start-hour-utc 18   --duration 8

注意事项

维护窗口仅适用于非关键更新，关键安全或稳定性修复仍可能在窗口外执行。

每个 Environment 只能配置一个维护窗口，持续时间范围为 8 到 24 小时。

该功能是可选能力，并会产生 Dedicated Plan Management 相关费用。

另外，维护窗口并不替代应用自身的高可用设计，建议将窗口设置在业务低峰期，并确保应用具备多副本、无状态化、重试和熔断等能力，以降低滚动更新期间的影响。

官方文档也说明，该能力不适用于运行在 consumption workload profiles 上的 Container Apps 和 Jobs。

参考资料

Azure 容器应用计划内维护 ：https://docs.azure.cn/zh-cn/container-apps/planned-maintenance

当在复杂的环境中面临问题，格物之道需：

浊而静之徐清，安以动之徐生。 

云中，恰是如此!