零停机维护策略 (Zero-Downtime Maintenance)

在云时代，"维护窗口 (Maintenance Window)" 应当是一个过时的概念。Cyberun Cloud 的架构设计目标是：基础设施的变更永远不应导致业务中断。

我们结合自动化能力与 Kubernetes 的原生调度机制，实现了全栈的零停机维护。

操作系统与内核修补 (OS Patching)

stateDiagram-v2
    direction TB

    state "1. 活跃节点 (Active)" as Active
    state "2. 封锁中 (Cordoned)" as Cordon
    state "3. 驱逐中 (Draining)" as Drain
    state "4. 重启/升级 (Reboot)" as Maint
    state "5. 就绪检测 (Ready)" as Check

    Active --> Cordon : 标记为不可调度
    Cordon --> Drain : 优雅终止 Pod
    Drain --> Maint : 流量完全排空
    Maint --> Check : 系统重启完成
    Check --> Active : 通过健康检查

    note right of Drain
        由 PDB 保护
        确保业务副本数 > 80%
    end note

为了修复底层 Linux 内核漏洞（如 CVE），物理节点必须重启。我们如何做到不影响业务？

封锁节点 (Cordon): 自动化脚本首先将目标节点标记为 Unschedulable，阻止新流量进入。
安全驱逐 (Drain): 系统发送 SIGTERM 信号给节点上的所有 Pod。
- 优雅终止: 您的应用有 30 秒（默认）的时间完成当前请求、关闭数据库连接并保存状态。
- PDB 保护: 我们严格遵守 PodDisruptionBudget，确保在任何时刻，服务的健康副本数不低于定义的阈值（例如 80%）。
滚动重启 (Rolling Reboot): 我们永远不会同时重启所有节点。Ansible 会按顺序、逐个机架地执行重启操作，确保集群容量始终充裕。

Kubernetes 版本升级

控制平面的升级对用户是完全透明的。

蓝绿控制面: 在升级 Carrier 集群时，我们会启动新版本的 API Server 副本，待其健康检查通过后，流量才会无缝切换过去。
兼容性保证: 我们严格遵循 N-2 版本策略，确保存储驱动 (CSI) 和网络插件 (CNI) 在升级过程中保持向后兼容。

应用发布 (GitOps)

对于用户部署的应用，Cyberun 默认通过 FluxCD 实施 滚动发布 (Rolling Update) 策略：

strategy:
  rollingUpdate:
    maxSurge: 25% # 允许临时超出 25% 的资源以启动新版本
    maxUnavailable: 0 # 升级过程中不允许任何旧版本副本不可用

这意味着在部署新版本代码时，直到新版本的 Pod 通过了 ReadinessProbe（就绪探针），旧版本的 Pod 才会开始下线。流量永远只会被路由到健康的实例。