4. Kubernetes集群搭建：使用kubeadm搭建生产级集群、高可用架构设计

说实话，很多人在学Kubernetes时，第一步就被集群搭建劝退了。我当年也一样，看着官方文档里密密麻麻的步骤，心里直打鼓。但后来我发现，只要理解了kubeadm的设计思路，搭建过程其实挺顺的。今天我就把生产级集群的搭建经验掰开揉碎讲给你听。

4.1 为什么选择kubeadm？

kubeadm是Kubernetes官方推荐的集群搭建工具。它不像二进制部署那样繁琐，也不像minikube那样玩具化。说白了，它就是为生产环境设计的——既能保证组件的正确配置，又保留了足够的定制空间。

我在项目中遇到过不少团队，一开始图省事用一键部署脚本，结果到了生产环境各种踩坑。后来都老老实实换回了kubeadm。为什么？因为kubeadm生成的配置是标准化的，出了问题社区里一搜就有答案。

核心优势：

  • 官方维护，版本迭代同步
  • 支持高可用架构
  • 证书自动管理
  • 配置可审计、可回溯

4.2 环境准备：别在这些细节上翻车

嗯，这里要注意，环境准备是翻车重灾区。我见过有人因为hostname没配好，折腾了一整天。

4.2.1 节点规划

生产环境我建议至少准备3台master节点和3台worker节点。你想想看，如果只有2台master，etcd集群脑裂的风险就很高。我个人习惯用奇数节点，这样选主时不容易出问题。

角色 推荐配置 数量
Master节点 4C8G, 100G SSD 3
Worker节点 8C16G, 200G SSD 3+
负载均衡器 2C4G 2

4.2.2 系统初始化

所有节点都要做这几步，少一步后面都可能出幺蛾子：

# 关闭swap
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

# 加载内核模块
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.ip_forward                 = 1
EOF

sudo sysctl --system

我曾经踩过的坑：忘记关闭swap，结果kubelet启动失败，报错信息还特别隐晦。排查了半天才发现是swap没关。所以建议你把这步写在checklist里，每次部署前逐项核对。

4.3 容器运行时安装：containerd实战

Docker虽然好用，但Kubernetes从1.24开始就弃用dockershim了。现在主流的选择是containerd。我推荐用containerd，它比CRI-O生态更成熟，比Docker更轻量。

# 安装containerd
sudo apt-get update
sudo apt-get install -y containerd

# 生成默认配置
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# 关键配置：使用systemd cgroup驱动
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

# 重启服务
sudo systemctl restart containerd
sudo systemctl enable containerd

小技巧：配置完containerd后，记得用crictl info检查一下。如果输出里显示systemdCgroup: true，说明配置生效了。这一步很多人会漏掉，等到kubelet报错才回头查。

4.4 安装kubeadm、kubelet、kubectl

这三个组件要一起装，版本必须一致。我习惯用阿里云的镜像源，国内下载速度快很多。

# 添加Kubernetes仓库
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl

sudo curl -fsSL https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

# 安装指定版本（以1.28为例）
sudo apt-get update
sudo apt-get install -y kubelet=1.28.0-00 kubeadm=1.28.0-00 kubectl=1.28.0-00
sudo apt-mark hold kubelet kubeadm kubectl

为什么要hold住版本？因为生产环境最怕版本不一致。我曾经见过一个团队，某天apt upgrade后kubelet自动升级了，结果和集群其他节点版本不匹配，整个集群都受影响。从那以后，我所有生产节点都锁版本。

4.5 高可用架构设计：不只是堆机器

高可用不是简单地把master节点堆到3台就完事了。这里有几个关键点要搞清楚。

4.5.1 控制平面高可用

Kubernetes控制平面的核心是etcd和API Server。etcd用Raft协议保证一致性，API Server通过负载均衡对外提供服务。

我个人习惯用HAProxy + Keepalived做API Server的负载均衡。Nginx也可以，但HAProxy在四层负载均衡上性能更好。

# HAProxy配置示例（/etc/haproxy/haproxy.cfg）
frontend kubernetes-frontend
    bind *:6443
    mode tcp
    option tcplog
    default_backend kubernetes-backend

backend kubernetes-backend
    mode tcp
    option tcp-check
    balance roundrobin
    server master1 192.168.1.11:6443 check fall 3 rise 2
    server master2 192.168.1.12:6443 check fall 3 rise 2
    server master3 192.168.1.13:6443 check fall 3 rise 2

关键点：负载均衡器本身也要高可用。Keepalived的VIP漂移时间建议设为2秒以内，这样API Server的切换对客户端几乎是透明的。

4.5.2 etcd集群部署

etcd是Kubernetes的"数据库"，它的稳定性直接决定集群的可用性。我建议把etcd单独部署在master节点上，不要和业务容器混跑。

# 在第一个master节点初始化
sudo kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:6443" \
  --upload-certs \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=MASTER1_IP

# 其他master节点加入
sudo kubeadm join LOAD_BALANCER_DNS:6443 --token xxx \
  --discovery-token-ca-cert-hash sha256:xxx \
  --control-plane --certificate-key xxx

注意：etcd的磁盘性能很关键。我建议用SSD，并且单独挂载。如果用的是云盘，选IOPS高的类型。etcd对延迟特别敏感，磁盘慢了整个集群都会受影响。

4.6 网络插件选择：CNI的学问

网络插件是集群搭建的最后一步，也是最容易出问题的一步。主流选择有Calico、Flannel、Cilium。我推荐Calico，它支持网络策略，性能也不错。

# 安装Calico
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26/manifests/calico.yaml

# 检查Pod状态
kubectl get pods -n kube-system -l k8s-app=calico-node

安装完成后，用kubectl get nodes检查节点状态。如果所有节点都变成Ready，恭喜你，集群搭建成功了。

4.7 验证集群：别急着上线

集群搭建完，我建议先跑一轮验证，确保所有功能正常。

  1. 节点状态检查：所有节点Ready，版本一致
  2. 核心组件检查：coredns、kube-proxy等Pod正常运行
  3. etcd健康检查：etcdctl endpoint health返回正常
  4. 调度测试：部署一个nginx，确认能正常调度到worker节点
  5. 高可用测试：手动停掉一个master节点，看集群是否正常工作

我的经验：高可用测试一定要做，而且要在业务低峰期做。我第一次做测试时，停掉一个master节点后，发现API Server的响应时间从10ms飙到了200ms。排查后发现是负载均衡器的健康检查间隔设置太长。调整后就好了。

4.8 生产环境建议

最后，分享几个生产环境的实用建议：

  • 证书管理：kubeadm默认证书有效期1年，记得提前规划续期
  • 日志收集：建议用EFK或Loki，别等到出问题才想起来看日志
  • 监控告警：Prometheus + Grafana是标配，etcd的监控指标尤其重要
  • 备份策略：etcd定期备份，建议每小时一次，保留7天

搭建生产级Kubernetes集群，说白了就是要把每个细节都做到位。别想着一步到位，先搭一个最小可用集群，然后逐步完善。我见过太多人一开始就想搞个"完美"集群，结果卡在某个细节上出不来。记住，先跑起来，再优化。

← 上一章 📖 返回目录 下一章 →