基于K3s的轻量级Kubernetes集群搭建与运维实践指南-开发者社区

1. 项目概述：一个基于K3s的轻量级Kubernetes集群实践

最近在折腾一个个人项目，需要一套稳定、资源占用少的Kubernetes环境来做持续集成和微服务部署。一开始也考虑过Minikube、Kind这些本地开发工具，但总感觉它们和“真实”的集群环境还是有点距离，特别是网络和存储方面。后来把目光投向了K3s——这个由Rancher（现在属于SUSE）出品的轻量级Kubernetes发行版。它最大的魅力在于，把K8s的复杂度“打包”成了一个不到100MB的二进制文件，去掉了很多生产环境中才需要的重型组件，非常适合在边缘计算、IoT设备，或者像我这样的个人开发/测试环境中使用。

“samip5/k8s-cluster”这个项目，本质上就是一个基于K3s快速搭建高可用或单节点Kubernetes集群的实践指南和资源仓库。它解决的痛点非常明确：让开发者，尤其是那些资源有限（比如只有几台树莓派或者低配云服务器）的爱好者，能够以最低的学习成本和硬件开销，快速获得一个功能完备的K8s环境。这个环境可以用来学习Kubernetes的核心概念、部署自己的Web应用、搭建CI/CD流水线，或者作为家庭实验室的“大脑”。如果你正在寻找一种比Minikube更贴近生产、比完整K8s部署更省心的方案，那么基于K3s的集群构建思路，绝对值得你花时间深入研究。

2. 核心架构设计与选型考量

2.1 为什么选择K3s而非完整Kubernetes？

在决定自己搭建集群时，第一个要面对的就是发行版选型。完整的Kubernetes（我们常说的K8s）功能强大，但组件繁多，包括etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy等等。部署和维护这样一套系统，至少需要3台节点（以实现高可用），对内存和CPU的要求也不低，通常每台节点至少需要2GB内存。这对于个人学习或资源受限的场景来说，门槛过高。

K3s的诞生就是为了解决这个问题。它做了大量的精简和集成：

打包与简化：将Kubernetes的所有核心组件打包进一个单一的二进制文件。它用内置的SQLite数据库替代了etcd作为默认的存储后端（也支持外部etcd），大大降低了部署复杂度。
移除非核心组件：去除了像云控制器管理器（cloud-controller-manager）这类依赖于特定云供应商的组件，以及一些过时的、非默认的Alpha功能。
轻量级替代：使用轻量级的容器运行时containerd替代Docker，使用Traefik作为默认的Ingress Controller，进一步减少了资源占用。
极简安装：安装命令简单到令人发指：curl -sfL https://get.k3s.io | sh -。一条命令，几分钟内，一个单节点的K8s集群就跑起来了。

对于“samip5/k8s-cluster”这样的项目目标，K3s几乎是唯一的选择。它让我们可以在树莓派（ARM架构）、老旧的笔记本、甚至低配的云主机上流畅运行Kubernetes，把硬件门槛拉低到1GB内存甚至更低。

2.2 单节点与高可用集群的架构抉择

确定了K3s作为基础，接下来要决定集群的拓扑结构。这主要取决于你的可用机器数量和可靠性要求。

单节点集群（All-in-One）：这是最简单的模式。在一台机器上，同时运行K3s的server（控制平面）和agent（工作节点）角色。所有Pod都调度在这一台机器上。

优点：部署最快，资源消耗最低，非常适合快速验证、开发测试或个人学习。
缺点：存在单点故障。如果这台机器宕机，整个集群就不可用了。
适用场景：个人开发机、快速概念验证（PoC）、资源极度受限的环境。

高可用（HA）集群：这需要至少三台服务器。其中，多个节点运行K3s server角色，构成一个高可用的控制平面。工作负载可以运行在独立的agent节点上，也可以运行在server节点上（通过--node-taint参数控制）。

