Kubernetes v1.28内网离线部署实践：网线直连环境下的完整操作指南

1. 动手前先想清楚：为什么是网线直连加离线这套组合

如果你已经点进这篇文章，大概率正面临一个很现实的场景：客户机房、实验室、或某些涉密内网环境里，机器是全新的，系统装好了，但网络策略极其严格，别说访问 Docker Hub，连一台能用的内网镜像源都找不到。设备之间就靠一根网线或者一台傻瓜交换机连在一起。这个时候想把 Kubernetes v1.28 集群跑起来，很多人第一反应是头大，但实际上这条路是可以走通的，前提是物料准备够细致、安装手法够干净。

我选择 v1.28 而不是更新的版本，原因很简单：v1.28 是当前生产环境中非常成熟的一个版本，稳定性和生态兼容性都经过了大量验证，网上可查的故障案例也足够多。而离线安装最怕的就是版本太新，踩到一个网上几乎没有记录的坑，那才叫真被动。如果你后续要装一些比较新的 Operator 或 CNI 插件，v1.28 的 API 兼容性也足够支撑。

这套方案的核心思路可以概括成一句话：用网线直连解决节点互通问题，用离线介质包解决软件分发问题，用合理的初始化参数解决版本兼容问题。 整篇文章不是讲怎么在理想网络环境下快速搭建，而是专门针对“没外网、没镜像源、节点少、网络结构简单”这种硬约束场景，提供一套可以照着一步一步执行的操作方案。适合的人很明确：准备在隔离网络里自建 K8s 的运维工程师、正在做实验环境但又不想依赖外网的开发人员，以及那些被要求在无网机房把容器平台搞起来的苦命兄弟们。

在正式动手之前，我建议你先用一张纸把整个流程画出来。我的习惯是先理清“包从哪来、镜像从哪来、节点间怎么通、初始化后怎么验证”这四件事，再开始敲命令。离线部署最大的风险不是某个步骤不会操作，而是做到一半发现缺了某个依赖包或某张镜像，卡在那里进退两难。所以这篇文章的前半部分会花大量篇幅讲准备工作，这一部分千万别跳。

2. 环境规划与网络设计：直连组网的几个隐藏细节

2.1 节点角色与硬件规划参考

离线部署通常规模不会太大，一般就是 3 到 5 台机器。我这里拿最常见的 3 节点配置举例：1 台控制平面节点加 2 台工作节点。硬件方面，控制平面建议至少 2 核 4G 内存，工作节点至少 2 核 4G，如果你要在上面跑一些像样的应用，工作节点最好 4 核 8G 起。磁盘这块，系统盘单独分开，容器数据目录如果可以的话用独立数据盘，尤其是后面要跑有状态服务的时候，数据盘和系统盘混在一起会非常痛苦。

操作系统我强烈建议统一用同一个版本，不要一台 Ubuntu 一台 CentOS 这么混着来。下面的操作示例基于 Rocky Linux 9.x 或 AlmaLinux 9.x 这类 RHEL 系发行版，但我也会单独讲 deb 系怎么做，因为很多内网机器实际装的是 Ubuntu Server。

2.2 网线直连的网络规划实操

网线直连相对交换机连接，本质区别在于物理拓扑极其简单，但更容易忽略一些网络参数问题。如果你只有两台机器，直接用一根超五类或六类网线把两个网口连起来就行。三台及以上的场景，还是建议通过一台傻瓜交换机汇聚，纯靠一根网线串三台机器是不现实的，别在这个环节浪费时间。

网线直连的 IP 规划我推荐用静态地址，且所有机器处于同一网段。这里分享一个比较稳的地址规划示例：

子网掩码统一 255.255.255.0，网关可以留空不写。这里有一个非常关键的细节：在仅直连的纯内网拓扑中，如果节点本身不需要访问外部网络，不要配置默认网关，免得产生路由歧义。DNS 可以写内网 DNS 或直接留空，不要写 8.8.8.8 这类外部 DNS，防止解析时产生不必要的延迟等待。每台机器的主机名和 /etc/hosts 要提前配置好，这步很基础但很多人会忘，后面 kubeadm init 的时候如果主机名解析有问题，报错信息会非常绕。

