CentOS 上 Kubernetes 扩展性设计
一 总体架构与扩展思路
- 采用分层扩展：应用层通过副本数与流量治理横向扩展，节点层通过新增 Node纵向扩容，存储与网络通过可插拔插件横向扩展。
- 在 CentOS 上以 kubeadm 搭建高可用集群，按需新增 Worker Node 提升算力；为应用配置 requests/limits 与 HPA，在节点资源不足时联动 Cluster Autoscaler 扩容节点。
- 网络选择 CNI 插件（如 Calico/Flannel），存储对接 CSI 驱动，使网络与存储具备可插拔与横向扩展能力。
二 节点与工作负载扩展
- 节点扩容
- 准备新节点：统一 主机名、/etc/hosts、NTP；在 CentOS 上按需关闭 SELinux、firewalld、禁用 swap，并调优内核网络参数；安装容器运行时与 kubelet/kubeadm。
- 加入集群：在 Master 生成加入命令（如 kubeadm token create --print-join-command），新节点执行 kubeadm join；在 Master 上执行 kubectl get nodes 校验状态为 Ready。
- 工作负载扩展
- 手动扩缩：kubectl scale deployment/ --replicas=。
- 自动扩缩：部署 Metrics Server，创建 HPA（支持 CPU/内存 或自定义指标），示例：
- 命令方式：kubectl autoscale deployment myapp --cpu-percent=80 --min=2 --max=10
- YAML 方式（autoscaling/v2）：设定 scaleTargetRef、minReplicas、maxReplicas 与 metrics（如 resource cpu 的 targetAverageUtilization）。
三 自动扩缩容策略与联动
- 组件分工
- HPA：基于 CPU/内存/自定义指标 调整 Pod 副本数，解决应用层弹性。
- Cluster Autoscaler（CA）：基于 Pending Pods 与节点资源余量调整 Node 数量，解决资源供给。
- 联动设计
- 典型路径：负载上升 → HPA 增加副本 → 资源不足出现 Pending → CA 增加节点 → 新节点就绪后调度成功 → 负载回落 → HPA 缩减副本 → CA 在冷却后回收节点。
- 关键参数：设置合理的 目标利用率、最小/最大副本、扩容/缩容冷却时间，避免抖动与成本浪费。
四 存储与网络的可扩展设计
- 存储扩展
- 通过 CSI（容器存储接口） 接入块/文件存储，第三方驱动可按需横向扩展，不侵入核心代码，适配 CentOS 上多种后端（如 Ceph/NFS/云盘）。
- 网络扩展
- 选择 CNI 插件（如 Calico/Flannel）实现 Pod 网络 与 网络策略，支持大规模节点与命名空间隔离；部署后在新节点上确保 CNI 生效 与跨节点通信正常。
五 容量规划与最佳实践
- 容量与配额
- 为每个命名空间配置 ResourceQuota/LimitRange，为关键应用设置 requests/limits，避免“吵闹邻居”；结合 节点资源预留（kube-reserved/system-reserved）保障稳定性。
- 调度与亲和性
- 使用 污点与容忍、节点亲和/反亲和、拓扑分散 提升高可用与资源利用；对 有状态服务 规划 StatefulSet 与稳定网络标识。
- 伸缩策略
- HPA 目标利用率建议结合 SLO 设定（常见 50%–80% 区间，视应用而定）；为 CA 设置 min/max Nodes 与合理冷却，配合 Pod 中断预算（PDB） 控制滚动升级风险。
- 可观测性
- 部署 Metrics Server、Prometheus/Grafana，监控 节点/Pod 利用率、Pending 数量、伸缩事件，定期回放与调参。
- 升级与变更
- 使用 kubeadm upgrade 进行版本升级，先在测试环境验证；扩展前对应用进行 弹性与容量压测，验证 HPA/CA 策略有效性。
