1. 为什么要给Kubernetes集群添加新节点?
当您的业务量像春笋般快速增长时,原有的Kubernetes集群可能会遇到以下情况:
- Pod调度失败提示"节点资源不足"
- 现有节点CPU使用率长期超过80%
- 工作负载出现频繁的OOM(内存溢出)告警
最近某电商平台在大促期间就遇到了这样的困境:原有10个Node节点同时处理着500+微服务实例,突增的流量导致所有节点资源吃紧。运维团队通过添加5个新节点,成功将集群容量扩容50%,平稳度过了流量洪峰。
2. 扩容前的必要准备
2.1 硬件规格检查
新节点需要满足以下基本要求:
# 验证CPU架构(示例节点配置)
lscpu | grep Architecture # 必须与主节点架构一致
Architecture: x86_64
# 检查内存容量(建议不低于4GB)
free -h
total used free
Mem: 16Gi 1.2Gi 14Gi
# 存储空间验证(推荐50GB以上系统盘)
df -h /
Filesystem Size Used Avail Use%
/dev/nvme0n1p2 80G 18G 62G 23%
2.2 环境预配置
每个新节点都需要完成以下基础配置:
# 关闭Swap分区(必须操作)
sudo swapoff -a
sudo sed -i '/ swap / s/^\(.*\)$/#\1/' /etc/fstab
# 安装容器运行时(以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
sudo systemctl restart containerd
# 设置内核参数(网络相关)
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter
3. 添加新节点的详细步骤(基于kubeadm)
3.1 在主节点生成加入命令
# 查看当前token列表(有效期24小时)
kubeadm token list
TOKEN TTL EXPIRES
abcd12.xyz345defg 23h 2024-03-01T09:00:00Z
# 生成新的永久token(用于长期维护)
kubeadm token create --ttl 0
# 获取CA证书哈希值
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | \
openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex
# 拼接完整的加入命令(示例格式)
kubeadm join 192.168.1.100:6443 \
--token xyz123.abc456def \
--discovery-token-ca-cert-hash sha256:d3b07384d113edec49eaa6238ad5ff00
3.2 新节点执行加入操作
# 步骤1:安装kubeadm等组件(Ubuntu示例)
sudo apt-get update && sudo apt-get install -y kubeadm=1.28.0-00 kubelet=1.28.0-00
# 步骤2:执行加入命令(注意替换真实参数)
sudo kubeadm join 192.168.1.100:6443 \
--token xyz123.abc456def \
--discovery-token-ca-cert-hash sha256:d3b07384d113edec49eaa6238ad5ff00
# 成功输出示例(注意最后两行)
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
4. 必须配置的关联组件
4.1 网络插件配置(以Calico为例)
# 主节点执行网络插件安装(已存在集群可跳过)
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml
# 新节点自动获取网络配置后查看状态
kubectl get pods -n kube-system -o wide | grep calico-node
calico-node-abc12 1/1 Running 0 2h 192.168.1.101 node01
calico-node-xyz45 1/1 Running 0 10m 192.168.1.105 node-new01
4.2 节点标签管理
# 给新节点添加SSD标签
kubectl label nodes node-new01 disktype=ssd
# 查看所有节点标签
kubectl get nodes --show-labels
NAME STATUS LABELS
node-new01 Ready disktype=ssd,kubernetes.io/hostname=node-new01
5. 核心技术的深度解析
5.1 扩容方案对比
特性 | 手动节点扩容 | Cluster Autoscaler | 第三方扩容工具 |
---|---|---|---|
响应速度 | 分钟级 | 秒级 | 依赖工具性能 |
资源利用率 | 依赖人工判断 | 自动优化 | 可配置策略 |
运维复杂度 | 高 | 低 | 中 |
适用场景 | 临时扩容 | 弹性伸缩 | 混合云环境 |
5.2 常见问题解决方案
问题1:加入集群时报错"x509 certificate signed by unknown authority"
# 解决方法:同步主节点时间
sudo timedatectl set-ntp true
sudo apt install chrony -y
sudo systemctl restart chrony
问题2:节点状态显示NotReady
# 检查容器运行时状态
sudo systemctl status containerd
● containerd.service - containerd container runtime
Loaded: loaded (/lib/systemd/system/containerd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2024-02-28 10:00:00 CST; 5min ago
6. 生产环境中的注意事项
- 资源分配策略:建议保留10%-20%的系统资源不分配给Kubernetes
- 版本一致性:确保kubelet、kubeadm等组件版本与主节点完全一致
- 安全组设置:新节点需要开放以下端口:
- 6443(API Server)
- 2379-2380(etcd)
- 10250-10259(Kubelet等组件)
- 污点设置建议:为专用节点添加污点防止误调度
kubectl taint nodes node-gpu01 special=gpu:NoSchedule
7. 应用场景与技术总结
典型应用场景:
- 电商大促期间的临时扩容
- 机器学习训练任务的专用节点
- 多地域部署时的区域节点扩展
技术优势:
- 在线扩容无需停机维护
- 资源分配粒度可达CPU核心级别
- 支持混合架构(如x86与ARM混合集群)
潜在风险:
- 节点过多可能导致etcd存储压力
- 跨AZ节点间网络延迟可能影响服务
- 裸金属节点需要考虑物理维护成本