2.3 时钟同步与内核参数的“事前”准备

离线环境最容易忽略的就是时钟同步。Kubernetes 对证书和时间比较敏感，节点间时间差超过一定范围，kubeadm 初始化时经常报证书验证相关的错。有条件的可以在内网放一台 NTP 服务器，没条件的至少保证在安装前用 date 命令人工确认每台机器时间一致。这个看起来有点原始，但确实能省掉很多莫名其妙的坑。

内核参数方面，我建议初始化之前就完成配置。主要是四个关键项：net.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward、以及对 fs.inotify.max_user_instances 和 fs.inotify.max_user_watches 的调优。前者关系到 iptables 对 bridge 流量的处理，后者直接影响 Pod 数量多了以后 inotify 资源是否够用。把配置写入 /etc/sysctl.d/k8s.conf 后执行 sysctl --system 使其生效，这些也是老生常谈，但确实是每次部署都少不了的底活。

3. 离线物料准备：一个装得下整个集群的U盘

3.1 获取 Kubernetes 二进制与镜像的离线思路

离线安装的物料分两大部分：一是 RPM/DEB 包，二是容器镜像。

RPM 包这块，如果你有一台能联网的同系统机器，最简单的方式是用 yumdownloader 把 kubeadm、kubelet、kubectl 及其依赖全部下载下来。需要注意的一点是，kubeadm 和 kubelet 的版本必须保持一致，且要指定好小版本号，例如 1.28.2-0，不要只写一个 1.28，否则 yum 解析依赖时可能拉到你意想不到的版本。命令大致是这样：

bash复制yumdownloader --resolve kubeadm-1.28.2-0 kubelet-1.28.2-0 kubectl-1.28.2-0 --destdir=/tmp/k8s-rpms

这里要求你本机已经配置了 Kubernetes 官方 yum 源。下载完成后，把整个目录拷到 U 盘里。目标机器上安装时统一执行：

