kubeadm部署Kubernetes集群实战与Docker运行时选择

1. 为什么选择kubeadm部署Kubernetes集群

作为在容器编排领域摸爬滚打多年的老运维，我见证过各种Kubernetes部署工具的兴衰。早期确实习惯用Rancher的RKE工具，它像一把瑞士军刀——开箱即用、简单粗暴。但最近两年，越来越多的同行开始转向官方kubeadm工具，这背后有几个关键原因：

首先，kubeadm作为CNCF官方认证的部署工具，版本迭代与Kubernetes核心版本保持完美同步。我去年就遇到过RKE对1.24版本支持延迟的情况，而kubeadm在发布当天就能用。其次，kubeadm生成的集群符合标准API规范，后续要对接ArgoCD、Prometheus等生态工具时兼容性更好。最重要的是，当集群出现问题时，kubeadm的报错信息更贴近上游代码，社区解决方案也更多。

不过kubeadm也不是银弹。相比RKE的一键式部署，kubeadm需要手动配置更多组件（比如CNI网络插件），对新手确实不够友好。但换个角度看，这反而能让我们更深入理解Kubernetes的架构原理。

2. 关键组件版本选型决策

2.1 关于容器运行时的选择困境

Kubernetes 1.24版本移除Docker支持时，我们团队内部争论了很久。官方推荐转向containerd固然有其道理——更轻量、更符合OCI标准。但现实情况是：

1. 运维团队对docker命令体系已经形成肌肉记忆，排查问题时docker ps和docker logs比crictl顺手太多
2. 现有CI/CD流水线中大量使用docker build构建镜像
3. Docker的日志驱动、存储驱动等配置项更直观

经过性能测试，我们发现通过cri-dockerd桥接Docker的方案，与纯containerd相比性能损耗不到5%，这个代价完全可以接受。最终拍板决定：生产环境继续用Docker作为运行时，等团队containerd技能成熟后再逐步迁移。

2.2 为什么选择Docker 29.0

这个版本有个不起眼但极其实用的改进——镜像标记系统。当执行docker pull时，新下载的镜像会被标记为U（Unused），而正在使用的镜像保持原有标签。这样当我们执行docker image prune时，可以放心添加-a参数，系统会自动保护正在使用的镜像。

这个特性完美解决了我们过去遇到的痛点：某次清理镜像时误删了生产环境正在使用的Redis镜像，导致服务短暂中断。现在有了这个保护机制，日常维护时心里踏实多了。

3. 集群部署全流程实操

3.1 基础环境准备

3.1.1 系统配置调优

所有节点（包括master和worker）都需要执行以下操作：

bash复制# 禁用swap（Kubernetes强制要求）
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# 关闭防火墙（生产环境建议配置精准规则）
sudo systemctl stop ufw
sudo systemctl disable ufw

# 加载内核模块
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 内核参数调整
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.i