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. 生产环境中的注意事项

  1. 资源分配策略:建议保留10%-20%的系统资源不分配给Kubernetes
  2. 版本一致性:确保kubelet、kubeadm等组件版本与主节点完全一致
  3. 安全组设置:新节点需要开放以下端口:
    • 6443(API Server)
    • 2379-2380(etcd)
    • 10250-10259(Kubelet等组件)
  4. 污点设置建议:为专用节点添加污点防止误调度
    kubectl taint nodes node-gpu01 special=gpu:NoSchedule
    

7. 应用场景与技术总结

典型应用场景

  • 电商大促期间的临时扩容
  • 机器学习训练任务的专用节点
  • 多地域部署时的区域节点扩展

技术优势

  1. 在线扩容无需停机维护
  2. 资源分配粒度可达CPU核心级别
  3. 支持混合架构(如x86与ARM混合集群)

潜在风险

  • 节点过多可能导致etcd存储压力
  • 跨AZ节点间网络延迟可能影响服务
  • 裸金属节点需要考虑物理维护成本