实现原理：K3s的高可用通过两种方式实现：
1. 嵌入式etcd（推荐）：从K3s v1.19.1开始，支持内置的etcd高可用。只需在初始化第一个server节点和后续加入的server节点时，指定一个共享的数据库存储端点（如外部etcd集群地址，或者使用内置etcd时通过--cluster-init标志），K3s server节点之间会自动组成一个高可用的etcd集群。
2. 外部数据库：使用一个外部的、高可用的数据库（如MySQL、PostgreSQL或外部etcd集群）作为数据存储后端。所有K3s server节点都连接到这个外部数据库。
优点：控制平面无单点故障，可靠性高，更贴近生产环境。
缺点：需要至少3台机器，部署和配置稍复杂，资源消耗更高。
适用场景：家庭实验室核心服务、中小型项目预生产环境、对可用性有要求的开发环境。

“samip5/k8s-cluster”项目通常会涵盖这两种模式的部署指南，让用户可以根据自身条件灵活选择。

2.3 关键组件与工具链选型

除了K3s本身，一个完整的“集群项目”还会涉及周边生态工具的选择。一个典型的工具链可能包括：

包管理：Helm。它是Kubernetes的包管理器，通过“Chart”来定义、安装和升级最复杂的K8s应用。在K3s集群上部署Ingress、监控、日志等基础设施，用Helm是最佳实践。
Ingress控制器：K3s默认集成了Traefik。Traefik是一个现代的、动态的HTTP反向代理和负载均衡器，它能够自动发现Kubernetes的Ingress资源并更新配置。你也可以选择替换为Nginx Ingress Controller。
服务网格：对于更复杂的微服务场景，可能会考虑Linkerd或Istio。但鉴于K3s的轻量定位，Linkerd通常是更合适的选择，因为它更轻量、更简单。
存储：K3s本身不提供动态存储卷供应。在单节点开发环境中，可以使用hostPath或local卷。在多节点或需要数据持久化的场景，需要部署一个CSI驱动，例如local-path-provisioner（K3s自带了一个简单的）、NFS Subdir External Provisioner，或者针对云环境的驱动。
网络：K3s默认使用Flannel作为CNI（容器网络接口）插件，提供Pod间的网络通信。Flannel简单稳定，足够满足大多数场景。

注意：工具链的选型没有绝对的对错，只有是否适合当前场景。对于个人集群，我的建议是“按需引入”，先用K3s+Traefik+Helm这个最小组合跑起来，再根据实际遇到的问题逐步添加其他组件，避免一开始就陷入复杂的配置泥潭。

3. 从零开始：单节点K3s集群部署实操

理论说得再多，不如动手搭一遍。下面我将以一台全新的Ubuntu 22.04 LTS服务器为例，演示如何部署一个单节点K3s集群，并验证其基本功能。假设你的服务器IP是192.168.1.100，你已经通过SSH登录。

3.1 前置环境检查与准备

在安装K3s之前，需要确保系统满足基本要求，并关闭一些可能冲突的服务。

# 1. 更新系统包索引 sudo apt update && sudo apt upgrade -y # 2. 检查主机名和hosts配置（确保能正确解析） hostname # 查看主机名 sudo hostnamectl set-hostname k3s-master # 可选：设置一个有意义的主机名 cat /etc/hosts # 检查是否包含 127.0.1.1 和主机名的映射，如果没有，可以添加 # 例如：echo "192.168.1.100 k3s-master" | sudo tee -a /etc/hosts # 3. 关闭Swap（Kubernetes为了稳定性和性能，默认要求禁用Swap） sudo swapoff -a # 临时关闭 # 永久关闭：注释掉 /etc/fstab 中所有包含 swap 的行 sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab # 4. 加载内核模块并调整内核参数（对于容器运行是必须的） sudo modprobe overlay sudo modprobe br_netfilter # 配置sysctl参数，使其持久化 cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-iptables = 1 net.bridge.bridge-nf-call-ip6tables = 1 net.ipv4.ip_forward = 1 EOF sudo sysctl --system # 5. 确保防火墙规则允许必要的端口（如果使用了防火墙） # K3s Server默认需要6443端口，节点间通信需要8472（Flannel VXLAN）等端口。 # 为了方便，可以先暂时禁用防火墙或放行所有流量（仅限测试环境！）。 # Ubuntu使用ufw： sudo ufw disable # 或者针对性放行： # sudo ufw allow 6443/tcp # sudo ufw allow 8472/udp # sudo ufw allow 10250/tcp

