4. K8s集群生命周期阶段:规划、部署、升级、扩缩容、备份恢复、退役
Kubernetes集群的生命周期管理是平台运维的核心能力。从初始规划到最终退役,每个阶段都涉及特定的操作、校验点和RBAC权限控制。本章将系统梳理集群全生命周期的六大阶段,并重点说明每个阶段对应的运维发布包校验与RBAC策略。
4.1 生命周期全景概览
K8s集群的完整生命周期可划分为六个连续阶段,每个阶段都有明确的输入、输出和关键校验点。下表总结了各阶段的核心任务与RBAC关注点:
| 阶段 | 核心任务 | 运维发布包校验要点 | RBAC关键角色 |
|---|---|---|---|
| 规划 | 版本选型、资源估算、网络方案、存储方案 | 兼容性矩阵、资源配额模板 | ClusterAdmin、Auditor |
| 部署 | 节点初始化、集群安装、CNI/CSI/Ingress部署 | 部署清单签名、组件镜像摘要 | ClusterAdmin、NodeOperator |
| 升级 | 控制面升级、节点池滚动升级、组件升级 | 升级包版本校验、回滚预案 | ClusterAdmin、NamespaceAdmin |
| 扩缩容 | 节点池扩缩、HPA/VPA配置、资源配额调整 | 节点模板校验、资源限额检查 | ClusterAdmin、NamespaceEditor |
| 备份恢复 | etcd备份、PV数据备份、集群配置备份 | 备份包完整性校验、恢复演练报告 | BackupOperator、Auditor |
| 退役 | 节点下线、集群销毁、数据清理、审计归档 | 退役清单确认、残留资源扫描 | ClusterAdmin、Auditor |
最佳实践:在每个阶段切换时,应执行一次完整的RBAC权限审计,确保运维发布包的签名者、审批者、执行者符合最小权限原则。建议使用
kubectl auth can-i --list配合自定义策略引擎进行自动化校验。
4.2 阶段一:规划(Planning)
规划阶段是集群生命周期的起点,决定了后续所有阶段的成败。核心工作包括:
- 版本选型:根据业务需求选择K8s版本(建议选择社区维护的稳定版本),并确认与CNI、CSI、Ingress Controller等组件的兼容性。
- 资源估算:基于业务负载预估节点数量、CPU/内存规格、存储容量、网络带宽。
- 网络方案:选择Pod网络CIDR、Service CIDR、Node网络规划,确定CNI插件(Calico、Cilium、Flannel等)。
- 存储方案:设计持久化存储后端(NFS、Ceph、云厂商块存储),规划StorageClass与PV回收策略。
- RBAC策略设计:定义集群角色、命名空间角色、ServiceAccount与绑定关系。
规划阶段发布包校验清单:
# 校验版本兼容性矩阵
k8s-version: 1.28.7
cni-plugin: calico v3.27.0
csi-driver: csi-hostpath v1.12.0
ingress-controller: nginx-ingress v1.9.0
# 校验资源配额模板
apiVersion: v1
kind: ResourceQuota
metadata:
name: default-quota
namespace: production
spec:
hard:
requests.cpu: "100"
requests.memory: "200Gi"
limits.cpu: "200"
limits.memory: "400Gi"
persistentvolumeclaims: "50"
pods: "200"
4.3 阶段二:部署(Deployment)
部署阶段将规划转化为实际集群。关键步骤包括:
- 节点初始化:操作系统配置、容器运行时安装(containerd/CRI-O)、内核参数调优。
- 控制面部署:使用kubeadm或二进制方式部署API Server、Controller Manager、Scheduler、etcd集群。
- 工作节点加入:节点认证、kubelet配置、kube-proxy部署。
- 网络与存储插件:部署CNI插件、CSI驱动、CoreDNS、Ingress Controller。
- 集群验证:运行一致性测试、节点健康检查、Pod调度验证。
安全警告:部署阶段使用的所有二进制文件、容器镜像、配置文件必须经过签名校验。建议使用
cosign或gpg对发布包进行数字签名,并在部署前验证签名有效性。禁止使用来源不明的组件。
# 部署阶段发布包校验示例
# 1. 校验kubeadm二进制签名
cosign verify-blob --key k8s-release.pub kubeadm
# 2. 校验组件镜像摘要
docker pull registry.k8s.io/kube-apiserver:v1.28.7
docker image inspect --format='{{index .RepoDigests 0}}' registry.k8s.io/kube-apiserver:v1.28.7
# 3. 校验部署清单签名
gpg --verify cluster-manifest.yaml.sig cluster-manifest.yaml
4.4 阶段三:升级(Upgrade)
集群升级是风险最高的运维操作之一。升级策略应遵循以下原则:
- 版本跳跃限制:每次升级最多跨越一个次要版本(如1.27→1.28,不可1.27→1.29)。
- 控制面优先:先升级控制面节点,再升级工作节点。
- 滚动升级:工作节点分批升级,每批不超过节点总数的25%。
- 回滚预案:升级前必须备份etcd快照,并准备回滚脚本。
| 升级组件 | 升级顺序 | 校验命令 | 回滚方式 |
|---|---|---|---|
| etcd | 1 | etcdctl endpoint health |
从快照恢复 |
| kube-apiserver | 2 | kubectl get --raw /healthz |
回退二进制版本 |
| kube-controller-manager | 3 | kubectl get cs |
回退二进制版本 |
| kube-scheduler | 4 | kubectl get pods -n kube-system |
回退二进制版本 |
| kubelet + kube-proxy | 5(分批) | kubectl get nodes |
节点驱逐后回退 |
4.5 阶段四:扩缩容(Scaling)
扩缩容包括节点层面的水平扩缩和Pod层面的自动伸缩。运维发布包需要校验以下内容:
- 节点池模板:虚拟机规格、镜像版本、初始化脚本、标签与污点配置。
- Cluster Autoscaler配置:最小/最大节点数、扩缩容阈值、不可调度节点处理策略。
- HPA/VPA配置:目标指标、最小/最大副本数、资源请求与限制比例。
- 资源配额调整:确保扩缩容后命名空间资源配额不超限。
扩缩容发布包校验示例:
# 校验节点池模板
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
name: worker-pool-1
spec:
replicas: 3
template:
spec:
version: v1.28.7
providerSpec:
value:
instanceType: Standard_D8s_v3
osDisk:
diskSizeGB: 128
# 校验HPA配置
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: web-app-hpa
namespace: production
spec:
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
4.6 阶段五:备份恢复(Backup & Restore)
备份恢复是集群容灾的最后防线。核心策略包括:
| 备份对象 | 备份频率 | 备份工具 | 恢复RTO | 恢复RPO |
|---|---|---|---|---|
| etcd数据 | 每小时 | etcdctl snapshot | < 5分钟 | < 1小时 |
| 集群配置(YAML) | 每天 | Velero / Ark | < 30分钟 | < 24小时 |
| PV数据 | 按业务需求 | Velero + CSI Snapshot | < 1小时 | < 1小时 |
| 审计日志 | 实时 | Fluentd + 对象存储 | 按需 | 实时 |
关键校验:备份包必须包含完整性校验值(SHA256或HMAC),恢复前需验证备份包未被篡改。建议每月执行一次恢复演练,并生成演练报告作为运维发布包的组成部分。
# 备份包完整性校验流程
# 1. 计算备份文件哈希
sha256sum etcd-snapshot-20250315.db > etcd-snapshot-20250315.db.sha256
# 2. 使用私钥签名哈希
gpg --detach-sign --armor etcd-snapshot-20250315.db.sha256
# 3. 恢复前验证
gpg --verify etcd-snapshot-20250315.db.sha256.asc etcd-snapshot-20250315.db.sha256
sha256sum -c etcd-snapshot-20250315.db.sha256
4.7 阶段六:退役(Retirement)
集群退役是生命周期中容易被忽视但至关重要的阶段。退役操作必须确保数据安全、资源释放和审计合规:
- 节点下线:先驱逐Pod(
kubectl drain),再删除节点(kubectl delete node),最后释放云资源。 - 数据清理:PV数据安全擦除、etcd数据清理、审计日志归档。
- 集群销毁:删除所有工作负载、命名空间、CRD、RBAC绑定,最后销毁控制面。
- 残留资源扫描:使用自定义脚本扫描未被清理的云资源(负载均衡器、磁盘、VPC等)。
- 审计归档:导出集群操作日志、RBAC变更记录、发布包签名记录,保存至合规存储。
退役发布包校验要点:
- 退役清单必须经过至少两级审批(运维负责人 + 安全审计员)。
- 所有退役操作必须记录操作人、时间、操作内容,并生成不可篡改的审计日志。
- 退役完成后,执行
kubectl get all -A确认无残留资源。 - 云资源层面,使用Provider CLI(如
aws resourcegroupstaggingapi)扫描未释放资源。
4.8 生命周期各阶段RBAC校验矩阵
运维发布包在每个阶段都需要绑定明确的RBAC权限校验。下表总结了各阶段的最小权限要求:
| 生命周期阶段 | 必需ClusterRole | 必需NamespaceRole | 发布包签名要求 | 审批层级 |
|---|---|---|---|---|
| 规划 | cluster-admin | — | 规划文档签名 | 架构师 + 安全 |
| 部署 | cluster-admin | namespace-admin | 二进制 + 镜像签名 | 运维负责人 |
| 升级 | cluster-admin | namespace-admin | 升级包双重签名 | 运维负责人 + 测试 |
| 扩缩容 | cluster-admin | namespace-editor | 模板配置签名 | 运维负责人 |
| 备份恢复 | cluster-admin | backup-operator | 备份包完整性校验 | 备份管理员 |
| 退役 | cluster-admin | namespace-admin | 退役清单签名 | 运维 + 审计 |
RBAC校验自动化建议:使用
kubectl auth reconcile命令结合自定义准入控制器(ValidatingAdmissionWebhook),在运维发布包应用到集群前自动校验操作者是否具备对应阶段的RBAC权限。示例准入策略:
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: lifecycle-rbac-check
spec:
matchConstraints:
resourceRules:
- apiGroups: ["*"]
apiVersions: ["*"]
operations: ["CREATE", "UPDATE", "DELETE"]
validations:
- expression: "has(object.metadata.annotations['lifecycle-phase'])"
message: "所有运维操作必须标注生命周期阶段"