橙心橙怡1. 为什么选择kubeasz部署Kubernetes集群
在Kubernetes部署工具百花齐放的今天，kubeasz凭借其独特的二进制部署方式在众多方案中脱颖而出。与常见的kubeadm等工具不同，kubeasz采用Ansible实现全自动化部署，这种设计带来了几个关键优势：
首先，二进制部署方式让你对集群的每个组件都有完全掌控权。不同于封装好的安装包，你能清晰看到每个组件的安装路径、配置文件位置和启动参数。这种透明性对于生产环境排错和性能调优至关重要。我曾在一次性能调优中，通过直接修改kube-apiserver的启动参数，将API响应延迟降低了40%，这在黑盒部署方式下几乎不可能实现。
其次，Ansible的幂等特性让部署过程变得异常可靠。在部署中断或部分节点失败时，重新运行playbook不会导致环境混乱，而是智能地继续完成剩余步骤。这个特性在大规模集群部署中尤其珍贵——想象一下在50个节点的集群中某个节点配置失败，你只需要修复问题后重新运行playbook，而不必从头开始。
提示：kubeasz的离线部署能力在国内网络环境下是决定性优势。所有依赖包和镜像都可以预先下载到本地，完全避免了因网络问题导致的部署失败。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备与规划要点
2.1 硬件资源配置基准线
根据我参与过的十几个生产集群部署经验，合理的资源配置应该遵循以下基准（以最小化生产环境为例）：
| 节点角色 | CPU核心 | 内存 | 磁盘 | 数量 |
|---|---|---|---|---|
| Master | 4 | 8GB | 100GB SSD | 3（高可用） |
| Worker | 8 | 16GB | 200GB SSD | 按需扩展 |
| Etcd | 2 | 4GB | 50GB SSD | 3（独立部署） |
特别注意：etcd节点强烈建议使用SSD磁盘，我在一个客户现场测试发现，使用机械硬盘的etcd集群在节点故障时恢复时间会延长5-8倍。
2.2 系统配置关键项
在开始部署前，这些系统配置必须检查（以CentOS 7为例）：
bash复制# 关闭防火墙
systemctl stop firewalld && systemctl disable firewalld
# 禁用SELinux
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
# 时间同步（关键！）
yum install -y chrony
systemctl enable chronyd && systemctl start chronyd
# 关闭swap
swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
# 内核参数调整
cat > /etc/sysctl.d/k8s.conf <<EOF
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl -p /etc/sysctl.d/k8s.conf
我曾遇到一个棘手的网络问题，最终发现是因为漏掉了net.bridge.bridge-nf-call-iptables参数导致Pod跨节点通信异常。这些配置看似基础，但往往就是集群异常的罪魁祸首。
3. 集群部署实战全流程
3.1 安装文件准备
kubeasz提供了极简的安装方式：
bash复制export release=3.6.9
curl -SL https://github.com/easzlab/kubeasz/releases/download/${release}/ezdown -o /usr/local/bin/ezdown
chmod +x /usr/local/bin/ezdown
ezdown -D
这个脚本会自动下载以下内容到/etc/kubeasz目录：
- Kubernetes各组件二进制文件
- 容器运行时（默认containerd）
- 网络插件（默认calico）
- 必要的系统依赖包
重要技巧：在内网环境可以先在一台能联网的机器执行
ezdown -D，然后将整个/etc/kubeasz目录打包复制到内网机器。这种离线部署方式在金融行业客户中特别受欢迎。
3.2 集群配置的艺术
配置文件/etc/kubeasz/clusters/{集群名}/config.yml是部署的核心，这几个参数需要特别注意：
yaml复制# 全局配置
cluster_name: my-prod-cluster
cluster_domain: cluster.local
# 网络配置（决定Pod IP分配）
kube_service_addresses: 10.96.0.0/16
kube_pods_subnet: 10.244.0.0/16
# 关键组件版本
kube_version: v1.28.5
etcd_version: v3.5.10
containerd_version: 1.7.11
# 高可用配置
enable_ha: true
ha_mode: keepalived # 或者使用nginx方案
vip: 192.168.1.100
网络规划是部署中最容易踩坑的部分。去年我们为一个电商客户部署时，因为Pod网段10.244.0.0/16与其办公网冲突，导致Pod无法访问某些内部系统。后来改为172.16.0.0/16才解决问题。建议在规划时使用ip route show仔细检查现有网络环境。
3.3 执行部署的关键命令
bash复制# 初始化第一个master节点
ezctl new my-prod-cluster
ezctl setup my-prod-cluster 01
# 添加其他master节点（高可用必需）
ezctl add my-prod-cluster master 192.168.1.101
ezctl setup my-prod-cluster 04
# 添加worker节点
ezctl add my-prod-cluster worker 192.168.1.102
ezctl setup my-prod-cluster 05
部署过程中最需要关注的是证书生成和etcd集群启动阶段。我习惯在另一个终端实时查看日志：
bash复制tail -f /var/log/messages | grep -E 'kubelet|etcd|containerd'
如果看到etcd持续报"leader changed"警告，通常意味着网络延迟过高或节点配置不一致。这时需要检查节点间时间同步和网络带宽。
4. 部署后必须做的验证
4.1 基础功能测试清单
bash复制# 检查节点状态
kubectl get nodes -o wide
# 检查核心组件健康状态
kubectl get cs
# 部署测试应用
kubectl create deployment nginx --image=nginx:alpine
kubectl expose deployment nginx --port=80
# 测试网络连通性
kubectl run busybox --rm -it --image=busybox -- sh
wget -qO- nginx
4.2 性能基准测试
使用我的团队总结的快速压测方案：
bash复制# API响应测试
kubectl run --rm -i --tty bench --image=centos --restart=Never \
-- bash -c "time for i in {1..100}; do kubectl get pods >/dev/null; done"
# 网络性能测试（需要提前部署iperf3服务）
kubectl create deploy iperf3-svr --image=networkstatic/iperf3 -- --server
kubectl expose deploy iperf3-svr --port=5201
kubectl run iperf3-cli --rm -it --image=networkstatic/iperf3 -- \
--client iperf3-svr --time 60 --parallel 4
健康的集群应该满足：
- 100次API请求总时间<30秒
- 节点间网络带宽>500Mbps，延迟<1ms
5. 生产环境进阶配置
5.1 关键组件调优参数
在/etc/kubeasz/roles/kube-master/templates/kube-apiserver.service.j2中调整：
ini复制--max-requests-inflight=1500
--max-mutating-requests-inflight=500
--event-ttl=168h
--service-node-port-range=30000-32767
对于大型集群，etcd参数需要特别关注（/etc/kubeasz/roles/etcd/templates/etcd.service.j2）：
ini复制--quota-backend-bytes=8589934592 # 8GB
--max-request-bytes=15728640
--auto-compaction-retention=24
这些参数来自一个实际支撑200+节点的生产环境配置。特别注意quota-backend-bytes需要根据集群规模调整，过小会导致频繁compact影响性能，过大则可能引发OOM。
5.2 网络插件选型对比
kubeasz支持多种CNI插件，这是我们的选型建议：
| 插件 | 适用场景 | 性能损耗 | 功能特性 |
|---|---|---|---|
| Calico | 需要NetworkPolicy | 8-12% | BGP支持、跨子网能力强 |
| Cilium | 安全敏感型应用 | 5-8% | 基于eBPF的可见性和安全 |
| Flannel | 简单场景快速部署 | 15-20% | 配置简单、资源占用低 |
| Kube-OVN | 需要高级网络功能 | 10-15% | 子网划分、QoS支持 |
在最近的一个制造业客户案例中，我们最终选择了Cilium，因为它提供的网络流量可视化功能帮助客户快速定位了多个微服务间的异常调用问题。
6. 常见故障排查指南
6.1 证书过期问题
kubeasz默认生成的证书有效期为10年，但如果遇到证书过期，症状通常表现为：
bash复制kubectl get pods
Unable to connect to the server: x509: certificate has expired or is not yet valid
解决方法：
bash复制# 重新生成证书
ezctl renew my-prod-cluster all
# 分发新证书到所有节点
ezctl setup my-prod-cluster 01
6.2 Pod网络异常排查流程
当遇到Pod间无法通信时，按这个顺序检查：
-
检查Calico（或其他CNI）Pod是否正常运行
bash复制
kubectl -n kube-system get pods -l k8s-app=calico-node -
检查路由表
bash复制
ip route show | grep calico -
检查iptables规则
bash复制
iptables-save | grep -i calico -
最终武器：抓包分析
bash复制
tcpdump -i any -nn -w /tmp/debug.pcap
去年我们遇到一个诡异案例：某个节点的Pod无法访问Service IP。最终发现是该节点的iptables被安全软件清空了。通过ezctl setup my-prod-cluster 06重新配置网络插件后恢复正常。
7. 集群升级实战经验
kubeasz支持无缝升级Kubernetes版本，但需要严格遵守以下步骤：
-
首先升级master节点：
bash复制
ezctl upgrade my-prod-cluster v1.29.0 -r master -
然后逐个升级worker节点（确保业务有冗余）：
bash复制
kubectl drain node-1 --ignore-daemonsets ezctl upgrade my-prod-cluster v1.29.0 -r node -n node-1 kubectl uncordon node-1
关键经验：
- 永远先升级一个非关键worker节点进行验证
- 确保etcd和kube-apiserver版本兼容性
- 大型集群采用滚动升级，每次只升级20%节点
在最近一次从1.26升级到1.28的过程中，我们发现新版kube-proxy的IPVS模式与旧版存在兼容性问题。最终通过在升级前统一配置--ipvs-strict-arp参数解决了问题。这再次证明了灰度升级的重要性。