离线安装Kubernetes集群关键在于资源完整性、镜像可用性及依赖链就位：必须确保/etc/hosts全节点互通、kubelet已启用且cgroupDriver一致、时间同步误差≤1s；镜像须按pause→etcd→控制平面顺序加载；kubeadm init需显式指定--image-repository=""和--cri-socket=/run/containerd/containerd.sock。
离线安装 Kubernetes 集群不是“把包拷过去就能跑”，关键在于资源完整性、镜像可用性、以及 kubeadm init 启动时的依赖链是否全部就位。跳过任何一环，大概率卡在 failed to pull image 或 etcd connection refused。
离线部署前必须确认的三件事
很多失败源于“以为准备好了”，实际缺了隐性依赖：
- 所有节点的
/etc/hosts必须包含全部集群节点的 IP + 主机名映射（不能只配 master 访问 worker）；kubeadm join会通过 hostname 解析其他 master 的地址，hostname 不通直接失败 -
kubelet服务必须已启用并运行（systemctl enable --now kubelet），且不报cgroup driver: systemd冲突 —— Ubuntu 22.04+ 默认用systemd，但若手动改过 Docker 的daemon.json，需同步调整/var/lib/kubelet/config.yaml中的cgroupDriver - 时间必须严格同步（
chrony或systemd-timesyncd），误差 >1s 可能导致 TLS 证书校验失败，kubeadm init报x509: certificate has expired or is not yet valid
镜像加载顺序不能乱：先 etcd，再 pause，最后控制平面组件
离线环境里，kubeadm init 默认从 registry.k8s.io 拉镜像，你得提前用 docker load 或 ctr -n k8s.io images import 加载到本地。但加载顺序错，kubeadm 仍会因依赖缺失而失败：
- 必须最先加载
registry.k8s.io/pause:3.9（或对应版本）—— 它是所有 Pod 的基础沙箱容器，kubelet 启动第一个 static pod 前就要它 - 其次加载
registry.k8s.io/etcd:3.5.14-0——kubeadm init初始化阶段立即调用 etcd，没这个镜像会卡在 “Waiting for etcd” - 最后加载
registry.k8s.io/kube-apiserver:v1.27.15等控制平面镜像 —— 它们由kubeadm在 etcd 就绪后按需拉取，但离线时必须已存在本地镜像仓库或本机
验证方式：docker images | grep -E "(pause|etcd|apiserver)"，三个都得有，且 tag 匹配你 kubeadm version 对应的 Kubernetes 小版本。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
kubeadm init 参数要带 --image-repository 和 --cri-socket
Ubuntu 22.04 默认用 containerd，但 kubeadm init 仍可能误判为 Docker，导致找不到 CRI socket；同时，不指定私有镜像仓库地址，它还是会去公网拉取：
-
--image-repository必须设为你本地 registry 地址（如192.168.1.100:5000）或空字符串（表示用本地镜像），不能留默认值 -
--cri-socket显式指定为/run/containerd/containerd.sock（Ubuntu 22.04+ containerd 路径），避免kubeadm自动探测失败 - 完整命令示例：
sudo kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=192.168.1.11 \ --image-repository="" \ --cri-socket=/run/containerd/containerd.sock
高可用场景下，keepalived + haproxy 的配置容易漏掉两个点
三主节点离线部署时，VIP（如 192.168.1.100）不是配完 keepalived 就自动生效的：
-
haproxy.cfg中的bind *:16443必须监听0.0.0.0，不能写成127.0.0.1:16443—— 否则其他 master 节点无法通过 VIP 连接 API Server -
keepalived.conf的vrrp_instance VI_1下必须加advert_int 1（通告间隔 1 秒），否则 VIP 切换延迟高达 3–5 秒，在kubeadm join过程中可能因超时失败 - 所有 master 节点的
kubeadm init命令中，--control-plane-endpoint必须设为 VIP + 端口（如192.168.1.100:16443），且该 VIP 必须已在首个 master 上成功漂移并响应curl -k https://192.168.1.100:16443/healthz
最常被忽略的是：VIP 所在网段的交换机必须允许 VRRP 协议（协议号 112），某些政企网络设备默认禁用，会导致 keepalived 无法发送通告包，VIP 一直不生效。
