Kubernetes 生产运维：发布、容量与数据保护

发布回滚、权限与集群维护

维护Kubernetes 单副本计数项目前先保存context、namespace、Secret 与 PVC，恢复后以Pod 条件、EndpointSlice 与持久数据验收。具体配置见配套示例。

配置发布与回滚

Kubernetes 配置 更新不是同时发生的事务。本例 ConfigMap 进入环境变量，Secret 在进程启动时读入；对象更新后旧进程仍保存旧值。应将配置变更与 PodTemplate 修订关联，用校验和注解或受控 rollout 明确重建，并记录配置版本、镜像 digest 和数据库兼容性。

Deployment rollback 主要回到旧 PodTemplate，不恢复外部 ConfigMap、Secret 或 PVC 数据。若两个修订引用同一个可变 ConfigMap 名称，旧模板也可能拿到新配置。生产可使用版本化配置对象，保留旧版本直到确认不再需要，并规划 Secret 轮换的双凭据过渡。

RBAC 与身份

Kubernetes RBAC 最小权限 由 Role 的资源/verb 与 RoleBinding 的主体共同决定。RBAC 只有允许规则，多条绑定权限取并集；命名空间内 RoleBinding 绑定 ClusterRole 也不会把该角色授予整个集群。认证、鉴权和准入是不同阶段，允许创建 Pod 不代表准入一定接受。

主例 counter ServiceAccount 不调用 API，故 automountServiceAccountToken: false；不能为了应用访问自己的数据卷而授 cluster-admin。observer 只读资源和日志，不读 secrets、不 exec、不改 Deployment。拥有创建 Pod、修改 RoleBinding 或模拟身份的权限可能形成间接提权，应按真实任务评估，而不是只看是否显式有 get secrets。

容量、扩缩与故障域

Kubernetes HPA requests 必须匹配指标语义：按 CPU 利用率伸缩通常需要 requests 和资源指标源；HPA 增副本不等于节点容量自动增加，节点扩容也不修复单写数据库设计。本例不含 HPA，因为 SQLite 单副本并不是可水平扩展后端。

资源值需依据启动、峰值、稳定期、重试与故障恢复测量。跨节点或故障域的拓扑分布、PDB、亲和性与配额会限制调度和维护。PDB 约束自愿中断，但不保证硬件故障时有副本，也不消除 drain 可能长时间等待的情况。

卷、快照与集群维护

Kubernetes PVC 备份 不由 etcd 快照代替：etcd 保存 API 对象，应用实际文件在后端存储。CSI 快照能力取决于驱动与控制器，快照是否应用一致还需数据库协调。恢复到新 PVC 后先核对数据、权限、应用版本与恢复时点，再切换服务，不能把“快照资源创建成功”写成恢复已验证。

集群升级需核对服务端/客户端版本偏差、API 移除、CNI/CSI/准入 webhook 和 CRD 兼容；节点维护先确认容量与 PDB，再计划 cordon/drain。drain 的 delete-emptydir-data 和强制选项可能丢临时状态，不能作为通用排障起手式。托管平台与自建 kubeadm 的控制面责任不同，命令不可混用。

维护练习与解答

问题：回滚 Deployment 后 MESSAGE 仍是新值，是否回滚失败？答案：可能模板已经回退，但仍引用同名新 ConfigMap。检查模板修订和配置对象两条线，不能只重复 rollback。

问题：平台备份了 etcd 能恢复 count 吗？答案：不能据此保证，count 位于 PVC 后端，需要应用一致的数据备份与真实恢复验证。

深入手册：扩缩容、安全 RBAC、可观测性、升级维护、生产实践。一手依据：RBAC、ConfigMap、Secrets、Disruptions。核对 2026-10-17。

管理界面的权限、网络与存储审查

