K8s:基于KubeKey的Kubernetes1.26.12离线部署与Harbor私有仓库集成实战

1. 为什么选择KubeKey进行离线部署？

如果你正在一个与互联网物理隔离的环境里工作，比如某些对安全要求极高的企业内部网络、研发测试内网，或者干脆就是机房压根没给你拉外网线，那么给这个环境部署一套Kubernetes集群，绝对是个让人头疼的活儿。传统的在线安装方式，动辄就要从Docker Hub、Quay.io这些公共仓库拉取上百个G的镜像，在离线环境下根本行不通。我经历过好几次，要么是拿着U盘一个个镜像倒腾，要么是写一堆复杂的脚本同步，过程繁琐不说，还容易出错。

后来我发现了KubeKey这个工具，它简直就是为离线环境而生的“瑞士军刀”。KubeKey是KubeSphere社区开源的一款集群部署工具，它最大的亮点就是把Kubernetes集群部署过程中所有依赖的组件，包括二进制文件、容器镜像、配置文件，全部打包成一个完整的离线安装包。你可以把它想象成一个“全家桶”安装包，在能上网的机器上一次性准备好所有食材，然后直接搬到离线厨房里开火做饭。这样一来，部署过程就变得极其简单和可控。

我这次要分享的，就是基于KubeKey，在一个完全离线的麒麟服务器上，部署Kubernetes 1.26.12集群，并且让它和已经部署好的Harbor 2.13.1私有镜像仓库无缝集成的全过程。这个组合特别适合企业生产环境，既能保证部署过程的安全、可控、可重复，又能利用私有仓库管理所有镜像，实现真正的内网闭环。整个流程我踩过不少坑，也总结了很多实用的技巧，下面我就手把手带你走一遍。

2. 战前准备：理清思路与备齐弹药

在真正动手之前，我们必须把整个部署的逻辑和所需的“弹药”搞清楚。离线部署的核心思想就是“一次准备，到处部署”。我们需要两台机器：一台能临时连接互联网的“跳板机”（也叫构建机），以及最终要部署集群的离线目标服务器。

2.1 环境清单与架构规划

首先，我们明确一下这次实战的环境。我的目标服务器是一台搭载Hygon C86 7285处理器的麒麟操作系统服务器，完全离线。我已经在上面独立部署好了Harbor 2.13.1作为私有镜像仓库，地址是 172.23.123.117:8443。我们的目标是在这台服务器上，用KubeKey部署一个单节点的Kubernetes 1.26.12集群（生产环境建议至少3节点），并使用containerd 1.7.27作为容器运行时。

这里有个关键点：KubeKey本身不包含Harbor。我们的Harbor是预先独立部署好的，KubeKey的任务是部署K8s集群，并让这个集群在创建Pod时，能自动从我们指定的Harbor仓库拉取镜像。所以，整个数据流是这样的：在跳板机上下载所有K8s和KubeSphere的镜像，推送到Harbor；然后在离线服务器上，KubeKey会从Harbor拉取这些镜像来创建集群。

2.2 联网跳板机：下载工具与生成物料清单

现在，我们转移到那台能上网的跳板机上进行操作。

第一步，下载指定版本的KubeKey。我选择的是v3.1.10版本，它完美支持Kubernetes 1.26.12。直接使用wget或curl下载即可。

wget https://kubernetes.pek3b.qingstor.com/kubekey/releases/download/v3.1.10/kubekey-v3.1.10-linux-amd64.tar.gz
tar -zxvf kubekey-v3.1.10-linux-amd64.tar.gz
cd kubekey
chmod +x kk

解压后你会得到一个名为 kk 的二进制文件，这就是我们核心的工具。接下来，我们需要一份详细的“购物清单”，也就是 manifest 文件。这个文件定义了我们要部署的Kubernetes版本、各种组件的版本，以及最关键的所有镜像列表。

KubeKey提供了一个命令来生成清单模板：

./kk create manifest --with-kubernetes v1.26.12

执行后，会生成一个 manifest-sample.yaml 文件。但这里有个大坑：这个初始文件里的镜像地址默认是Docker Hub等海外源。在国内网络环境下，或者为了后续推送到自己的Harbor，我们需要替换成可访问的镜像源。KubeSphere官方很贴心地提供了基于华为云镜像仓库的清单文件 kk-manifest-mirror.yaml，我们可以从 https://get-images.kubesphere.io/ 这个地址找到并下载它。

我们的操作是：用 kk-manifest-mirror.yaml 文件里庞大的镜像列表，替换掉 manifest-sample.yaml 中 images: 部分的内容。同时，我们还需要在 manifest-sample.yaml 中精确指定各组件的版本，比如 helm、cni、etcd、containerRuntimes 等。下面是我调整后的 manifest-sample.yaml 关键部分示例：

apiVersion: kubekey.kubesphere.io/v1alpha2
kind: Manifest
metadata:
  name: sample
spec:
  arches:
  - amd64
  operatingSystems: []
  kubernetesDistributions:
  - type