完成以上步骤后，你的系统就为安装K3s做好了准备。这些步骤看似繁琐，但能避免后续很多奇怪的网络和性能问题。

3.2 一键安装与初始化

K3s的安装简单得不可思议。使用官方提供的安装脚本是最佳方式，它能自动处理依赖和服务的安装。

# 使用官方脚本安装K3s Server，同时也会安装作为Agent curl -sfL https://get.k3s.io | sh - # 安装完成后，K3s服务会自动启动。你可以检查服务状态： sudo systemctl status k3s # 查看集群节点信息。此时应该只有本机一个节点，角色是 control-plane,master sudo k3s kubectl get nodes # 输出应类似于： # NAME STATUS ROLES AGE VERSION # k3s-master Ready control-plane,master 1m v1.27.6+k3s1

安装脚本默认会将K3s的kubeconfig文件（集群访问凭证）保存在/etc/rancher/k3s/k3s.yaml。为了能在普通用户下使用kubectl命令，我们需要复制并设置权限。

# 将kubeconfig复制到当前用户目录下 mkdir -p ~/.kube sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config sudo chown $(id -u):$(id -g) ~/.kube/config # 修改kubeconfig中的server地址，从127.0.0.1改为服务器的实际IP，以便从外部访问 sed -i 's/127.0.0.1/192.168.1.100/g' ~/.kube/config # 现在，你可以直接使用kubectl命令了 kubectl cluster-info kubectl get pods -A

至此，一个单节点的K3s集群已经部署完成。你可以看到kube-system命名空间下已经运行着coredns、traefik、local-path-provisioner等核心组件。

3.3 验证集群基本功能：部署一个测试应用

让我们部署一个最简单的Nginx应用，来验证集群的调度、网络和访问功能。

# 创建一个名为 nginx-test.yaml 的文件 cat > nginx-test.yaml <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:alpine ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-ingress spec: rules: - http: paths: - path: / pathType: Prefix backend: service: name: nginx-service port: number: 80 EOF # 应用这个配置文件 kubectl apply -f nginx-test.yaml # 查看资源创建情况 kubectl get deployments,svc,pods,ingress

稍等片刻，Pod会进入Running状态。由于我们使用了Ingress，并且K3s默认安装了Traefik作为Ingress Controller，我们可以通过Traefik的默认服务来访问这个Nginx。

# 获取Traefik的Dashboard服务地址（通常是ClusterIP类型，我们需要端口转发或修改为NodePort） kubectl get svc -n kube-system traefik # 假设traefik service名字就是 traefik，我们将其类型改为NodePort以便从主机访问 kubectl patch svc traefik -n kube-system -p '{"spec":{"type":"NodePort"}}' # 查看新的端口 kubectl get svc -n kube-system traefik # 输出会显示一个30000-32767之间的端口，例如 30444。现在可以通过 http://192.168.1.100:30444 访问Traefik Dashboard。 # 而我们部署的Nginx应用，可以通过Traefik自动生成的域名访问。默认情况下，Traefik会使用`<service-name>.<namespace>.<domain>`的格式。 # 但由于我们没有配置明确的域名，更简单的测试方法是使用端口转发： kubectl port-forward svc/nginx-service 8080:80 & # 然后在本地浏览器访问 http://localhost:8080，应该能看到Nginx欢迎页面。

这个简单的测试验证了从镜像拉取、Pod调度、服务发现到外部访问的完整链路。如果你的所有步骤都成功了，那么恭喜你，你的K3s单节点集群已经完全可以用于学习和开发了。

4. 进阶部署：构建三节点高可用K3s集群

单节点适合入门，但想要更可靠的环境，或者学习多节点集群的管理，搭建一个高可用（HA）集群是必要的。下面我们以三台Ubuntu服务器为例，演示如何构建一个基于嵌入式etcd的K3s高可用集群。假设三台服务器信息如下：

Server 1:192.168.1.101(将作为第一个控制平面节点)
Server 2:192.168.1.102
Server 3:192.168.1.103

4.1 第一台Server节点的初始化

