你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用计划内维护来计划和控制 Azure Kubernetes 服务群集的升级
本文介绍如何在 Azure Kubernetes 服务 (AKS) 中使用计划内维护来计划和控制群集和节点映像升级。
对 AKS 群集的定期维护是自动进行的。 有两种类型的维护操作:
- AKS 发起的维护涉及 AKS 执行的用于使群集与最新功能和修补程序保持一致的每周发布。
- 用户发起的维护包括群集自动升级和节点操作系统 (OS) 自动安全更新。
使用 AKS 中的计划内维护功能时,可以按照自己选择的节奏运行两种类型的维护,以最大程度地减少工作负荷影响。 可以使用计划内维护来计划自动升级的时间,但启用或禁用计划内维护不会启用或禁用自动升级。
- 本文假定你拥有现有的 AKS 群集。 如果还没有 AKS 群集,请参阅创建 AKS 群集。
- 如果使用 Azure CLI,请通过使用
az upgrade
命令升级到最新版本。
使用计划内维护时,以下注意事项适用:
- 对于紧急或关键的计划外、反应性维护操作,AKS 保留在计划内维护时段外进行操作的权利。 这些维护操作甚至可以在配置中定义的
notAllowedTime
或notAllowedDates
期间运行。 - 我们会尽最大努力执行维护操作,但不保证在指定时段内执行。
计划内维护可使用三种计划配置类型:
default
是用于控制 AKS 发布的基本配置。 由于 Azure 安全部署做法,这些发布可能需要长达两周的时间才能推出到所有区域(从最初的发布时间算起)。选择
default
可安排这些更新,使其对你造成的影响最小。 可使用每周发布跟踪器按区域监视正在进行的 AKS 发布的状态。aksManagedAutoUpgradeSchedule
控制何时执行由指定的自动升级通道计划的群集升级。 与default
配置相比,使用此配置可以更精细地控制频率和定期设置。 有关群集自动升级的详细信息,请参阅自动升级 Azure Kubernetes 服务群集。aksManagedNodeOSUpgradeSchedule
控制何时执行由节点 OS 自动升级通道计划的节点 OS 安全修补。 与default
配置相比,使用此配置可以更精细地控制频率和定期设置。 有关节点 OS 自动升级通道的详细信息,请参阅自动修补和更新 AKS 群集节点映像。
建议对所有群集升级方案使用 aksManagedAutoUpgradeSchedule
,对所有节点 OS 安全修补方案使用 aksManagedNodeOSUpgradeSchedule
。
default
专用于 AKS 每周发布。 可以使用 az aks maintenanceconfiguration update
命令将 default
配置切换为 aksManagedAutoUpgradeSchedule
或 aksManagedNodeOSUpgradeSchedule
配置。
备注
使用自动升级时,为了确保正常运行,请使用持续时间为 4 小时或 4 小时以上的维护时段。
计划内维护时段以协调世界时 (UTC) 方式指定。
default
维护时段具有以下旧属性(不再推荐):
名称 | 说明 | 默认值 |
---|---|---|
timeInWeek |
在 default 配置中,此属性包含定义维护时段的 day 和 hourSlots 值。 |
不适用 |
timeInWeek.day |
default 配置中要执行维护的一周中的某一天。 |
不适用 |
timeInWeek.hourSlots |
default 配置中要在特定的一天执行维护的小时长的时间槽列表。 |
不适用 |
notAllowedTime |
维护无法运行的日期范围,由 start 和 end 子属性确定。 仅当你使用配置文件创建维护时段时,此属性才适用。 |
不适用 |
备注
从 2023-05-01 API 版本开始,请使用以下属性进行 default
配置。
从 2023-05-01 API 版本开始,aksManagedAutoUpgradeSchedule
或 aksManagedNodeOSUpgradeSchedule
维护时段和 default
配置具有以下属性:
名称 | 说明 | 默认值 |
---|---|---|
utcOffset |
群集维护的时区。 | +00:00 |
startDate |
维护时段开始生效的日期。 | 创建时的当前日期 |
startTime |
维护开始的时间,基于由 utcOffset 确定的时区。 |
不适用 |
schedule |
升级频率。 提供三种类型:Weekly 、AbsoluteMonthly 和 RelativeMonthly 。 |
不适用 |
intervalDays |
维护运行的间隔(以天为单位)。 它仅适用于 aksManagedNodeOSUpgradeSchedule 。 |
不适用 |
intervalWeeks |
维护运行的间隔(以周为单位)。 | 不适用 |
intervalMonths |
维护运行的间隔(以月为单位)。 | 不适用 |
dayOfWeek |
要开始维护的一周中的指定某一天。 | 不适用 |
durationHours |
要运行维护的时段的持续时间。 | 不适用 |
notAllowedDates |
维护无法运行的日期范围,由 start 和 end 子属性确定。 仅当你使用配置文件创建维护时段时,它才适用。 |
不适用 |
有四种可用的计划类型:Daily
、Weekly
、AbsoluteMonthly
和 RelativeMonthly
。
Weekly
、AbsoluteMonthly
和 RelativeMonthly
计划类型仅适用于 aksManagedClusterAutoUpgradeSchedule
和 aksManagedNodeOSUpgradeSchedule
配置。 Daily
计划仅适用于 aksManagedNodeOSUpgradeSchedule
配置。
为每个计划类型显示的所有字段都是必填字段。
Daily
计划可能类似于“每三天一次”:
"schedule": {
"daily": {
"intervalDays": 3
}
}
Weekly
计划可能类似于“每两周一次,在星期五进行”:
"schedule": {
"weekly": {
"intervalWeeks": 2,
"dayOfWeek": "Friday"
}
}
AbsoluteMonthly
计划可能类似于“每三个月一次,在当月的第一天进行”:
"schedule": {
"absoluteMonthly": {
"intervalMonths": 3,
"dayOfMonth": 1
}
}
RelativeMonthly
计划可能类似于“每两个月一次,在最后一个星期一进行”:
"schedule": {
"relativeMonthly": {
"intervalMonths": 2,
"dayOfWeek": "Monday",
"weekIndex": "Last"
}
}
weekIndex
的有效值包括 First
、Second
、Third
、Fourth
和 Last
。
使用 az aks maintenanceconfiguration add
命令向 AKS 群集添加维护时段配置。
第一个示例添加一个新的 default
配置,该配置计划的维护在每星期一从凌晨 1:00 运行到凌晨 2:00。 第二个示例添加一个新的 aksManagedAutoUpgradeSchedule
配置,该配置计划的维护每三周进行一次,在星期五的凌晨 0:00 到上午 8:00 之间运行(UTC+5:30
时区)。
# Add a new default configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 1
# Add a new aksManagedAutoUpgradeSchedule configuration
az aks maintenanceconfiguration add --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule --schedule-type Weekly --day-of-week Friday --interval-weeks 3 --duration 8 --utc-offset +05:30 --start-time 00:00
备注
使用 default
配置类型时,可以省略 --start-time
参数,这样就可以在一天内随时进行维护。
使用 az aks maintenanceconfiguration update
命令更新现有的维护配置。
以下示例将 default
配置更新为让计划的维护在每星期一从凌晨 2:00 运行到凌晨 3:00:
az aks maintenanceconfiguration update --resource-group myResourceGroup --cluster-name myAKSCluster --name default --weekday Monday --start-hour 2
使用 az aks maintenanceconfiguration list
命令列出 AKS 群集中的当前维护配置时段:
az aks maintenanceconfiguration list --resource-group myResourceGroup --cluster-name myAKSCluster
配合使用 az aks maintenanceconfiguration show
命令和 --name
参数查看 AKS 群集中的特定维护配置时段:
az aks maintenanceconfiguration show --resource-group myResourceGroup --cluster-name myAKSCluster --name aksManagedAutoUpgradeSchedule
以下示例输出显示了 aksManagedAutoUpgradeSchedule
的维护时段:
{
"id": "/subscriptions/<subscription>/resourceGroups/myResourceGroup/providers/Microsoft.ContainerService/managedClusters/myAKSCluster/maintenanceConfigurations/aksManagedAutoUpgradeSchedule",
"maintenanceWindow": {
"durationHours": 4,
"notAllowedDates": [
{
"end": "2024-01-05",
"start": "2023-12-23"
}
],
"schedule": {
"absoluteMonthly": {
"dayOfMonth": 1,
"intervalMonths": 3
},
"daily": null,
"relativeMonthly": null,
"weekly": null
},
"startDate": "2023-01-20",
"startTime": "09:00",
"utcOffset": "-08:00"
},
"name": "aksManagedAutoUpgradeSchedule",
"notAllowedTime": null,
"resourceGroup": "myResourceGroup",
"systemData": null,
"timeInWeek": null,
"type": null
}
使用 az aks maintenanceconfiguration delete
命令删除 AKS 群集中的维护配置时段。
以下示例删除 autoUpgradeSchedule
维护配置:
az aks maintenanceconfiguration delete --resource-group myResourceGroup --cluster-name myAKSCluster --name autoUpgradeSchedule
如何检查群集中的现有维护配置?
使用
az aks maintenanceconfiguration show
命令。计划外、反应性维护是否也能在
notAllowedTime
或notAllowedDates
期间进行?是的。 对于紧急或关键的计划外、反应性维护操作,AKS 保留在这些时段外进行操作的权利。
如何判断是否发生了维护事件?
对于发布,请检查群集的区域并在每周发布中查找信息,看它是否与维护计划匹配。 若要查看自动升级的状态,请在群集上查找活动日志。 还可查找升级 AKS 群集中所述的与升级相关的特定事件。
AKS 还会发出与升级相关的 Azure 事件网格事件。 若要了解详细信息,请参阅充当事件网格源的 AKS。
是否可以同时使用多种维护配置?
是的,可以同时运行所有三种配置:
default
、aksManagedAutoUpgradeSchedule
和aksManagedNodeOSUpgradeSchedule
。 如果时段重叠,AKS 会决定运行顺序。我配置了维护时段,但升级没有进行。 为什么?
考虑到维护时段,AKS 自动升级需要一定的时间(通常不超过 15 分钟)。 建议在创建或更新维护配置与计划启动时间之间至少间隔 15 分钟。
此外,请确保在计划内维护时段开始时启动群集。 如果群集已停止,则会解除其控制平面的分配,不允许执行任何操作。
为什么我的代理池之一在维护时段之外进行了升级?
如果代理池因故未升级(例如,Pod 中断预算阻止其升级),则稍后可能会在维护时段之外对其进行升级。 此方案称为“弥补升级”。它可以避免让代理池使用与 AKS 控制平面不同的版本进行升级。
代理池可能被意外升级的另一个原因是没有已定义的维护配置,或者它已被删除。 在这种情况下,具有自动升级配置但没有维护配置的群集将在随机时间(回退时间表,可能不是希望使用的时间范围)进行升级。
对于维护配置,是否有任何最佳做法?
如果你使用的是
NodeImage
通道,建议将节点 OS 安全更新计划设置为每周一次,因为每周都会发布一个新的节点映像。 也可选择使用SecurityPatch
通道来接收每日安全更新.请将自动升级计划设置为每月一次,随时了解 Kubernetes N-2 支持策略。
有关升级最佳做法和其他注意事项的详细讨论,请参阅 AKS 补丁和升级指南。
是否可以将单个订阅中的所有群集配置为使用相同的维护配置?
不建议对单个订阅中的多个群集使用相同的维护配置,因为这样做可能会导致 ARM 限制错误,从而导致群集升级失败。 相反,我们建议错开每个群集的维护时段,以避免这些错误。
- 若要开始升级 AKS 群集,请参阅 AKS 群集的升级选项。