Kubernetes 管理界面使用 cluster-admin、hostNetwork 和 hostPath 时要检查什么？ 管理界面是集群内的应用，也要沿身份、网络和数据三条线审查。Kuboard v3 旧清单把 ServiceAccount 绑定 cluster-admin，给 etcd DaemonSet 使用 hostNetwork、hostPort 与 hostPath，并用节点亲和与容忍选择节点。需要分别解释它为何需要这些权限、实际会在哪些节点保存数据，以及服务端口与 agent TCP/UDP 端口的调用方；浏览器能访问 NodePort 只覆盖入口，不证明 agent 通信、数据库可靠性或授权边界。

不要由“DaemonSet 跑在多个节点”推导数据已可靠复制，也不要把原节点目录当作可移植的 PVC。评估替代版本时，应查看目标产品的实际部署与备份合同，再按任务授予权限、确认网络可达和恢复路径。本课 observer 只读角色不是该管理界面的等价替换；这里继承审查方法，原厂商清单和原地址不再作为可执行指导。RBAC与卷是平台侧核对依据。

从证书脚本检查文件与信任链

如何从 Kubernetes 二进制部署草稿发现证书路径和 etcd 协议不一致？ 二进制部署草稿适合练习“生成什么、消费什么”的静态核对。原稿生成 ca-ssl.json 却引用 ca-config.json，覆盖 etcd-csr.json 后又读取未生成的 kube-apiserver-csr.json；复制 .pem 产物后，API Server 参数却指向 ca.crt、apiserver.crt 等另一组文件。仅把脚本排版变整齐，不会补齐这些依赖。先画出 CA→CSR→签发产物→服务参数的对应表，逐项核对路径、证书用途、SAN、私钥访问权与有效期，再检查组件之间是否信任同一个签发链。PKI requirements为核对入口（2026-10-17）。

协议也属于合同：原 etcd 监听和通告使用 HTTPS，API Server 却连接 HTTP；这不是靠重试可修复的同一个地址。etcd 客户端与 peer 连接要分别确认监听、通告、信任 CA 和客户端证书。旧参数还包含未提供的 service-account/front-proxy/kubelet-client 文件，因此没有闭合到可运行集群。本节只保存审查方法和具体断点；没有生成证书、运行 cfssl/systemd、补写安装脚本或声称兼容当前版本。

Kubernetes 生产实践

生产就绪不是一个 YAML

生产 Kubernetes 是控制面、节点、插件、云资源、镜像仓库、身份、可观测性和团队流程共同组成的系统。下面是基线，不替代发行版与业务专用设计。

集群与故障域

• 控制面跨故障域高可用；etcd 使用低延迟、可靠磁盘并定期恢复演练。
• 工作节点至少跨多个故障域，关键服务多副本并用拓扑分布。
• CoreDNS、CNI、CSI、Ingress/Gateway、监控和密钥控制器同样多副本。
• 预留单节点/单故障域失败、滚动升级和突发扩容容量。
• 明确单集群、同区域多集群或跨区域架构；Kubernetes 不自动提供跨集群容灾。

命名空间与多租户

按团队/环境/生命周期划分命名空间，配套：

• 专用 ServiceAccount 和最小 RBAC。
• ResourceQuota、LimitRange 和 PriorityClass 治理。
• 默认拒绝 NetworkPolicy 与明确出口。
• Pod Security Admission 和准入策略。
• 成本、告警、备份、所有者和数据等级标签。

命名空间不是强隔离沙箱。互不信任租户应评估独立节点池、RuntimeClass、用户命名空间、沙箱运行时甚至独立集群。

工作负载生产基线

每个服务还应具备：

• 稳定标签、Owner、Runbook、SLO、Dashboard 和告警。
• 镜像 digest、SBOM、扫描、签名/来源验证和回退版本。
• 多副本、PDB、拓扑分布、资源请求、三类探针、优雅终止和连接排空。
• 非 root、禁止提权、只读根文件系统、默认 seccomp 和最小 capabilities。
• 配置 Schema、Secret 轮换和向前/向后兼容发布。
• 应用级日志、指标、Trace 和健康端点。

发布治理