在第一台服务器（192.168.1.101）上执行初始化。关键参数是--cluster-init，它会告诉K3s使用内置的etcd并初始化一个新的etcd集群。

# 在 server-1 (192.168.1.101) 上执行 curl -sfL https://get.k3s.io | K3S_TOKEN=my_super_secret_ha_token sh -s - server --cluster-init --node-ip 192.168.1.101 --tls-san 192.168.1.101

参数解析：

K3S_TOKEN=my_super_secret_ha_token：这是一个共享的密钥，用于其他server节点加入集群时进行认证。请务必使用一个强密码并妥善保管。
server：指定该节点运行server角色。
--cluster-init：初始化一个新的嵌入式etcd集群。这是实现高可用的关键。
--node-ip 192.168.1.101：显式指定节点的IP地址，避免使用不可靠的自动发现。
--tls-san 192.168.1.101：在TLS证书中添加一个主题备用名称（SAN）。这对于通过这个IP地址访问Kubernetes API Server是必须的。如果你有负载均衡器或域名，也需要在这里添加，例如--tls-san k8s-api.my.domain。

安装完成后，同样检查状态并获取kubeconfig文件。

sudo systemctl status k3s sudo cat /var/lib/rancher/k3s/server/node-token # 这个token也可以用于agent节点加入，但server节点加入建议用K3S_TOKEN环境变量

4.2 其他Server节点加入集群

在第二台和第三台服务器上，使用相同的K3S_TOKEN和第一个server节点的地址加入集群。

# 在 server-2 (192.168.1.102) 上执行 curl -sfL https://get.k3s.io | K3S_TOKEN=my_super_secret_ha_token sh -s - server --server https://192.168.1.101:6443 --node-ip 192.168.1.102 --tls-san 192.168.1.102 # 在 server-3 (192.168.1.103) 上执行 curl -sfL https://get.k3s.io | K3S_TOKEN=my_super_secret_ha_token sh -s - server --server https://192.168.1.101:6443 --node-ip 192.168.1.103 --tls-san 192.168.1.103

参数解析：

--server https://192.168.1.101:6443：指定要加入的现有集群的API Server地址。新节点会从该地址获取集群信息并注册自己。

等待几分钟，让etcd集群完成成员添加和数据同步。然后在任意一个server节点上查看集群状态：

# 使用从server-1复制的kubeconfig，或者配置一个能访问任意server节点的kubeconfig kubectl get nodes

你应该能看到三台服务器，角色都是control-plane,etcd,master。这表明一个高可用的控制平面已经建立。

4.3 添加Worker节点（可选）

如果你有纯粹的只运行工作负载的机器，可以将它们作为Agent节点加入。Agent节点加入需要使用server节点提供的node-token。

# 在任意server节点上获取node-token sudo cat /var/lib/rancher/k3s/server/node-token # 假设输出token为：K10abcdefghijklmnopqrstuvwxyz::server:0123456789abcdef0123456789abcdef # 在要加入的worker节点上执行 curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.101:6443 K3S_TOKEN=K10abcdefghijklmnopqrstuvwxyz::server:0123456789abcdef0123456789abcdef sh -s - agent --node-ip <worker_node_ip>

这样，你就拥有了一个由三个控制平面节点和若干个计算节点组成的标准高可用Kubernetes集群。即使其中一个server节点宕机，集群的控制平面依然可以正常工作。

5. 集群运维与必备工具集成

集群跑起来只是第一步，日常的监控、日志、备份同样重要。对于个人或小团队集群，我们追求的是“够用、简单”。

5.1 使用Helm部署监控栈：Prometheus + Grafana

Helm是管理K8s应用的生命线。首先安装Helm客户端。

# 下载Helm安装脚本并执行 curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 chmod 700 get_helm.sh ./get_helm.sh

然后，我们可以用Helm一键部署Kubernetes社区维护的kube-prometheus-stack，它包含了Prometheus、Grafana、Alertmanager以及一整套针对K8s的监控规则和仪表盘。

# 添加Prometheus社区Chart仓库 helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update # 创建一个用于监控的命名空间 kubectl create namespace monitoring # 安装 kube-prometheus-stack helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \ --namespace monitoring \ --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false \ --set grafana.service.type=NodePort

