Skip to main content

K8s 介绍

基本结构

Kubernetes(简称 K8s)采用 Master/Node(控制面 / 工作节点) 的架构: Master 节点:集群的大脑,负责管理和调度,保证系统运行在预期状态。 Node 节点(工作节点):负责运行实际的业务容器(Pod)。 etcd:独立存储集群状态的分布式键值数据库。 K8s 可以部署成 单 Master(测试/小规模)或 多 Master 高可用(生产环境)。

Master 节点组件

kube-apiserver
  • 唯一对外接口,所有操作都通过 API Server 进行(kubectl、UI、控制器都要调用它)。
  • 负责认证、授权、访问控制,把对象状态写入 etcd。
etcd
  • 高可用键值数据库,保存集群的所有配置、状态信息。
  • 类似 K8s 的“大脑存储”。
kube-scheduler
  • 调度器,负责选择合适的 Node 来运行新建的 Pod。
  • 根据资源、亲和性、污点等规则来分配 Pod。
kube-controller-manager
  • 控制器集合,负责“自动化管理”:
    • Node 控制器(发现节点故障并重调度 Pod)
    • Replication 控制器(保证副本数一致)
    • Endpoint 控制器、命名空间控制器等。

Node 节点组件

kubelet
  • 运行在每个 Node 上,负责:
    • 和 API Server 通信
    • 管理本机 Pod 的生命周期(创建、启动、停止容器)
    • 上报节点状态。
kube-proxy
  • 网络代理,负责 Service 的负载均衡与转发
  • 保证访问 Service 时能正确路由到对应 Pod。
容器运行时(Container Runtime)
  • 负责启动和管理容器,例如 Docker(已逐步弃用)、containerd、CRI-O。
CoreDNS
  • 集群内置的 DNS 服务,负责 服务发现
CNI 网络插件(如 Calico、Flannel)
  • 提供跨节点 Pod 网络互通和网络策略。

辅助工具

  • kubectl:命令行管理工具,直接和 kube-apiserver 交互。
  • Dashboard:可选的 Web UI。

核心资源

工作负载类(Workloads)

  • Pod:最小的运行单元,封装一个或多个容器。
  • ReplicaSet:确保指定数量的 Pod 副本数运行。
  • Deployment:声明式管理应用的部署与滚动升级(基于 ReplicaSet)。
  • StatefulSet:用于有状态服务,提供稳定的网络标识和存储。
  • DaemonSet:确保每个(或指定)节点上运行一个 Pod(常用于日志、监控代理)。
  • Job:一次性任务,保证任务完成。
  • CronJob:定时任务,按时间周期调度 Job。

服务发现与负载均衡(Service Discovery & Load Balancing)

  • Service:为一组 Pod 提供稳定访问入口(ClusterIP、NodePort、LoadBalancer)。
  • Endpoints:Service 实际对应的 Pod IP 列表。
  • Ingress:提供 HTTP/HTTPS 的七层路由入口。

配置与存储(Configuration & Storage)

  • ConfigMap:保存非机密的配置数据,挂载到 Pod。
  • Secret:保存敏感数据(密码、证书、Token)。
  • Volume:Pod 使用的存储抽象。
  • PersistentVolume (PV):集群级别的持久化存储资源。
  • PersistentVolumeClaim (PVC):用户申请存储的声明。
  • StorageClass:定义存储卷的动态供应策略。

集群资源与节点管理(Cluster & Node Management)

  • Node:集群中的工作节点。
  • Namespace:逻辑上的资源隔离。
  • ResourceQuota:限制命名空间下的资源用量。
  • LimitRange:限制 Pod 或容器的资源请求/上限。

安全与访问控制(Security & Access Control)

  • ServiceAccount:Pod 在集群内的身份标识。
  • Role / ClusterRole:定义资源的访问权限。
  • RoleBinding / ClusterRoleBinding:将角色绑定到用户/组/ServiceAccount。
  • NetworkPolicy:限制 Pod 之间或 Pod 与外部的网络通信。

kubeadm安装单master的K8s

节点分布

所有系统均用ubuntu24.04搭建 所有节点按照如下图配置 Image 20250919202446018

系统初始化

