摘要

  • APNIC 公告列出 10 月 21 日 08:30—14:30（UTC+10）的 Kubernetes 升级窗口，状态页显示的 UTC 时段与之相符。
  • 同一公告链接下的 iCalendar 事件从 10 月 19 日 22:30 UTC 开始，早一天；这项排期冲突本身不能证明发生过中断。

同一项升级，两个开始日期

APNIC 服务公告把 Kubernetes 集群升级安排在 2026 年 10 月 21 日（星期三）08:30 至 14:30（UTC+10），并提示节点轮换期间可能出现短暂中断。六小时是预留的维护窗口，不代表每项列出的服务都会停机六小时。

APNIC 的公开服务状态页把同一事件显示为 10 月 20 日 22:30 UTC 至 21 日 04:30 UTC，换算后正好是公告所列的六小时。差异出现在官方 iCalendar 订阅：事件名为 “Kubernetes upgrade”，描述链接到同一份 21 日公告，却写有 DTSTART;TZID=UTC:20261019T223000 和 DTEND;TZID=UTC:20261020T043000。

按 UTC+10 换算，订阅中的时段是布里斯班时间 10 月 20 日 08:30—14:30，比公告和状态页早整整一天。iCalendar 字段明确标为 UTC，因此把它误读成布里斯班当地时间不能解释这 24 小时差距。相同的事件名称、六小时长度和公告链接也表明，这不是两项不同的维护。

对于把官方日历订阅导入变更日历的团队，差异很实际：订阅流显示的日期与公告和状态页不同。但现有公开记录没有说明 APNIC 希望运营者遵循哪一个日期，也没有证据显示有人依据提前的日期采取行动，或任何服务将会中断。我们查看记录时，这项工作仍是未来安排。

来源

本文对照了 APNIC 服务公告、公开状态页和 iCalendar 订阅。