Linux下K8S集群部署教程

本文详细解析了在Linux环境下使用kubeadm可靠部署Kubernetes生产级集群的完整实践路径，直击国内用户高频踩坑点：从必备前提（关闭swap、时间同步、systemd与cgroup driver一致性）到镜像加速配置，从kubeadm init常见卡顿（control-plane就绪失败、etcd异常）的根因排查与清理技巧，到CNI插件（Calico/Flannel）选型、版本匹配及网络配置要点，再到node节点反复重启kubelet的权限、token时效、容器运行时兼容性等深层问题，强调真正决定成败的不是命令本身，而是那些容易被忽略却环环相扣的隐式依赖——这是一份聚焦落地细节、拒绝纸上谈兵的硬核实战指南。

直接用 kubeadm 部署是最靠谱的起点

别碰二进制手动装，也别用 minikube 或 kind 当生产集群用——它们解决的是开发/测试场景，不是“Linux 部署 Kubernetes 集群”这个需求本身。kubeadm 是官方维护、版本对齐、文档完整、社区验证过的标准路径，只要你的节点满足基础条件（2 核+、2GB+ 内存、swap 关闭、容器运行时就绪），它就能跑起来。

• swapoff -a 必须执行，否则 kubeadm init 会直接报错 [preflight] [ERROR Swap]: running with swap on is not supported
• 确认 systemd 是默认 init 系统（CentOS 7+/Ubuntu 16.04+ 默认满足），kubeadm 依赖 cgroup driver = systemd，和 Docker 默认的 cgroupfs 冲突时要改配置
• 所有节点时间必须同步，chrony 或 ntpd 跑稳，否则证书握手失败、etcd 启动卡住

kubeadm init 失败常见原因和绕过方法

最常卡在 waiting for the control-plane 或 etcd 不就绪，根本不是命令写错了，而是环境没清理干净或镜像拉不下来。

• 国内环境默认拉不到 k8s.gcr.io 镜像：提前用 crictl pull 或 docker pull 拉好对应版本镜像（如 registry.aliyuncs.com/google_containers/kube-apiserver:v1.28.2），再用 kubeadm config images list 和 kubeadm config images pull --image-repository registry.aliyuncs.com/google_containers
• 如果已有旧集群残留（比如上次 kubeadm reset 没清干净），/etc/kubernetes/manifests/ 下的静态 Pod 文件、/var/lib/etcd 目录、/etc/cni/net.d/ 都得手动删掉
• kubeadm init 默认绑定 0.0.0.0:6443，如果服务器有多个网卡，得加 --apiserver-advertise-address=实际内网IP，否则 node 加入时连不上 control-plane

kubectl get nodes 显示 NotReady？先查 CNI 插件

control-plane 起来了，但 node 状态卡在 NotReady，90% 是网络插件没装或装错版本。kubeadm 不自带 CNI，必须手动选一个并部署。

• Calico 最稳：用官方 manifest（如 https://raw.githubusercontent.com/projectcalico/calico/v3.27.2/manifests/calico.yaml），注意检查 CALICO_IPV4POOL_CIDR 是否和 kubeadm init 的 --pod-network-cidr 一致（默认是 192.168.0.0/16）
• Flannel 要求 kube-proxy 运行在 iptables 模式（不是 nftables），Ubuntu 22.04+ 默认用 nftables，得在 kubeadm init 前加参数：--feature-gates=SupportIPVSProxyMode=false，再改 kube-proxy ConfigMap
• 装完插件后等 1–2 分钟，kubectl get pods -n kube-system 看 calico-node 或 kube-flannel-ds 是否 Running，不是 Pending 或 CrashLoopBackOff

node 加入集群后反复重启 kubelet

现象是 systemctl status kubelet 显示 active (running)，但几秒后变成 activating (auto-restart)，日志里反复出现 failed to run Kubelet 或 failed to load Kubeconfig。

• 检查 /etc/kubernetes/kubelet.conf 是否存在且权限正确（root:root，644），kubeadm join 命令生成的 token 过期（默认 24 小时），要用 kubeadm token create --print-join-command 重生成
• 确认 node 上的 containerd 或 docker 版本和 control-plane 兼容（例如 k8s v1.28 不支持 containerd v2.0+，得用 v1.7.x）
• 如果用了自定义 --cgroup-driver（比如 systemd），node 上的 kubelet 启动参数也要显式指定，改 /var/lib/kubelet/config.yaml 或 /etc/default/kubelet，然后 systemctl daemon-reload && systemctl restart kubelet

真正麻烦的从来不是命令怎么敲，而是每个环节的隐式依赖：镜像源、cgroup 驱动、时间同步、网络策略、token 有效期——漏掉一个，整个流程就卡在某个看似无关的报错里。

今天关于《Linux下K8S集群部署教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！