操作节点:[所有节点]

免密脚本

操作节点:[所有节点]

安装docker

操作节点:[所有节点]
运行脚本 28.4.0是docker的最新版本 要更改版本可以看这里 https://download.docker.com/linux/static/stable/x86_64/
验证

安装cri-docker

操作节点:[所有节点]
运行
验证

配置k8s源并安装k8s基础工具

操作节点:所有节点 自行修改版本,版本查看网站:https://mirrors.aliyun.com/kubernetes-new/core/stable/ 这里安装最新版:1.34
Kubeadm: kubeadm 是一个工具,用来初始化 k8s 集群的 kubelet: 安装在集群所有节点上,用于启动 Pod 的 kubectl: 通过 kubectl 可以部署和管理应用,查看各种资源,创建、删除和更新各种组件 kubelet暂时不会启动,等后面安装完k8s组件就会正常启动
验证

初始化集群

操作节点:master1
--kubernetes-version=1.34.1 指定安装的 Kubernetes 版本 --apiserver-advertise-address=192.168.48.128 设置 API Server 对外通信的 IP 地址(Master 节点 IP)。 --image-repository=registry.aliyuncs.com/google_containers 指定 镜像仓库地址(国内用阿里云替代 gcr.io,避免拉取失败)。 --pod-network-cidr=10.244.0.0/16 设置 Pod 网络网段,常配合 Flannel 使用。 --service-cidr=10.96.0.0/12 设置 Service 网络网段,和 Pod 网段必须不重叠。 --cri-socket=unix:///var/run/cri-dockerd.sock 指定 容器运行时接口 (CRI) 的 socket,这里用 cri-dockerd 来支持 Docker。 生成信息
设置环境变量
如果想重置就输入这个

node节点加入集群

根据前面master节点初始化信息,里面有如下信息,通过这个给所有node节点加入集群,还要再结尾加上--cri-socket=unix:///var/run/cri-dockerd.sock

安装calico

操作节点:master1 网络组件有很多种,只需要部署其中一个即可,推荐Calico。 Calico是一个纯三层的数据中心网络方案,Calico支持广泛的平台,包括Kubernetes、OpenStack等。 Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器( vRouter) 来负责数据转发,而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。 此外,Calico 项目还实现了 Kubernetes 网络策略,提供ACL功能
calico文件可能下载不下来,你直接魔法下载,然后上传到虚拟机计科
要等很久,之后就是如下情况,全是ready,全是running,才说明k8s安装成功

安装dashboard

运行
验证,两个都是running
创建token,直接全选复制运行
这时候就会提示你 ✅ kubeconfig 文件已生成:dashboard-kubeconfig.yaml 你就把这个文件上传到dashboard的kubeconfig就可以免密登入了 访问页面https://192.168.48.128:30001 Image 20250919232423512

修改mode支持ipvs

修改器请确认你的机子是否支持ipvs,我已经在2.2 系统初始化的脚本里设置了ipvs功能,你要是没用我的,你可以自行看看脚本,或者自行配置
那这样他是不支持ipvs要进行修改
然后修改为mode: "ipvs" Image 20250927203606943 重启kube-proxy Pods
检查是否可用

验证是否可以创建服务

k8s单master安装成功

模拟Token过期重新生成并加入Node节点

假设加入集群的token过期了。node01无法加入了,这里就模拟一下这种情况
  1. Token过期后生成新的token:
其中,192.168.48.200:16443 是你的 Kubernetes API 服务器的地址和端口,tn5q1b.7w1jj77ewup7k2in 是新的令牌,sha256:cc5427e0e133d95250ab0aa90976fea2c383278b6345fd7e8c28702ac8dfc61f 是令牌的 CA 证书哈希值。
  1. Master需要生成—certificate-key:
其中,5d3706028d5e569324a4c456c81ae0f5551ece88b3132f03917668c6b0605128 是证书密钥。
  1. 生成新的Token用于集群添加新Node节点
操作节点[node01]
注意:这里末尾添加了--cri-socket unix:///var/run/cri-dockerd.sock image-20231110181623386 这时在master查看node状态(显示为notready不影响) image-20231111145807000

模拟新加master节点的加入K8S集群中