bash复制rpm -ivh /mnt/usb/k8s-rpms/*.rpm

我一般不用 rpm -Uvh，反而更习惯 -ivh 强制安装指定版本，避免目录里有多个版本时出现意外升级。

DEB 系的做法类似，用 apt-get download 或 apt download 加依赖处理即可，但 deb 的依赖关系更细碎，建议用 apt-get install --download-only 加指定安装目录的方式处理，成功率更高。

3.2 没有镜像仓库时，容器镜像如何精准搬运

容器镜像是离线部署里最容易卡壳的地方。最理想的方式是把镜像推到你内网的一台私有仓库里，但很多约束环境下根本没有这个条件。退而求其次，也是本文采用的方式，就是在能联网的机器上用 docker pull 把镜像拉下来，再 save 成 tar 包，拷贝到内网机器后再 load 回去。

kubeadm 在初始化时需要的镜像列表可以通过一条命令查看，这里要注意命令会因架构和版本略有差异：

bash复制kubeadm config images list --kubernetes-version v1.28.2

输出大致内容如下：

text复制registry.k8s.io/kube-apiserver:v1.28.2
registry.k8s.io/kube-controller-manager:v1.28.2
registry.k8s.io/kube-scheduler:v1.28.2
registry.k8s.io/kube-proxy:v1.28.2
registry.k8s.io/pause:3.9
registry.k8s.io/etcd:3.5.9-0
registry.k8s.io/coredns/coredns:v1.10.1

这里需要特别提醒已经提前踩过坑的同志：在 v1.28 版本里，coredns 镜像的路径已经发生了变化，不再是 registry.k8s.io/coredns:v1.10.1，而是多了个 coredns/ 路径，变成了 registry.k8s.io/coredns/coredns:v1.10.1。如果你按照老教程去 pull 镜像，八成会卡在这一步。别问我是怎么知道这个坑的。

拉取镜像时同样要注意国内网络环境对 registry.k8s.io 的访问问题。如果你准备镜像的机器能正常访问，那自然最好。如果访问不稳定，可以考虑使用一些镜像加速站点，但因为这些站点的可用性时有变化，这里不具体推荐某一个，你可以根据实际操作时的情况去决定。

镜像全部拉完后，统一打包即可：

bash复制docker save $(docker images | grep registry.k8s.io | awk '{print $1":"$2}') -o k8s-images-v1.28.2.tar

文件名里带上版本号，这个习惯能让你后期排查物料版本不匹配时少掉很多头发。

3.3 CNI、Dashboard 等附件镜像的准备清单

除了 kubeadm 系统镜像外，你还要提前想清楚集群要跑哪些附件。比如网络插件，如果选 Calico，那 Calico 相关的镜像体积不小，加起来好几百兆，而且它的镜像列表在不同版本里有变化。这里建议以你实际选择的安装方式为准，用官方 manifest 文件里定义的镜像列表去拉取，不要凭感觉。

如果你的网络插件想图省事用 Flannel，那镜像是比较少的，但 Flannel 在跨宿主机容器通信的性能表现上不如 Calico，这个就看你的业务场景了。离线环境通常没有太多外部流量进来，反而是集群内部的南北向和东西向性能更重要，需要自己权衡。

另外如果在隔离环境里还想通过浏览器访问 Kubernetes Dashboard，那 dashboard 的镜像也得提前准备好。比较常见的还有 metrics-server，没有它 kubectl top 就是废的。后面这些建议在初始化之前就把镜像全都放到每台机器上，免得等工作节点加入集群时才想起来要拉镜像，那个时候网络已经断了就非常被动。

一个非常笨但有效的方法是：把所有 tar 包统一放到一个目录，然后写一个简单脚本在每台机器上执行 docker load，镜像加载时如果遇到重名，后加载的会覆盖先加载的，但因为我们这边拉取时已经标记好版本号，基本不会出问题。脚本示例如下：

bash复制for image_tar in /opt/k8s-offline/images/*.tar; do
    docker load -i "$image_tar"
done

4. 从包安装到容器运行时：提前消灭版本兼容雷区

4.1 Docker 还是 Containerd：离线环境的选择逻辑

Kubernetes 从 v1.24 开始已经移除了对 Docker 的直接支持，kubelet 里的 dockershim 被彻底删除。现在主流做法是 kubelet 通过 CRI 接口直接对接 containerd，再由 containerd 去管理镜像和容器生命周期。

这就引出一个离线环境下很大的坑：你不能像以前那样装完 Docker 就完事，要么配置 cri-dockerd 作为适配层，要么直接用 containerd。我强烈建议直接用 containerd，因为 cri-dockerd 是额外的中间层，不仅浪费一点性能，还多一个组件要维护，离线环境少一个组件就是少一个不稳定因素。

4.2 Containerd 的离线安装与关键配置

在 Rocky/Alma 系列上，containerd 可以从 Docker 官方 yum 源安装，也可以直接使用 containerd.io 这个包名安装。安装完成后需要修改核心配置 /etc/containerd/config.toml。

首要是生成一份默认配置：

bash复制containerd config default > /etc/containerd/config.toml

然后找到 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 这一段，把 SystemdCgroup 设置为 true。这一步非常关键，否则 kubelet 与 containerd 在 cgroup 驱动上不一致，就会直接导致初始化失败或者 Pod 反复重启。官方给出的错误信息可能不够明显，通常是在 kubelet 日志里会反复刷 cgroup 相关的 warning。

还有一个非常隐秘的配置：pause 镜像的地址。containerd 默认的 pause 镜像地址是 registry.k8s.io/pause:3.6，但 kubeadm 在 v1.28 里默认拉的是 registry.k8s.io/pause:3.9，两个版本不一致在某些场景下会导致 Pod 创建缓慢或者报 Sandbox 相关的错误。稳妥的做法是确保前面的镜像准备阶段把 pause:3.9 也加载到了机器里，同时把配置文件里的 sandbox_image 改成对应版本：

toml复制[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"

改完配置记得重启 containerd，并确认服务状态是 active：

bash复制systemctl restart containerd
systemctl status containerd

4.3 kubelet、kubeadm、kubectl 的安装与启动策略

RPM 包装完后，需要设置 kubelet 开机自启，但这里有个细节是不要立即启动它。在 kubeadm init 之前 kubelet 会因为缺少静态 Pod 配置反复崩溃，这是正常现象，不用慌。你只需要：

bash复制systemctl enable kubelet

然后先别 systemctl start kubelet，等着 kubeadm 初始化时帮你去拉起它。

另外要提前确认 kubelet 的 cgroup 驱动配置。可以在 /etc/sysconfig/kubelet 里加一行：

bash复制KUBELET_EXTRA_ARGS="--cgroup-driver=systemd"

这是系统初始化之前的最后一层保险，确保 kubelet 启动时驱动正确，省得初始化过程中因为驱动不匹配而中止。做这些准备工作的时候，有意识地照着一条命令一条命令执行，不要图快一把梭，每步敲完最好都检查一下输出结果，这能让你在后续环节少很多排查工作。

5. 初始化过程详录：kubeadm init 的参数、输出与避坑

5.1 准备初始化配置文件的推荐方式

在执行 kubeadm init 之前，先写好配置文件永远比用一堆命令行参数靠谱。好处是版本化、可审查、后续要再加节点可以复用。执行：

bash复制kubeadm config print init-defaults > kubeadm-init.yaml

然后按需修改。核心字段主要重点关注 localAPIEndpoint.advertiseAddress 改成 master 节点的 IP，nodeRegistration.name 改成 master 主机名，还有 imageRepository 这一项。如果你走的纯离线加载镜像的路线，imageRepository 保持默认的 registry.k8s.io 是没问题的，因为镜像已经提前 load 进 containerd 了，kubeadm 不会真正去远程拉。如果你希望走本地仓库的形式，可以改成你的仓库地址。

Pod 网段这里需要单独给一个不冲突的网段，比如 10.244.0.0/16，注意不要和你物理机网段重叠。如果你之后要用 Flannel，那这个地址基本是固定的，因为 Flannel 默认使用这个网段。如果要用 Calico，可以自定义，但要和 Calico 的 IPPool 配置保持一致。

5.2 控制平面初始化实际执行记录

配置就绪后执行初始化：

bash复制kubeadm init --config kubeadm-init.yaml --upload-certs

整个初始化时间正常情况下在 1 到 3 分钟之间，取决于机器的 CPU 和磁盘性能。如果你配置没问题，最终输出会提示你执行一系列命令配置 kubectl。这一步跟着输出做就行，它会给出类似这样的内容：

bash复制mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

注意这里必须把 admin.conf 复制到默认的 kubeconfig 路径，kubectl 才能连上 API Server。另外一种方式是把 kubeconfig 的路径通过环境变量 export KUBECONFIG=/etc/kubernetes/admin.conf 暴露出来，但我觉得最稳的还是老老实实复制到 ~/.kube/config，因为很多工具默认只认这个路径。

5.3 etcd、CoreDNS 启动失败的排查切入点

初始化输出结束只是第一步。此时用 kubectl get pods -n kube-system 查看，很可能会看到一堆 Pending 或 CrashLoopBackOff。不要慌，这基本是健康状态，因为还没有安装网络插件，CoreDNS 一直处于 Pending 是符合预期的。

如果看到的是 etcd 或 kube-apiserver 反复崩溃，那就比较麻烦了。最直接的办法是 journalctl -u kubelet -f 看日志，或者找到 /var/log/pods 下对应容器的日志。我见过最多的情况是证书时间不同步、cgroup 驱动不一致、或者是宿主机的主机名解析不了自己。前面的准备阶段如果做得好，这部分大概率不会出问题，但如果真出事，记住一条原则：看日志永远优先于乱改配置。

初始化完成后还会输出一条 worker 节点加入集群的命令，这条命令默认 24 小时有效，一定要保存好。如果忘了，可以在 master 节点上用 kubeadm token create --print-join-command 重新生成。

6. 网络插件选型与安装：什么时候选 Flannel，什么时候选 Calico

6.1 两种插件在离线场景下的差异对比

离线环境网络插件的选择会直接影响集群的后续稳定性，建议在初始化前就做决定。

如果你的环境只是自己实验或跑点轻量服务，Flannel 绝对是省心之选，一个 DaemonSet 就能把网络打通，几乎没有额外维护成本。但如果你是在正经机房搭生产环境，未来还可能有跨节点通信、精细隔离的需求，我建议直接上 Calico，因为 Flannel 后期要迁移到 Calico 是非常痛苦的，整个集群的 Pod 网络要重置。

6.2 Calico 的离线安装细节与 IP 池规划

Calico 官方提供 operator 方式和 manifest 方式安装。离线环境下我建议用 manifest 方式，因为你只需准备一个或多个 YAML 文件，加上对应的镜像即可。

下载好 calico.yaml 后，打开文件修改 Pod 网段。如果你在 kubeadm 里配置的是 10.244.0.0/16，那 calico.yaml 里的 CALICO_IPV4POOL_CIDR 变量就要保持一致。如果这里改漏了，Calico 会使用默认的 192.168.0.0/16，结果就是集群 Pod 之间完全不通，而且报错还很不直观。

安装：

bash复制kubectl apply -f calico.yaml

安装后稍等一两分钟，再用 kubectl get pods -n kube-system 查看，正常情况下 calico-node 的 Pod 会逐渐变成 Running，此时 CoreDNS 也会跟着从 Pending 变成 Running。如果 calico-node 一直 CrashLoopBackOff，大概率是配置文件里 IP 池网段的问题，需要查日志确认。

6.3 验证网络是否可用的几种干净姿势

网络插件装完后不要急着部署业务，先做两件事。第一件是查看所有节点状态是否 Ready：

bash复制kubectl get nodes

第二件是建一个临时的测试 Pod 验证跨节点通信。不推荐直接使用你的业务镜像，而是用一个轻量测试镜像，比如 busybox。在两个不同的节点上分别调度 Pod，然后互相 ping 或 wget。这里要注意 busybox 版本不同，里面的命令集可能有差异，我自己就遇到过 busybox 里没有 wget 的情况，当时挺尴尬的。可以换成 curl 镜像或直接使用 kubectl run 加 --image=nginx 做个临时 Pod 更省心。

7. 工作节点加入集群的完整过程

7.1 确保工作节点的前置条件完全一致

工作节点加入集群的位置并不复杂，但前置条件这里要再强调一遍，因为很多人的坑都出在细节上。工作节点上必须已经完成以下几件事：系统基础配置、containerd 安装与配置、kubelet/kubeadm/kubectl 安装、镜像加载完毕。换句话说，从第 3 节到第 4 节的所有准备步骤，在每台工作节点上都要重复执行一遍，不能只在 master 上做完就直接拿 join 命令去跑。我见过有人带着 U 盘在每台节点上单独拉镜像，结果在一个节点上拉完了另一个节点却忘记做，导致节点加入集群后 kube-proxy 镜像拉取失败，实际上镜像还是缺的。

7.2 join 操作的常见报错与原因拆解

执行 join 命令时最典型的报错有几种。

第一种是提示证书过期或者 token 无效。这个通常是因为 join 命令复制错了、或者过了 24 小时的 token 有效期，解决办法就是回到 master 节点重新生成一条新的 join 命令。这里有一个技巧：kubeadm token create --print-join-command 这条命令能同时生成 token 和证书哈希，但需要注意，如果你在 init 时使用了 --upload-certs，还需要在 join 命令里带上 --certificate-key，否则控制平面节点加入时证书同步会失败，工作节点则不需要这参数。

第二种是连接超时。原因常见于工作节点根本无法访问 master 的 6443 端口。检测方式很简单，在工作节点上执行：

bash复制telnet <master-ip> 6443

如果是直连组网，检查 IP 是否配置正确、防火墙是否放行，这里就要提一句了：Kubernetes 需要的端口很多，包括 6443、2379-2380、10250、10251、10252、10255、30000-32767 等等。如果你在两台机器之间做了严谨的防火墙配置，记得先全部放通或直接禁用 firewalld 图个清净。

第三种是 CRI 连接失败。提示 containerd 的 socket 无法连接之类的，这时回到第 4 节检查 containerd 是否在运行、配置文件是否正确。

7.3 节点加入后的检查列表清单

等所有节点 join 完成后，在 master 上执行 kubectl get nodes，这时应当看到所有节点都处于 Ready 状态，版本列应该显示的是 v1.28.2。如果某个节点显示 NotReady，日志观察基本都会指向 Calico 或 Flannel 的 Pod 未能正常运行，也可以 kubectl describe node 看节点状态里的 Conditions 字段，里面往往有更详细的线索。

我习惯在节点全部就绪后再部署一个 DaemonSet 类型的测试应用，确保每个节点上都能正常调度 Pod 和挂载容器网络。这个验证方式比单纯看节点状态更可靠，因为节点 Ready 只是代表 kubelet 和容器运行时正常，并不代表容器网络真的没问题。

8. 附件组件安装：Dashboard、Metrics-Server 与离线证书问题

8.1 Metrics-Server 的离线安装与 kubelet 证书坑

Metrics-Server 用于提供 kubectl top 的数据来源，没有它，HPA 自动扩缩容也无从谈起。安装要点是镜像提前准备。在离线环境下，Metrics-Server 经常遇到的一个问题是它默认通过 HTTPS 去访问 kubelet 的 10250 端口收集数据，而 kubelet 默认使用自签证书，如果 metrics-server 没有配置跳过证书校验，启动后会一直报 TLS 相关错误。

解决方式是修改 deployment 的启动参数，加一行：

yaml复制- --kubelet-insecure-tls

同时如果 kubelet 的只读端口未启用，要确保 metrics-server 访问的是 10250 而不是 10255，这个和前面说到的只读端口要区分清楚。改动后重启 metrics-server Pod，正常情况下很快就能在 kubectl top nodes 看到数据了。

8.2 Dashboard 证书与访问方式选择

Kubernetes Dashboard 的安装最简单的方式是直接 apply 官方提供的 recommended.yaml，但在离线环境它内部定义的镜像如果没准备好，Pod 会直接 ImagePullBackOff。所以第一步还是把镜像提前 load 进去。

访问 Dashboard 通常有三种路径：kubectl proxy、NodePort、Ingress。离线环境没有现成 Ingress Controller 的话，最简单的是用 NodePort 方式。修改 dashboard service 类型为 NodePort，然后通过集群任意节点 IP 加随机分配的端口去访问。

进入 Dashboard 后需要登录凭据。推荐创建单独的服务账号而不是用 admin 用户的 token，因为 admin 的 token 权限过大，放浏览器里属于高危操作。可以用以下方式创建：

bash复制kubectl create serviceaccount dashboard-admin -n kubernetes-dashboard
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:dashboard-admin
kubectl create token dashboard-admin -n kubernetes-dashboard

最后一条命令会输出一个长效的 token，可以直接粘贴到 Dashboard 登录页。这里有个老教程的误区要指出：早期版本通过 kubectl describe secret 去拿 token 的方式在 v1.28 中已经不太适用，因为 v1.24 之后创建 ServiceAccount 时 Secret 不是自动生成的，所以直接用 create token 更干净。

8.3 本地仓库的替代路线：什么时候依然要用私有仓库

如果你觉得把所有镜像手动 load 到每一台机器过于繁琐，且环境内有一台能作为仓库的机器，那部署一个本地 Harbor 或干脆用精简的 registry:2 容器作为镜像仓库，整个运维体验会好很多。所有节点只需要在 containerd 配置里添加 registry.k8s.io 到本地仓库的映射，或者在 kubeadm init 时通过 imageRepository 指定私有仓库地址，就可以避免手工拉镜像的重复劳动。

但要注意，私有仓库本身也需要镜像才能跑起来，这就变成了先有鸡还是先有蛋的问题。实际操作中我还是建议：第一台节点用离线 load 的方式完成初始化，然后把必要的系统镜像推送到本地仓库，后续其他节点直接从仓库拉取。这是一个两全其美的方法。

9. 常见问题速查：我收集的典型案发现场

我在反复部署过程中整理了一个问题清单，走查时建议直接对照排查：

这中间最典型的就是第一种。我在一次实操中遇到过，机器是物理机，远程操作控制台不方便看到启动日志，kubeadm init 直接报 etcd 健康检查超时。后来核对时间才发现，两台机器相差了近三分钟。手动同步之后重新 init，一气呵成。所以说离线环境里，时间同步这事值得多上点心。

如果 kubeadm init 执行到一半失败，修改配置后想重来，需要执行比较彻底的清理。我自己常用的清理步骤是：

bash复制kubeadm reset -f
rm -rf /etc/kubernetes/
rm -rf /var/lib/etcd/
rm -rf /var/lib/cni/
ip link delete cni0 2>/dev/null
ip link delete flannel.1 2>/dev/null

注意这些命令在节点上执行后有严重的破坏性，操作前确认这台机器不是正在运行的集群中的一份子。reset 之后如果还要再初始化，记得重新检查 kubelet 和 containerd 的状态，有时 reset 会把这两个服务搞成 dead 状态，需要手动启动。

10. 高可用视角：离线环境下的扩展思路

前面的流程是基于单控制平面节点的，如果只是想先跑起来，那已经够用了。但对于生产性质的离线场景，单控制平面始终存在单点风险，控制平面节点一旦宕机，整个集群的管理面就瘫痪了。

高可用方案在离线环境里会增加不少复杂度，核心在于 etcd 的集群配置和负载均衡器的引入。如果你有三台以上的机器，可以考虑将三台都作为控制平面节点，外部再放一个 HAProxy 或 keepalived 作为 API Server 的入口。这样即使某一台 master 挂了，集群的调度和 API 访问依然可用。

但高可用配置的离线坑更多：etcd 的证书需要提前生成和分发、kubeadm 的配置文件需要指定多个控制平面地址、负载均衡器的健康检查配置。这些内容一篇文章很难全部展开，建议在单机版集群完全跑通、并且对 kubeadm 的运作机制有清晰认知之后再去尝试。

如果你一开始就知道未来要扩展成高可用，那么网络规划上建议预留额外的 VIP 地址和机器资源，不要在单节点架构稳定后再回头改网络拓扑，那种改造成本往往比重新部署还高。

11. 从验证到使用：集群可用的最后一道验收

集群搭建完成不代表工作结束。我一般会做一套完整的验收动作，简单但覆盖面广。第一步是在集群里部署一个测试用的 Deployment 并暴露成 NodePort 服务，从集群外部通过任一节点的 IP 访问验证南北向流量。测试应用可以用 nginx 或者直接用你业务体系的简单服务，关键是方便验证。

第二步是验证 DNS 解析。假如你部署了一个 nginx 服务，在集群内另起一个临时 Pod，用 nslookup nginx.<namespace>.svc.cluster.local 去解析服务名，确认 CoreDNS 工作正常。如果解析不出来，后端服务的 Pod 之间想通过 Service 域名互相调用就是空中楼阁。

第三步是验证控制器能力。手动把测试 Deployment 的副本数调成 0，观察 ReplicaSet 是否能自动拉回一个副本，以及被删掉的 Pod 是否会按照 DaemonSet 或 Deployment 的声明被重新创建。这个步骤虽然很基础，但能直接反映 controller-manager 的健康状态。

验收结束后，把临时的测试资源清理干净：

bash复制kubectl delete deployment <test-name>
kubectl delete service <test-name>

然后在每个节点上用 df -h 和 free -m 简单确认资源水位没被测试数据拉高。整个集群的可运行状态就算基本确认了。

我个人对这套流程的评价是：能跑通不稀奇，能快速复制才叫能力。下次如果还要在新的隔离环境搭集群，我会先准备一份物料 check list，再从 U 盘拷出 RPM 包和镜像 tar，严格照着顺序执行，基本可以把搭建时间压缩到一个小时以内。但前提是每一步都不要跳、每个验证都不要省。离线部署容错率低，一步错可能就要 reset 重来，那些多花几分钟做检查的时间，从结果看你从来不会后悔。