Ubuntu Kubernetes 集群升级如何操作

Ubuntu上Kubernetes集群升级操作指南（基于kubeadm）

一、升级前准备

1. 备份关键数据

升级前必须备份集群核心数据，作为回退兜底方案：

Etcd数据备份（存储集群元数据，如Pod、Deployment配置）：

kubectl -n kube-system exec -it etcd-<master-node-name> -- etcdctl snapshot save /var/lib/etcd/snapshot-$(date +%Y%m%d).db \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key # 将备份文件复制到本地 kubectl -n kube-system cp etcd-<master-node-name>:/var/lib/etcd/snapshot-$(date +%Y%m%d).db ./

集群配置文件：备份/etc/kubernetes/目录下的admin.conf、controller-manager.conf、scheduler.conf及证书文件（如ca.crt、apiserver.crt）。
有状态应用数据：若有状态应用（如MySQL、Elasticsearch），通过应用自身机制（如MySQL主从备份、Elasticsearch快照）备份业务数据。

2. 检查集群健康状态

确保集群处于可升级状态，避免因原有问题导致升级失败：

控制平面组件状态：检查API Server、Etcd、Controller Manager、Scheduler的Pod是否正常：

kubectl get pods -n kube-system -l component=kube-apiserver kubectl get pods -n kube-system -l component=etcd kubectl get pods -n kube-system -l component=kube-controller-manager kubectl get pods -n kube-system -l component=kube-scheduler

节点状态：所有节点需为Ready：
```
kubectl get nodes 
```

Pod运行状态：无CrashLoopBackOff、Error等异常状态的Pod：

kubectl get pods --all-namespaces --field-selector status.phase!=Running

3. 确认版本兼容性

Kubernetes不支持跨多个次要版本跳跃升级（如1.22→1.25），必须遵循“相邻次要版本递进”规则（如1.22→1.23→1.24→1.25）。升级前需：

通过kubectl version --short查看当前集群版本；
参考Kubernetes官方升级文档（如1.25升级文档），确认目标版本与当前版本的兼容性，以及周边组件（容器运行时、网络插件、Ingress控制器）的兼容性要求。

4. 升级kubeadm工具

kubeadm是官方推荐的集群升级工具，需先升级到目标版本：

# 更新apt源并安装指定版本的kubeadm（以Ubuntu为例） sudo apt update sudo apt-mark unhold kubeadm # 若之前锁定版本，需解锁 sudo apt install -y kubeadm=<target-version>-00 # 替换<target-version>为目标版本（如1.25.0） sudo apt-mark hold kubeadm # 锁定版本，避免自动升级 # 验证kubeadm版本 kubeadm version

二、核心升级步骤

1. 升级控制平面节点（Master节点）

控制平面是集群核心，升级需严格遵循“先升级组件，再重启服务”的顺序：

检查升级可行性：通过kubeadm upgrade plan命令查看目标版本是否可用，以及是否存在潜在问题（如组件兼容性、配置冲突）：
```
sudo kubeadm upgrade plan 
```
若输出提示“Components that must be upgraded manually after you have upgraded the control plane”（如容器运行时），需按提示提前处理。
执行控制平面升级：使用kubeadm upgrade apply命令升级控制平面组件（API Server、Controller Manager、Scheduler）及Etcd（若为kubeadm部署）：
```
sudo kubeadm upgrade apply v<target-version> # 替换<target-version>为目标版本（如v1.25.0） 
```
该命令会自动完成：
- 升级控制平面静态Pod配置（位于/etc/kubernetes/manifests/）；
- 升级Etcd集群（若为kubeadm部署）；
- 更新集群证书（若证书即将过期）。
重启kubelet服务：升级后，kubelet会自动重启控制平面组件，但部分场景需手动重启以确保生效：
```
sudo systemctl daemon-reload sudo systemctl restart kubelet 
```
验证控制平面状态：检查控制平面Pod是否均为Running：
```
kubectl get pods -n kube-system -l tier=control-plane 
```

2. 升级工作节点（Worker节点）

工作节点运行业务Pod，升级需采用“分批升级”策略（每次升级1-2个节点），避免全量升级导致业务中断：

标记节点为不可调度并驱逐Pod：避免升级过程中Pod被调度到该节点，DaemonSet Pod（如kube-proxy）需忽略：

kubectl cordon <worker-node-name> # 标记为不可调度 kubectl drain <worker-node-name> --ignore-daemonsets # 驱逐Pod（自动重新调度到其他节点）

升级节点组件：

升级kubeadm：确保节点kubeadm版本与控制平面一致：

sudo apt-mark unhold kubeadm sudo apt install -y kubeadm=<target-version>-00 sudo apt-mark hold kubeadm

升级节点配置：同步控制平面的升级配置：
```
sudo kubeadm upgrade node 
```

升级kubelet和kubectl：升级到目标版本：

sudo apt-mark unhold kubelet kubectl sudo apt install -y kubelet=<target-version>-00 kubectl=<target-version>-00 sudo apt-mark hold kubelet kubectl

重启kubelet服务：使升级生效：

sudo systemctl daemon-reload sudo systemctl restart kubelet

恢复节点调度并验证状态：

kubectl uncordon <worker-node-name> # 标记为可调度 kubectl get nodes # 验证节点状态为Ready，VERSION显示目标版本 kubectl get pods -o wide | grep <worker-node-name> # 验证业务Pod重新调度并正常运行

3. 分批升级工作节点

重复上述“升级工作节点”步骤，依次升级所有工作节点，确保集群始终有足够节点承载业务流量。

三、升级后验证

升级完成后，需全面验证集群功能及业务状态：

集群组件状态：检查所有核心组件（kube-apiserver、kube-controller-manager、kube-scheduler、kubelet）是否正常：
```
kubectl get componentstatuses 
```
Pod运行状态：确保所有Pod均为Running，无异常状态：
```
kubectl get pods --all-namespaces 
```
网络功能：验证Service、Ingress是否正常访问（如通过curl测试Ingress端点）。
业务功能：检查业务应用是否正常运行（如访问应用接口、验证数据一致性）。

四、常见问题解决

升级失败：若升级过程中出现错误（如组件兼容性问题），可通过kubeadm upgrade plan查看具体原因，按提示修复后重新执行升级。
节点无法恢复：若节点升级后无法加入集群，可尝试重新运行kubeadm reset重置节点，再重新加入集群（需确保控制平面正常）。
Etcd数据丢失：若Etcd备份失败或数据损坏，可通过备份文件恢复（参考etcdctl snapshot restore命令）。

注：以上步骤基于kubeadm部署的Kubernetes集群，若使用其他部署工具（如kops、Sealos），需参考对应工具的升级文档。升级前务必在测试环境验证步骤，确保符合业务需求。