安装完成后，查看Grafana的服务端口：

kubectl get svc -n monitoring kube-prometheus-stack-grafana

将服务类型改为NodePort后，会分配一个外部端口（如32623）。访问http://<你的服务器IP>:32623，默认用户名/密码是admin/prom-operator（安装时可通过--set grafana.adminPassword修改）。登录后，你会发现已经预置了众多关于Kubernetes集群、节点、Pod的监控仪表盘，开箱即用。

5.2 配置持久化存储：以NFS为例

K3s自带的local-path-provisioner只能在单个节点上提供持久卷。在多节点集群中，我们需要一个网络存储方案。NFS是一个简单通用的选择。假设你有一台NFS服务器，地址是192.168.1.200，共享目录是/data/nfs。

首先，在所有K3s节点上安装NFS客户端工具：

sudo apt install -y nfs-common

然后，在Kubernetes中创建对应的StorageClass和PersistentVolume（PV）/ PersistentVolumeClaim（PVC）。更现代的方式是使用NFS Subdir External Provisioner这个Helm Chart，它可以动态创建PV。

# 添加Helm仓库 helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/ helm repo update # 安装 provisioner helm install nfs-subdir-exvisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \ --set nfs.server=192.168.1.200 \ --set nfs.path=/data/nfs \ --set storageClass.name=nfs-client \ --set storageClass.defaultClass=true # 设置为默认StorageClass

安装后，创建一个PVC测试：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pvc spec: storageClassName: nfs-client accessModes: - ReadWriteMany resources: requests: storage: 1Gi

应用后，kubectl get pvc应该能看到PVC状态为Bound，并且系统会自动在NFS服务器/data/nfs目录下创建一个专属子目录来存放数据。

5.3 日志收集方案：Fluent Bit + Elasticsearch + Kibana (EFK)

对于日志，轻量级选择是Fluent Bit。它可以作为DaemonSet运行在每个节点上，收集容器和系统日志，并输出到多种目的地（如Elasticsearch、Loki等）。

部署Fluent Bit到K3s集群：

# 添加Fluent Bit Helm仓库 helm repo add fluent https://fluent.github.io/helm-charts helm repo update # 安装Fluent Bit，输出到标准输出（stdout）用于测试 helm install fluent-bit fluent/fluent-bit --namespace logging --create-namespace \ --set backend.type=forward \ --set backend.forward.host=127.0.0.1 # 这里仅为示例，实际需要配置真实的日志后端地址

对于完整的EFK栈，部署会复杂一些，需要分别部署Elasticsearch（状态ful有状态应用）和Kibana。考虑到资源消耗，在个人集群中，更推荐使用Grafana Loki，它比Elasticsearch更轻量，且与Grafana集成无缝。

# 添加Grafana Loki仓库 helm repo add grafana https://grafana.github.io/helm-charts helm repo update # 安装Loki（日志存储）和Promtail（日志收集，替代Fluent Bit） helm install loki grafana/loki-stack --namespace logging --create-namespace \ --set promtail.enabled=true \ --set loki.persistence.enabled=true \ --set loki.persistence.size=10Gi

安装后，在Grafana中添加数据源，选择Loki，URL填写http://loki.logging:3100，就可以在Grafana中查询和展示日志了。

6. 常见问题与故障排查实录

在搭建和维护K3s集群的过程中，我踩过不少坑。这里把一些典型问题和解决方法记录下来，希望能帮你节省时间。

6.1 节点状态NotReady或网络问题

问题现象：kubectl get nodes显示节点状态为NotReady，或者Pod之间无法通信。

排查思路：

