KubernetesSRE
场景
您的Kubernetes集群在业务高峰期频繁出现Pod调度失败,而在低峰期大量资源闲置导致巨额云账单。您需要实现自动扩展以匹配负载,同时控制成本。
症状
- Pod处于Pending状态,因节点资源不足
- 集群节点利用率低于30%持续数小时
- 云账单月环比增长超过20%且无对应业务增长
诊断
- 检查集群资源:
kubectl top nodes和kubectl top pods - 查看Pod事件:
kubectl describe pod <pod-name>寻找Insufficient memory/cpu - 分析成本:在AWS Cost Explorer中按服务(EC2、EKS)和标签筛选,识别空闲资源
- 检查HPA状态:
kubectl get hpa观察目标指标与实际值
命令
配置HPA(水平Pod自动扩展)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
应用:kubectl apply -f hpa.yaml
配置Cluster Autoscaler(节点自动扩展)
假设已有Cluster Autoscaler部署,设置最小/最大节点数:
apiVersion: v1
kind: ConfigMap
metadata:
name: cluster-autoscaler-status
namespace: kube-system
data:
config: |
{
"minNodes": 3,
"maxNodes": 20
}
或通过AWS CLI更新Auto Scaling Group:
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --min-size 3 --max-size 20
成本标签与报告
# 为节点组添加成本标签
kubectl label nodes --all cost-center=production
# 在AWS Cost Explorer中按标签分组
风险控制
- 设置HPA冷却时间以避免波动:
--horizontal-pod-autoscaler-downscale-stabilization-window=5m - 为Cluster Autoscaler设置扩容延迟:
--scale-down-delay-after-add=10m - 使用Pod Disruption Budgets保证关键服务可用性
- 测试环境先行验证
回滚
- 删除HPA:
kubectl delete hpa my-app-hpa - 恢复Deployment副本数:
kubectl scale deployment my-app --replicas=3 - 重置Cluster Autoscaler配置:恢复原Auto Scaling Group最小值
- 如需彻底禁用:
kubectl scale deployment cluster-autoscaler --replicas=0 -n kube-system
验证
- 检查Pod调度:
kubectl get pods -o wide确认所有Pod运行 - 监控资源利用率:
kubectl top nodes节点利用率在40-80% - 成本对比:对比优化前后两周AWS账单,确认节省至少15%
- 自动化测试:使用
kubectl run -it --rm load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://my-app-service; done"触发扩展观察
何时提交OpsGlobal工单
- 自动扩展未按预期触发,且日志显示指标服务器异常
- Cluster Autoscaler频繁扩容缩容导致稳定性问题
- 需要跨区域多集群成本优化咨询
- 出现因扩展策略错误导致的服务中断
适用场景
适合正在处理 Cloud Migration、Kubernetes, SRE 相关问题的团队,用于快速建立排查路径和交付标准。
问题背景
本文深入探讨云容量自动扩展与成本优化,涵盖场景、症状、诊断、命令、风险控制、回滚、验证及何时提交OpsGlobal工单。
排查步骤
先确认影响范围和最近变更,再收集日志、配置、指标和链路数据,最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名,并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径,避免扩大故障影响。
回滚方案
保留原配置和发布版本;如修复后指标异常,立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题?
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题,可以提交日志和配置文件,我们帮你远程诊断。