K8s etdc备份恢复和集群升级证书更新

一句话理解 etcd

etcd 是 Kubernetes 集群的"数据库" ，所有集群信息（比如 Pod、Service、节点状态等）都存在里面。如果 etcd 坏了或数据丢了，整个集群就废了。所以定期备份 etcd 非常重要，就像给电脑系统做"还原点"一样。

备份恢复的核心命令

文档里用的工具叫 etcdctl，可以把它理解为 etcd 的"命令行客户端"。

1. 生成快照（备份）

bash

复制代码

etcdctl snapshot save 备份文件.db

比如：etcdctl snapshot save snap.db

这会把 etcd 当前所有数据保存成一个文件。

2. 查看快照信息

bash

复制代码

etcdctl snapshot status 备份文件.db -w table

可以看看备份文件有多大、里面有多少个 key 等。

3. 恢复快照（还原）

先要停止 etcd 和 apiserver ，然后删除旧的 etcd 数据目录 （比如 /var/lib/etcd），再用命令恢复：

bash

复制代码

etcdctl snapshot restore 备份文件.db --data-dir=/var/lib/etcd

两种常见场景的恢复步骤（大白话版）

场景一：单 master 集群（只有一个控制节点）

提前做备份 ：用 snapshot save 生成一个快照文件。
制造一点测试数据（比如创建几个 nginx Pod），证明集群在跑。
模拟灾难 ：停掉 etcd 和 apiserver（把 /etc/kubernetes/manifests 目录移走，kubelet 就会停掉这些容器）。
删掉旧数据目录 ：mv /var/lib/etcd /var/lib/etcd.bak（相当于清空数据库）。
用备份恢复 ：执行 snapshot restore，把数据写回 /var/lib/etcd。
重新启动 ：把 manifests 目录恢复回来，kubelet 会自动拉起 etcd 和 apiserver。
检查结果：备份之后新建的 Pod 会丢失，备份之前存在的 Pod 会回来。

👉 简单说：删除旧数据 → 把备份文件"解压"到数据目录 → 重启服务 → 集群回到备份时的状态。

场景二：多 master 集群（多个控制节点，etcd 集群）

多 master 时，etcd 是集群模式，所有 master 上的 etcd 数据是一致的。恢复时要用同一份快照文件 ，在每个 master 节点上分别恢复，并且要指定各自的节点名称和地址。

步骤和单 master 类似，只是多了一步：

恢复命令里要加上 --name=节点名、--initial-cluster=所有节点列表 等参数，告诉 etcd 集群谁是谁。

👉 注意：多 master 恢复时，所有 master 必须用同一份快照，否则集群会乱。

一些重要的"小贴士"（大白话）

备份一定要定期做，最好配成定时任务（cronjob）。
恢复前必须先停掉 etcd 和 apiserver，不然正在写入的数据会捣乱。
恢复后，备份时间点之后新建的资源会丢失（比如你备份后创建的 Pod 就没了），所以恢复相当于"时光倒流"。
etcdctl 命令如果报证书错误，需要指定证书文件路径，文档里给了环境变量的设置方法，照抄就行。
恢复时要用 --data-dir 指定新的数据目录，目录里不能有旧数据。

总结一句话

etcd 是 K8s 的命根子，一定要备份 。

备份用 snapshot save，恢复用 snapshot restore，恢复前停服务、删旧数据，恢复后重启，集群就回到备份时的状态。

多 master 集群要在每个 master 上用同一份备份文件分别恢复。

一句话理解升级

Kubernetes 集群像一辆车，定期需要"保养升级"来获得新功能和安全补丁。升级时不能直接熄火 ，而要逐个节点轮着来，保证车子一直能跑。

升级前的准备

备份集群数据（尤其是 etcd，上一篇文档讲过了）。
确认当前版本和目标版本（示例：从 v1.28.15 → v1.29.15）。
看看官方文档，不同版本可能有特殊要求。

升级 master 节点（控制平面）

master 节点是"司机"，先升级它。

步骤详解

步骤	做什么	大白话解释
1	更新 `kubeadm` 工具	把升级用的"扳手"换成新版本。
2	运行 `kubeadm upgrade plan`	让系统检查能不能升、会升哪些组件。
3	运行 `kubeadm upgrade apply v1.29.15`	正式升级 master 上的 api-server、scheduler 等核心组件。
4	执行 `kubectl drain <master节点名>`	把该节点上的普通 Pod 赶到其他节点上，避免服务中断。
5	升级 `kubelet` 和 `kubectl`	用 `yum update -y kubelet`，让节点上的"小工"也升到新版本。
6	重启 kubelet	`systemctl restart kubelet`，让新版本生效。
7	执行 `kubectl uncordon <master节点名>`	重新允许 Pod 调度到这个节点，恢复服务。

注意：多 master 集群需要逐个对每个 master 节点执行上述步骤。

升级 worker 节点（工作节点）

worker 节点是"乘客车厢"，在 master 升级完后再升。

步骤详解

步骤	做什么	大白话解释
1	在 worker 节点上执行 `kubeadm upgrade node`	更新节点上的 kubelet 配置，准备升级。
2	回到 master 节点，执行 `kubectl drain <worker节点名>`	把该 worker 上的 Pod 安全地迁走。
3	在 worker 节点上升级 kubelet	`yum update -y kubelet`。
4	重启 kubelet	`systemctl restart kubelet`。
5	回到 master 节点，执行 `kubectl uncordon <worker节点名>`	允许新 Pod 再调度回来。