假设我们新加master节点的话,就拼接token,从刚刚生成的token拼接
这里提取信息1
接着
这里提取信息2:这里前面要加上--control-plane --certificate-key
合成
注意:这里末尾添加了--cri-socket unix:///var/run/cri-dockerd.sock 图示 image-20231110182741430

kubeadm部署高可用K8s

请前往https://blog.qianyios.top/tags/K8s/ 我的文章里会有一些高可用的,有centos,openeuler,但是没有ubuntu,都差不多的

二进制安装高可用K8S

节点分布

所有系统均用ubuntu24.04搭建 所有节点按照如下图配置 image-20250919202446018

系统初始化

操作节点:[所有节点]

免密脚本

操作节点:[所有节点]

负载均衡部署

操作节点:master1和master2
操作节点:master1
操作节点:master2
master1和master2启动

部署etcd集群

操作节点:master1 全选复制运行
然后在所有的master执行
验证健康性 操作节点 :master1
这是正常的情况 image-20250920013623278

安装k8s组件

https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG 本次安装的是最新版1.34.1 Image 20250920014033286 image-20250920014305570 操作节点:master1

检测组件监控脚本

部署 apiserver 组件

1️⃣ 创建 kubelet bootstrap 配置文件 操作节点:[master1] 作用:让 kubelet 自动向 apiserver 申请证书,避免手动签发大量客户端证书。 首次启动时,kubelet 使用 bootstrap.kubeconfig 配置文件里的 Token 与 apiserver 建立 TLS 连接。 Bootstrap 配置示例(kubelet 使用):
2️⃣ 创建 bootstrap token 操作节点:[master1] 作用
  • 这个 token 用于 kubelet 首次请求 apiserver 时进行身份认证。
  • 生成随机 token,指定用户名、UID、用户组。
3️⃣ 创建 kube-apiserver CSR 文件 操作节点:[master1] 作用
  • 用于生成 apiserver 的证书,确保 apiserver 与节点之间的 TLS 通信安全。
  • hosts 字段中必须包含所有 master 节点 IP 和服务网络首个 IP(service-cluster-ip-range 的第一个 IP)。
说明: 如果 hosts 字段不为空则需要指定授权使用该证书的 IP(含VIP) 或域名列表。由于该证书被 集群使用,需要将节点的IP都填上,为了方便后期扩容可以多写几个预留的IP。同时还需要填写 service 网络的首个IP(一般是 kube-apiserver 指定的 service-cluster-ip-range 网段的第一个IP,如 10.96.0.1)。
4️⃣ 生成 apiserver 证书 操作节点:[master1]
生成文件:
  • kube-apiserver.pem(证书)
  • kube-apiserver-key.pem(私钥)
5️⃣ 创建 apiserver 配置文件 操作节点:[master1] 作用: 定义 apiserver 启动参数,包括 TLS、etcd、RBAC、service IP 范围、审计日志等。 master1 配置示例:
6️⃣ 创建 systemd 服务文件 操作节点:[master1]
7️⃣ 同步文件到所有 master 节点 操作节点:[master1]
8️⃣ 启动 apiserver
9️⃣ 验证

部署 kubectl 组件

kubectl 是 Kubernetes 的客户端命令工具,用于对集群资源进行增删改查等操作。 在使用 kubectl 时,需要指定要连接的集群信息和认证方式,这些信息保存在 kubeconfig 文件中。 1️⃣ 1. 创建 admin 证书签名请求文件 admin 证书用于后续生成 kubeconfig 文件,代表集群管理员身份。 注意:O 字段必须为 system:masters,否则无法绑定到 cluster-admin 权限。
说明: 这个admin 证书,是将来生成管理员用的kubeconfig 配置文件用的,现在我们一般建议使用RBAC 来对kubernetes 进行角色权限控制, kubernetes 将证书中的CN 字段 作为User, O 字段作为 Group; “O”: “system:masters”, 必须是system:masters,否则后面kubectl create clusterrolebinding报错。
2️⃣ 生成 admin 证书和密钥
3️⃣生成 kubeconfig 配置文件
4️⃣拷贝配置文件到默认路径
5️⃣授权 admin 证书访问 kubelet API
6️⃣验证 kubectl 是否可用
image-20250920194637063 7️⃣同步配置到其他 Master 节点
8️⃣配置命令补全