检查K3s服务状态：sudo systemctl status k3s或sudo systemctl status k3s-agent。查看服务是否正常运行，日志是否有报错（sudo journalctl -u k3s -f）。
检查网络插件：K3s默认使用Flannel。检查Flannel Pod是否运行正常：kubectl get pods -n kube-system -l app=flannel。如果CrashLoopBackOff，很可能是Pod网段与主机网络冲突。
检查Pod网段配置：Flannel默认使用10.42.0.0/16，如果这个网段和你物理网络冲突，需要修改。在安装server时指定：--flannel-backend=wireguard-native --flannel-ipv4-masq --cluster-cidr=10.244.0.0/16（例如改用Calico的默认网段）。
检查防火墙：这是最常见的问题。确保节点间放行了必要的端口：
- TCP 6443 (Kubernetes API)
- UDP 8472 (Flannel VXLAN，非常重要！)
- TCP 10250 (kubelet API)
- TCP 2379-2380 (etcd，如果使用嵌入式HA)
检查路由：在多网卡或复杂网络环境中，Flannel可能选错了网络接口。可以通过--node-ip显式指定IP，或通过--flannel-iface指定接口。

6.2 镜像拉取失败或速度慢

问题现象：Pod状态为ImagePullBackOff或ErrImagePull。

解决方法：

配置镜像加速器：对于Docker Hub等国外仓库，国内拉取很慢甚至失败。K3s使用containerd，可以修改其配置。编辑/etc/rancher/k3s/registries.yaml文件（如果不存在则创建）：
```
mirrors: docker.io: endpoint: - "https://docker.mirrors.ustc.edu.cn" # 使用中科大镜像站 - "https://hub-mirror.c.163.com" # 或网易镜像站
```
然后重启K3s服务：sudo systemctl restart k3s。
使用私有仓库：如果需要从私有仓库拉取镜像，需要在registries.yaml中配置认证信息，并在Pod的imagePullSecrets中指定。
提前拉取镜像：在节点上手动使用crictl命令拉取镜像（K3s集成了crictl）：sudo crictl pull nginx:alpine。

6.3 存储卷挂载失败

问题现象：Pod启动失败，事件显示FailedMount，提示timeout waiting for volume。

排查步骤：

检查StorageClass：kubectl get storageclass。确认你PVC指定的StorageClass存在且是default（或者明确指定了正确的名字）。
检查PV/PVC状态：kubectl get pv,pvc。确认PVC是否处于Bound状态，以及绑定的PV是否正常。
查看Provisioner日志：如果使用动态供应（如nfs-client-provisioner），查看其Pod日志：kubectl logs -f deployment/nfs-subdir-external-provisioner -n <namespace>。
检查节点挂载：SSH到Pod所在节点，检查是否成功挂载了网络存储。例如对于NFS，使用showmount -e <nfs-server-ip>检查导出列表，使用mount | grep nfs检查挂载点。

6.4 集群备份与恢复

对于个人集群，定期备份是良好的习惯。K3s的备份主要针对两部分数据：etcd的数据快照和/var/lib/rancher/k3s目录下的配置文件。

手动备份etcd（适用于嵌入式etcd）：

# 在server节点上执行 sudo k3s etcd-snapshot save --snapshot-compress --data-dir /var/lib/rancher/k3s/server # 快照会保存在 /var/lib/rancher/k3s/server/db/snapshots/ 目录下

使用Velero进行应用级备份（更推荐）： Velero可以备份整个命名空间、带标签的资源甚至整个集群的持久卷数据。

安装Velero客户端和服务器端（需要对象存储如MinIO或S3）。
创建一个备份：velero backup create my-backup --include-namespaces default。
恢复：velero restore create --from-backup my-backup。

对于个人集群，最简单的恢复演练就是：定期用etcd-snapshot命令备份，并确保/etc/rancher/k3s/和/var/lib/rancher/k3s/中的重要配置文件有副本。当集群崩溃时，可以重新安装K3s，并通过--cluster-restore参数指定快照文件来恢复etcd数据。

6.5 资源清理与卸载

如果你想彻底清理K3s，特别是在安装失败后重试，需要执行以下命令：

# 在server节点上 /usr/local/bin/k3s-uninstall.sh # 在agent节点上 /usr/local/bin/k3s-agent-uninstall.sh # 手动清理残留（谨慎操作！） sudo rm -rf /etc/rancher/k3s sudo rm -rf /var/lib/rancher/k3s sudo rm -rf /var/lib/cni sudo ip link delete cni0 sudo ip link delete flannel.1

卸载脚本会停止服务并移除相关文件，但一些网络命名空间和CNI配置可能需要手动清理。执行完上述操作后，机器基本恢复到了安装前的状态。