重复上述步骤，一次升级一个 worker 节点，直到所有节点都升完。

升级过程中的"小工具"命令

命令	作用
`kubectl get node`	查看节点状态和版本。
`kubectl get pod -o wide	grep <节点名>`
`kubectl drain <节点> --ignore-daemonsets`	排空节点（把 Pod 迁走），`--ignore-daemonsets` 跳过系统级 Pod。
`kubectl uncordon <节点>`	恢复节点可调度。
`kubeadm upgrade plan`	查看升级计划和可能的障碍。
`kubeadm upgrade diff 1.29.15`	对比新旧配置文件的差异。

升级后的检查

集群状态 ：kubectl get nodes 看所有节点是否 Ready。
Pod 状态 ：kubectl get pods -A 看有没有 CrashLoopBackOff 之类的错误。
应用程序：访问你的业务服务，确认功能正常。
查看日志 ：如果出问题，用 kubectl logs 或 journalctl -u kubelet 看日志。

如果升级失败怎么办？

回滚：用旧版本的二进制文件替换回来，或者从备份的 etcd 恢复。
提前测试：建议先在测试环境演练一遍。
官方文档：不同版本细节可能不同，以官方指南为准。

总结一句话

升级 K8s 集群要 先升 master，再升 worker ，每个节点升级前要 排空 Pod ，升级完再 允许调度 。全程保持集群可用，一个个节点轮着来。别忘了提前备份 etcd！

一句话理解证书更新

Kubernetes 的证书就像"身份证"，有效期内集群才能正常通信。证书过期了，集群就"锁门"了。所以定期更新证书很重要，就像换新身份证一样。

推荐方式：用 kubeadm 自动更新（最简单）

适用于用 kubeadm 安装的集群（绝大多数测试和生产环境都用这个）。

步骤（大白话版）

步骤	命令	大白话解释
1	`kubeadm certs check-expiration`	看看所有证书的"有效期还剩多久"。
2	`sudo kubeadm certs renew all`	一键更新所有证书，自动完成。
3	`kubeadm certs check-expiration`	再次检查，确认有效期已经刷新。
4	重启相关组件	让集群用上新证书（比如重启 `kubelet` 或删除静态 Pod 让它重建）。

注意：更新后必须重启组件，否则新证书不会生效。

手动方式（非 kubeadm 部署，比如自己搭的集群）

适用于自己用二进制文件或其他方式部署的集群 ，没有 kubeadm 帮你自动弄。

简化步骤

检查哪些证书快过期

bash
复制代码
```
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -text | grep "Not After"
```
看输出里的日期，就知道啥时候过期。

用 openssl 工具生成新证书（比如 apiserver 的证书）

bash

复制代码

openssl genrsa -out apiserver.key 2048
openssl req -new -key apiserver.key -out apiserver.csr -subj "/CN=kube-apiserver"
openssl x509 -req -in apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out apiserver.crt -days 365

其他组件（controller-manager、scheduler 等）类似。

把新证书覆盖到 /etc/kubernetes/pki/ 目录（替换旧文件）。
重启对应组件 （比如 systemctl restart kube-apiserver）。
验证：用 kubectl get nodes 看集群是否正常。

工作节点（worker）证书也要更新

工作节点上的 kubelet 和 kube-proxy 也有自己的证书。
步骤类似：生成新证书 → 复制到 /var/lib/kubelet/pki/ → 重启 kubelet。

重要注意事项（别踩坑）

更新前一定备份证书

bash
复制代码
```
tar -czvf /root/kubernetes-pki-backup.tar.gz /etc/kubernetes/pki
```
万一新证书搞错了，还能恢复。
所有节点时间要同步

证书依赖系统时间，如果节点时间不对，新证书可能被当作无效。
更新后一定要验证
- kubectl get nodes 看节点状态
- kubectl get pods -A 看 Pod 是否正常
- 如果出问题，检查日志并用备份恢复。

总结一句话

用 kubeadm 的集群，一条命令 kubeadm certs renew all 就能自动更新证书，更新后记得重启组件。手动部署的集群需要用 openssl 一个个生成替换。更新前一定备份！

K8s etdc备份恢复 和 集群升级 证书更新

一句话理解 etcd

备份恢复的核心命令

1. 生成快照（备份）

2. 查看快照信息

3. 恢复快照（还原）

两种常见场景的恢复步骤（大白话版）

场景一：单 master 集群（只有一个控制节点）

场景二：多 master 集群（多个控制节点，etcd 集群）

一些重要的"小贴士"（大白话）

总结一句话

一句话理解升级

升级前的准备

升级 master 节点（控制平面）

步骤详解

升级 worker 节点（工作节点）

步骤详解

升级过程中的"小工具"命令

升级后的检查

如果升级失败怎么办？

总结一句话

一句话理解证书更新

推荐方式：用 kubeadm 自动更新（最简单）

步骤（大白话版）

手动方式（非 kubeadm 部署，比如自己搭的集群）

简化步骤

工作节点（worker）证书也要更新

重要注意事项（别踩坑）

总结一句话

K8s etdc备份恢复和集群升级证书更新