部署 kube-controller-manager 组件

1️⃣ 创建 CSR 请求文件 在 master1 执行
说明: hosts 列表包含所有 kube-controller-manager 节点 IP; CN 为 system:kube-controller-manager、O 为 system:kube-controller-manager,kubernetes 内置的 ClusterRoleBindings system:kube-controller-manager 赋予 kube-controller-manager 工作所需的权限
2️⃣ 生成证书和私钥
生成的文件包括:
  • /etc/kubernetes/ssl/kube-controller-manager.pem
  • /etc/kubernetes/ssl/kube-controller-manager-key.pem
3️⃣ 创建 kubeconfig 文件
4️⃣ 创建配置文件
5️⃣ 创建 systemd 启动文件
6️⃣ 分发文件到其他 master
7️⃣ 启动服务 在所有 master 节点执行:
8️⃣ 验证

部署 kube-scheduler组件

1️⃣ 生成证书和 kubeconfig 1.1 创建 CSR 请求 在 master1 节点(证书统一生成处)执行:
说明:
CN=system:kube-schedulerO=system:kube-scheduler,这是 Kubernetes 内置的 RBAC 绑定角色,必须保持一致。
1.2 生成证书和私钥
生成的文件: kube-scheduler.pem —— scheduler 客户端证书 kube-scheduler-key.pem —— scheduler 私钥
1.3 生成 kubeconfig kubeconfig 是 scheduler 访问 kube-apiserver 的配置文件。
2️⃣ 创建配置文件
3️⃣ 创建 systemd 服务文件
4️⃣ 分发文件到其他 master 节点
5️⃣ 启动服务 在 三个 master 节点执行:
6️⃣ 验证 全绿

导入镜像

操作节点:node01

安装docker

操作节点:[所有node节点] 我是给所有节点都安装,因为我想master也能运行pod,所以如果你不想你可以不安装,包括在后面给node节点安装kubelet和kube-proxy的时候也要注意一下节点信息,我的代码里会有一些简简单单的主机列表,你可以自行删除
运行脚本 28.4.0是docker的最新版本 要更改版本可以看这里 https://download.docker.com/linux/static/stable/x86_64/
验证

安装cri-docker

我是给所有节点都安装,因为我想master也能运行pod,所以如果你不想你可以不安装,包括在后面给node节点安装kubelet和kube-proxy的时候也要注意一下节点信息,我的代码里会有一些简简单单的主机列表,你可以自行删除 操作节点:[所有node节点]
运行 0.3.20是版本,如果要改请前往https://github.com/Mirantis/cri-dockerd/releases查看版本
验证

部署 kubelet 组件

kubelet: 每个 Node 节点上的 kubelet 定期就会调用 API Server 的 REST 接口报告自身状态,API Server 接收这些信息后,将节点状态信息更新到 etcd 中。kubelet 也通过 API Server 监听 Pod 信息,从而对 Node 机器上的 POD 进行管理,如创建、删除、更新 Pod 1️⃣ 在 master1 节点生成 kubelet bootstrap kubeconfig 作用:kubelet 启动时使用 bootstrap kubeconfig 向 API Server 请求证书,完成节点注册。
2️⃣ 创建 kubelet.json 配置文件
作用:kubelet 的主要配置,包括认证、授权、IP 地址、端口、cgroupDriver、集群域名和 DNS 等信息。 注意:address 替换为节点实际 IP,cgroupDriver 与 Docker 一致。
操作节点:[master1] 这里用脚本生成所有节点的文件,这样后续可以加入集群
3️⃣ 创建 systemd kubelet 服务文件
作用:定义 kubelet 系统服务,启动时使用 bootstrap kubeconfig 申请证书,并使用配置文件和证书目录。
操作节点:[所有的node节点]
关于容器运行时的说明: 如果使用的是containerd,则—container-runtime-endpoint设置为:unix:///run/containerd/containerd.sock
4️⃣ 分发文件到各节点
5️⃣ 所有节点运行
6️⃣ 在master1验证
Image 20250920205652956 #注意:STATUS 是 NotReady 表示还没有安装网络插件

