CentOS 7.9上k8s v1.15.1初始化踩坑实录：从preflight报错到集群就绪的完整排障指南
那天深夜的报警短信把我从睡梦中惊醒——生产环境的Kubernetes集群突然崩溃，而更糟的是，这个运行着v1.15.1版本的老集群文档早已遗失。作为团队最后接触过这个版本的人，我不得不在CentOS 7.9上重新搭建一套相同版本的环境。本以为轻车熟路，却没想到从kubeadm init开始就遭遇了preflight的连环阻击。本文将还原这段从绝望到重生的48小时排障历程，不仅包含技术解决方案，更重要的是分享那些官方文档没写的"生存技巧"。
1. 环境准备：那些看似无关紧要的细节
1.1 系统配置的隐形陷阱
在CentOS 7.9上安装Kubernetes v1.15.1时，我犯的第一个错误就是低估了系统配置的敏感性。以下是必须检查的基础配置清单：
SELinux状态：运行
getenforce必须显示Permissive或Disabled防火墙规则：清空所有规则或确保以下端口开放（实际需要更多端口，但这是最小集）：
协议 端口范围 用途 TCP 6443 Kubernetes API TCP 2379-2380 etcd客户端/对等通信 TCP 10250 Kubelet API 时间同步：使用
chronyd确保时间偏差小于100ms主机名解析：
/etc/hosts必须包含所有节点的主机名映射
提示：在虚拟机环境中，务必检查MAC地址是否冲突，这会导致网络插件出现难以诊断的问题
1.2 依赖组件的版本矩阵
Kubernetes v1.15.1对周边组件的版本要求极为苛刻，这是导致preflight失败的高频原因。经过反复测试，我整理出这个版本的黄金组合：
# 验证过的组件版本组合 DOCKER_VERSION="18.09.8-3.el7" KUBERNETES_VERSION="1.15.1-0" ETCD_VERSION="3.3.15-0"安装指定版本Docker的命令序列：
# 移除现有Docker sudo yum remove -y docker* containerd.io # 安装特定版本 sudo yum install -y docker-ce-$DOCKER_VERSION docker-ce-cli-$DOCKER_VERSION # 关键配置：修改cgroup驱动为systemd sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json <<EOF { "exec-opts": ["native.cgroupdriver=systemd"] } EOF # 重启服务 sudo systemctl enable --now docker2. preflight报错深度解析
2.1 Swap报错背后的真相
当看到[ERROR Swap]: running with swap on is not supported这个报错时，大多数教程会教你简单运行swapoff -a。但实际生产环境中，这远远不够：
持久化禁用Swap：
# 临时禁用 sudo swapoff -a # 永久禁用（需重启） sudo sed -i '/swap/d' /etc/fstab sudo sed -i '/^\/swapfile/d' /etc/fstab内核参数调整：
# 防止kubelet因内存压力被杀 echo "vm.overcommit_memory=1" | sudo tee -a /etc/sysctl.conf sudo sysctl -p
注意：在内存有限的机器上，完全禁用Swap可能导致OOM Killer终止关键进程。此时可以设置
--fail-swap-on=false参数，但这会失去官方支持
2.2 Docker版本兼容性迷宫
WARNING SystemVerification: this Docker version is not on the validated list这个警告比想象中危险。v1.15.1的兼容性列表早已不可查，但通过源码分析发现：
必须匹配的组件：
- Docker API版本 ≤ 1.39
- containerd版本 ≤ 1.2.10
验证方法：
# 检查Docker API版本 docker version --format '{{.Server.APIVersion}}' # 检查containerd版本 containerd --version
如果不得不使用非官方认证版本，可以通过修改kubelet参数跳过验证（不推荐）：
sudo sed -i 's/--enforce-node-allocatable=/--enforce-node-allocatable=&\n--runtime-cgroups=\/systemd\/system.slice/' /var/lib/kubelet/kubeadm-flags.env3. 那些年我们踩过的kubeadm坑
3.1 证书参数迁移陷阱
--experimental-upload-certs has been deprecated这个错误看似简单，但在v1.15.1这个过渡版本中，证书处理有多个隐藏细节：
正确的初始化命令：
kubeadm init \ --kubernetes-version=v1.15.1 \ --pod-network-cidr=10.244.0.0/16 \ --service-cidr=10.96.0.0/12 \ --upload-certs \ --ignore-preflight-errors=Swap 2>&1 | tee kubeadm-init.log证书备份关键步骤：
# 备份证书目录 sudo cp -r /etc/kubernetes/pki /opt/k8s-pki-backup # 备份kubeconfig mkdir -p $HOME/.kube sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config
3.2 网络插件的版本适配
Flannel的现代版本已不兼容v1.15.1，必须使用特定配置：
# kube-flannel.yml apiVersion: extensions/v1beta1 kind: DaemonSet metadata: name: kube-flannel-ds labels: tier: node app: flannel spec: template: spec: containers: - name: kube-flannel image: quay.io/coreos/flannel:v0.11.0-amd64 command: ["/opt/bin/flanneld"] args: [ "--ip-masq", "--kube-subnet-mgr", "--iface=eth0" # 根据实际网卡修改 ]应用配置时需要额外步骤：
# 先应用CRD kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.11.0/Documentation/kube-flannel.yml # 等待5分钟后检查状态 watch kubectl get pods -n kube-system -l app=flannel4. 集群验证与灾备方案
4.1 健康检查的三重验证
基础状态检查：
kubectl get --raw='/readyz?verbose' | jq .组件健康度：
# 检查控制平面组件 for comp in kube-apiserver kube-controller-manager kube-scheduler; do kubectl -n kube-system get pods -l component=$comp -o wide done网络连通性测试：
# 创建测试Pod kubectl run -it --rm --restart=Never testpod --image=busybox -- sh # 在Pod内执行 ping kubernetes.default.svc.cluster.local
4.2 旧版本特有的备份方案
由于velero等工具对新版本支持更好，对于v1.15.1建议采用以下备份策略：
etcd手动备份：
# 在master节点执行 sudo docker run --rm \ -v /var/lib/etcd:/var/lib/etcd \ -v /opt/etcd-backup:/backup \ --network host \ k8s.gcr.io/etcd:3.3.15 \ etcdctl --endpoints=http://127.0.0.1:2379 \ snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db关键资源配置导出：
# 导出所有命名空间资源 for ns in $(kubectl get ns -o jsonpath='{.items[*].metadata.name}'); do mkdir -p cluster-backup/$ns kubectl get -n $ns all -o yaml > cluster-backup/$ns/resources.yaml done
在经历了无数次kubeadm reset和重新初始化后，我终于理解了为什么这个旧版本会被弃用——它就像一位固执的老工匠，需要你用特定的方式与之对话。最讽刺的是，当我最终成功搭建好集群时，发现生产环境的问题其实只是一个简单的etcd磁盘空间不足...但这段经历让我明白，在运维的世界里，没有白踩的坑，每个错误都是通往精通的阶梯。