1. 代码、清单、Chart/Overlay 和策略均经 Review。
2. CI 执行单测、镜像构建/扫描、Schema、服务器 dry-run/策略和集成测试。
3. CD 展示 diff，使用独立最小权限身份，等待 rollout 和业务冒烟。
4. 高风险服务用金丝雀/蓝绿与自动指标判定；数据库先做兼容迁移。
5. 变更与监控时间线关联，失败自动停止扩散而不是无限重试。
6. 紧急手工修改必须记录并尽快回写声明式源，消除漂移。

GitOps/Helm/Kustomize 是配置交付工具，不自动保证配置正确。明确每个字段的唯一管理者，避免 HPA、GitOps、人工同时写 replicas。

容量与弹性

• requests 基于真实负载，定期对比使用率与节流/OOM。
• 命名空间 Quota 留出 surge、故障恢复、Job 和调试余量。
• HPA 上限与下游数据库、缓存、消息队列容量一致。
• 节点扩容考虑启动延迟、云配额、IP、镜像拉取和 PV 故障域。
• 定期演练节点、故障域、DNS、Registry、依赖和控制面故障。
• 避免所有关键副本被同一节点、节点池或可用区承载。

数据保护

• 为每个有状态系统定义 RPO、RTO、备份所有者、保留与恢复流程。
• 数据库使用应用一致备份；CSI 快照只是其中一个层次。
• 备份存储与集群/账户/区域隔离，启用加密和防删除。
• 定期恢复到隔离环境并验证业务数据，而不是只验证文件存在。
• 记录 PVC、PV、后端卷、StatefulSet 序号和数据库成员映射。
• etcd 备份只保护 Kubernetes API 状态，不替代业务数据备份。

安全运营

• 人员通过集中身份/OIDC 和短期权限访问，不共享 kubeconfig。
• Break-glass 凭据离线保护、使用即告警、事后轮换和复盘。
• 节点与控制面无不必要公网入口，补丁在支持窗口内上线。
• 审计 exec、Secret、RBAC、Webhook、CRD、Node 和策略变更。
• 第三方 Chart/Operator 视为软件供应链依赖，审查权限与维护状态。
• 建立 Kubernetes、CNI/CSI、Ingress、运行时和 OS CVE 响应流程。

可观测性与值班

• 以用户 SLO 驱动告警，基础设施告警能关联业务影响。
• Dashboard 可按 cluster → namespace → workload → Pod → node 下钻。
• 日志、指标、Trace、Event、Audit 与部署版本使用统一时间和元数据。
• Runbook 给出只读诊断、决策点、安全缓解、回退和升级路径。
• 每季度通过游戏日/故障演练验证人、权限、工具和文档。

成本治理

• 以 requests/实际使用/峰值对比发现闲置和风险，而非只看账单总额。
• 分配共享控制面、LB、公网流量、日志、快照和闲置 PV 成本。
• Spot/抢占式节点只承载可中断、跨节点冗余且有恢复能力的工作负载。
• 节省成本不能破坏 N+1 容量、发布 Surge 或灾备目标。

生命周期治理

建立版本台账：Kubernetes、节点 OS、运行时、CNI、CSI、DNS、Ingress/Gateway、监控、Operator、CRD 与客户端。每项记录当前版、目标版、EOL、Owner、兼容矩阵和升级演练日期。

每个次要版本发布后：

1. 阅读公告、弃用和安全变化。
2. 在预发运行 API/插件兼容测试。
3. 升到当前分支最新补丁，减少已知缺陷。
4. 在 EOL 前完成逐级升级，不把多个大版本堆到最后。

生产评审清单

• [ ] 服务 SLO、Owner、Runbook、Dashboard、告警齐全。
• [ ] 多副本跨故障域，PDB、资源、探针和优雅终止已压测。
• [ ] RBAC、Pod Security、NetworkPolicy、镜像和 Secret 达到基线。
• [ ] 配置/Schema/依赖支持滚动发布与回退。
• [ ] HPA/节点容量/配额/IP/PV 能覆盖峰值与故障。
• [ ] 备份跨故障域且恢复演练满足 RPO/RTO。
• [ ] 发布、紧急变更和 Break-glass 流程实际演练过。
• [ ] 核心与插件版本均在支持期，升级窗口明确。