部署 kube-proxy 组件

1️⃣ 创建 kube-proxy CSR 文件 操作节点:[master1 ]
2️⃣ 生成证书 操作节点:[master1]
生成文件: kube-proxy.pem(证书) kube-proxy-key.pem(私钥) 3️⃣创建 kube-proxy kubeconfig 操作节点:[master1]
说明:为 kube-proxy 创建独立的 kubeconfig 文件,确保能访问 API Server。 4️⃣ 创建 kube-proxy 配置文件 操作节点:[master1] 自动分发到所有节点
说明:这里 bindAddress 用每个节点的实际 IP,clusterCIDR 为 Pod 网段。 如果在 node01 上部署,IP 改为 192.168.48.10 如果在其他节点上部署,相应修改 bindAddress 5️⃣ 创建 kube-proxy systemd 服务文件 操作节点:[master1]
6️⃣ 将证书和kubeconfig复制到各节点 操作节点:[master1]
7️⃣所有节点运行

部署calico

操作节点:master1 网络组件有很多种,只需要部署其中一个即可,推荐Calico。 Calico是一个纯三层的数据中心网络方案,Calico支持广泛的平台,包括Kubernetes、OpenStack等。 Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的虚拟路由器( vRouter) 来负责数据转发,而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息向整个 Calico 网络内传播。 此外,Calico 项目还实现了 Kubernetes 网络策略,提供ACL功能
calico文件可能下载不下来,你直接魔法下载,然后上传到虚拟机计科
要等很久,之后就是如下情况,全是ready,全是running,才说明k8s安装成功 image-20250921004527351

coredne部署

操作节点:[master1]
验证

安装dashboard

运行
验证,两个都是running
创建token,直接全选复制运行
这时候就会提示你 ✅ kubeconfig 文件已生成:dashboard-kubeconfig.yaml 你就把这个文件上传到dashboard的kubeconfig就可以免密登入了 访问页面https://192.168.48.200:30001 image-20250919232423512

验证是否可以创建服务

二进制k8s高可用安装成功

集群运维实战

这一章讲的是:
  • 集群怎么“防翻车”(先备份)
  • 出问题怎么“拉回来”(恢复)
  • 证书快过期怎么处理(轮换)
  • 版本怎么稳妥升级,出问题怎么回滚
  • 平时怎么做故障演练,不到线上慌
你可以把这章理解成:
前面章节是“会搭”,这一章是“会养、会救、会演练”。

etcd 备份与恢复(重点中的重点)

先说大白话:
  • etcd 是 k8s 的“总账本”
  • 你创建的 Pod、Deployment、Service、Secret、ConfigMap 等元数据,最终都在 etcd 里
  • etcd 没了,控制面就会非常痛苦,严重时几乎等于“失忆”
所以,备份 etcd 不是可选项,是必选项。

kubeadm 部署:etcd 备份与恢复

适用特征:
  • kubeadm 命令
  • 常见目录有 /etc/kubernetes/pki
  • 多数情况下是静态 Pod etcd
先确认 etcd 形态:
如果你宿主机没有 etcdctl,优先直接在 etcd Pod 内执行快照:
如果你宿主机装了 etcdctl,也可以直接本机备份:
恢复(单控制面示例):
多控制面时建议“先恢复一个控制面验证,再逐台处理其余控制面”。

k3s 部署:etcd 备份与恢复

适用特征:
  • k3s server / k3s agent
  • 常用命令是 k3s etcd-snapshot ...
  • 不走 kubeadm 那套目录
这一段要先讲清楚三种形态:
  • 单 server 默认是 SQLite(不是 etcd)
  • 单 server 但首台用 --cluster-init,则启用的是内置 etcd
  • 多 server 高可用一般是:首台 --cluster-init,后续 server 用 --server + 同一 K3S_TOKEN 加入,自动进入同一个内置 etcd 集群
一句话记住:
--cluster-init 只在第一个 server 用一次;后续 server 不要再加这个参数。
情况 A:单 server 默认 SQLite
这种情况没有 etcd,k3s etcd-snapshot 相关操作不适用。 你要做的是系统级备份(例如 VM 快照、磁盘备份、配置备份)。
情况 B:单 server(启用内置 etcd)
先确认能用 etcd 快照命令:
手动备份:
备份出来如下
恢复示例:
情况 C:多 server(内置 etcd 高可用)
典型初始化:
备份(在任一可用 server 执行):
恢复建议顺序:
  • 先在目标 server 做 --cluster-reset --cluster-reset-restore-path
  • 该节点恢复稳定后,再让其他 server 重新加入/同步
恢复示例:
恢复后验证:

rke 部署:etcd 备份与恢复

先分清是 RKE1 还是 RKE2。
RKE1
在持有 cluster.yml 的运维机执行:
RKE2
备份:
恢复(示例):
验证:

备份与恢复通用建议

  • 每天至少一份快照,至少保留最近 7 天
  • 快照要异机留存(不要只放本机)
  • 恢复前先停相关服务,恢复后先看控制面健康再放业务
  • 出问题先看日志,不要多人同时改配置

证书轮换(别等过期再处理)

大白话:
  • 证书就像“门禁卡”
  • 过期了,不是慢一点,是直接进不去
  • 最怕的是你半夜才发现快过期

kubeadm 部署集群:证书轮换步骤

适用场景:
  • kubeadm 初始化的集群
  • 控制面证书在 /etc/kubernetes/pki
先检查证书剩余时间:
轮换控制面证书:
让组件加载新证书(建议每个控制面节点滚动执行):
验证:
补充一个常见坑:
  • kubeadm certs renew all 主要是控制面证书
  • 如果 kubelet.conf 已过期,或者 bootstrap-kubelet.conf 丢了,还要单独修 kubelet 证书链路
kubelet 证书链路排查:
必要时给 node 重建 kubelet kubeconfig:

k3s 部署集群:证书轮换步骤

适用场景:
  • k3s server / k3s agent 架构
  • 没有 kubeadm,走 k3s 自带命令
先检查证书:
执行证书轮换:
重启服务加载证书:
验证:
如果你是内置 etcd 的 k3s 高可用,建议轮换前后都做快照:

rke 部署集群:证书轮换步骤

你如果是 Rancher 系列,要先分清是 RKE1 还是 RKE2。
RKE1(rke up 那套)
先在保存 cluster.yml 的运维机检查集群:
执行证书轮换:
让变更生效:
验证:
RKE2(rke2 server/agent 那套)
检查证书:
轮换证书:
重启服务:
验证:
通用建议:
  • 证书轮换前先做备份(etcd 快照 + 配置备份)
  • 控制面节点尽量滚动重启,不要一起重启
  • 轮换后优先看 readyzkubectl get nodes、核心业务 Pod 状态

十年证书(谨慎使用)

你想做“十年证书”是可以理解的,但要先讲清楚:
  • 证书年限拉长会降低运维频率
  • 但也会拉长风险暴露窗口(密钥泄漏后的影响期更长)
所以建议优先:自动轮换 + 定期检查;十年证书只在明确合规允许、且有严格密钥管理时使用。
kubeadm 场景
如果你坚持做十年证书,常见做法有两种: 方式一:使用你文档里已经提到的脚本(最省事)
方式二:按你自己的 CA 策略重签发(可控但更复杂)
  • 需要统一重签控制面/组件证书
  • 需要滚动重启并逐项验证
k3s 场景
k3s 日常证书有自动续签机制,通常不需要手工改到 10 年。 重点边界:
  • k3s 可以做证书轮换:k3s certificate rotate
  • 但“直接把所有运行中证书一键改成十年”并不是标准日常操作
  • 若强制改年限,通常涉及 CA 重新规划/重建流程,风险高于收益
实操建议:
把“自动续签 + 月度巡检”作为主方案更稳。
rke / rke2 场景
RKE1/RKE2 一般建议走官方轮换机制,不建议直接拉长到十年作为默认策略。
  • RKE1:rke cert rotate
  • RKE2:rke2 certificate rotate
如果你必须十年,通常同样会落到“CA 与证书体系重建”级别,操作复杂、回滚成本高。
做十年证书前的最小检查清单
  • 是否有密钥托管方案(至少做到权限最小化 + 备份加密)
  • 是否有年度演练(证书故障演练、节点失联演练)
  • 是否有回滚方案(etcd 快照、配置版本、恢复手册)
一句话:
十年证书能做,但不是默认最佳实践;优先自动轮换,十年策略要配套更严格的安全与演练。

证书轮换建议

  • 提前 60 天开始检查
  • 提前 30 天完成演练环境轮换
  • 提前 15 天完成生产轮换
  • 不要卡到最后一周

版本升级与回滚(稳字当头)

核心原则:
  • 先备份,再升级
  • 先控制面,再工作节点
  • 一次只升一个小版本(按官方支持路径)
  • 每一步都要验证

升级前清单

升级前先确认:
  • etcd 快照已完成
  • 关键业务有副本,且探针配置合理
  • 有维护窗口
  • 已读目标版本 release note

kubeadm:升级与回滚

升级步骤(控制面先行):
多控制面就逐台执行 kubeadm upgrade node + kubelet/kubectl 升级。 工作节点升级:
回滚要点:
  • 应用回滚:kubectl rollout undo ...
  • 控制面回退优先锚点:etcd 快照 + 变更记录
  • 不建议在生产直接“硬降级”控制面版本,先在演练环境验证

k3s:升级与回滚

升级前确认:
  • 单 server 默认 SQLite;多 server 常见内置 etcd
  • 先做快照:k3s etcd-snapshot save(内置 etcd 时)
升级步骤(示例思路):
回滚要点:
  • 应用层仍可用 kubectl rollout undo
  • 内置 etcd 场景可用快照恢复:
  • 若是 SQLite 单 server,回滚主要依赖系统快照/磁盘备份

rke / rke2:升级与回滚

先分清版本:
  • RKE1:rke upcluster.yml
  • RKE2:rke2 server/agent
RKE1 升级与回退:
RKE2 升级与回退(思路同 k3s,滚动处理 server/agent):
回滚要点:
  • 优先应用层回滚
  • 控制面问题优先用 etcd 快照恢复(RKE1/RKE2 都建议升级前留快照)
  • 多控制面必须滚动操作,不要同一时间重启全部 server

升级后验证清单

业务验证建议:
  • 核心接口可访问
  • 核心服务无异常重启
  • 监控指标无明显抖动
应用层通用回滚命令(最常见):

故障演练流程(不演练=没准备)

很多团队问题不在“不会修”,而是“第一次遇到时太乱”。 所以故障演练要做成固定动作。

演练目标

  • 人员知道谁先做什么
  • 命令和步骤有模板
  • 业务影响可控
  • 演练结束有复盘

推荐演练场景

可以从这几个最实用的开始:
  • 场景 A:单个工作节点宕机
  • 场景 B:某个命名空间核心服务异常重启
  • 场景 C:证书即将过期,做一次轮换演练
  • 场景 D:模拟误删 Deployment 并恢复
  • 场景 E:模拟 etcd 数据恢复(在测试环境)

一次标准演练模板

准备阶段:
  • 明确演练范围(只在测试环境)
  • 明确回退条件(超过阈值立即停止)
  • 通知相关人员
执行阶段:
  • 注入故障(比如停 kubelet、删除 Pod、阻断某服务)
  • 观察现象(监控、日志、事件)
  • 按预案恢复
验证阶段:
  • 业务是否恢复
  • 数据是否一致
  • 告警是否及时
复盘阶段:
  • 哪一步慢了
  • 哪个命令容易打错
  • 哪个文档描述不清楚

故障排查通用命令清单

你可以直接落地的节奏

  • 每月一次小演练(30~60 分钟)
  • 每季度一次完整演练(2~4 小时)
  • 每次演练都更新文档
一句话总结:
线上稳定不是“运气好”,是“平时演得多”。

本章小结

你只要先把这四件事做实了,集群运维基本盘就稳了:
  • etcd 备份恢复有流程
  • 证书轮换有节奏
  • 升级回滚有预案
  • 故障演练成习惯
到这里,你已经不只是“会搭 K8s”,而是开始具备“守住 K8s”的能力了。

轻量级K3S

前往查看:https://blog.qianyios.top/tags/K3s/