K8S
1、项目总览
1.1、最终架构方案
1.2、IP分配规划
1.3、域名规划
1.4、CPU优化指南
1.5、云C部署指南
1.6、部署检查清单
1.7、快速参考手册
2.1、API-VIP高可用配置
2.2、Calico网络配置
2.3、存储方案配置
2.4、Ingress入口配置
2.5、安全加固配置
2.6、etcd优化配置
2.7、灾难恢复配置
2.8、公司网络配置
K8s部署
本文档使用 MrDoc 发布
-
+
首页
1.4、CPU优化指南
# CPU资源优化配置方案 **KtCloudGroup标准配置:平衡方案(2.375:1超配)** ✅ ## 🎯 KtCloudGroup标准方案 ### 架构配置 ``` ┌───────────────────────────────────────────────────────────────┐ │ 云A服务器 (128GB) │ │ AMD Ryzen 7700: 8C16T │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Master-1 │ │ Worker-A-1 │ │ Worker-A-2 │ │ │ │ 6C 16G │ │ 16C 52G │ │ 16C 52G │ │ │ │ etcd-1 │ │ 生产主力 │ │ 生产备用 │ │ │ │ 系统盘100G │ │ Longhorn │ │ Longhorn │ │ │ │ │ │ 数据盘900G │ │ 数据盘900G │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ 虚拟CPU: 38C | 内存: 120G | 超配: 38/16 = 2.375:1 ✅ │ │ 公网IP: 185.150.190.216 + 172.93.107.95-104(10个) │ └───────────────────────────────────────────────────────────────┘ │ 0.5ms │ 超低延迟 │ ┌───────────────────────────────────────────────────────────────┐ │ 云B服务器 (128GB) │ │ AMD Ryzen 7700: 8C16T │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Master-2 │ │ Worker-B-1 │ │ Worker-B-2 │ │ │ │ 6C 16G │ │ 16C 52G │ │ 16C 52G │ │ │ │ etcd-2 │ │ 灰度主力 │ │ 灰度备用 │ │ │ │ 系统盘100G │ │ Longhorn │ │ Longhorn │ │ │ │ │ │ 数据盘900G │ │ 数据盘900G │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ 虚拟CPU: 38C | 内存: 120G | 超配: 38/16 = 2.375:1 ✅ │ │ 公网IP: 104.194.9.56 + 172.93.107.136-145(10个) │ └───────────────────────────────────────────────────────────────┘ │ 0.5ms │ 超低延迟 │ ┌───────────────────────────────────────────────────────────────┐ │ 云C服务器 (128GB) │ │ AMD Ryzen 7700: 8C16T │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Master-3 │ │ Worker-C-1 │ │ Worker-C-2 │ │ │ │ 6C 16G │ │ 16C 52G │ │ 16C 52G │ │ │ │ etcd-3 │ │ 测试环境 │ │ 应急/扩展 │ │ │ │ 系统盘100G │ │ Longhorn │ │ Longhorn │ │ │ │ │ │ 数据盘900G │ │ 数据盘900G │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ 虚拟CPU: 38C | 内存: 120G | 超配: 38/16 = 2.375:1 ✅ │ │ 公网IP: 199.127.62.90 + 9个附加IP │ └───────────────────────────────────────────────────────────────┘ │ 180ms │ 高延迟(WireGuard) │ ┌───────────────────────────────────────────────────────────────┐ │ 公司服务器 (128GB,边缘节点) │ │ 延迟到云端: 180ms │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ Worker-Edge │ │ Storage-Backup │ │ │ │ 24C 64G │ │ 12C 56G │ │ │ │ 开发环境 │ │ MinIO 3TB │ │ │ │ Harbor/Gitea │ │ 备份存储 │ │ │ │ 边缘服务 │ │ 监控/日志归档 │ │ │ └──────────────────┘ └──────────────────┘ │ │ 内网IP: 172.16.100.0/21(K8s专用) + VPN网关: 10.255.0.100 │ └───────────────────────────────────────────────────────────────┘ ``` ### 关键指标 | 指标 | **平衡方案(2.375:1)**<br>✅ KtCloudGroup标准 | 保守方案(1.875:1)<br>备选方案 | |------|------------------|----------------| | **Master CPU** | **6C × 3 = 18C** ✅ | 6C × 3 = 18C | | **Worker CPU** | **32C × 3 = 96C** ✅ | 24C × 3 = 72C | | **云端总虚拟CPU** | **114C** ✅ | 90C | | **超配比例** | **2.375:1** ✅ | 1.875:1 | | **内存利用率** | **93.7%** ✅ | 87.5% | | **etcd稳定性** | **高** ✅ | 极高 | | **生产适用性** | **✅ 常规生产环境推荐** | 金融级(资源利用率较低) | | **可支撑Pod** | **~700** ✅ | ~500 | | **可支撑QPS** | **40000+** ✅ | 30000+ | --- ## 📐 详细配置(KtCloudGroup标准) ### 1. Master节点配置 ✅ ```yaml # Master-1/2/3 配置 VM规格: CPU: 6核 ✅ 内存: 16GB 系统盘: 100GB SSD 网络: WireGuard VPN (10.255.0.101-103) 设计考虑: - Master节点主要负载是API Server和etcd - etcd在0.5ms延迟下运行稳定 - 6核足够支撑1000+节点的集群 - 平衡控制面和数据面的算力分配 kubelet配置: --kube-reserved=cpu=500m,memory=1Gi,ephemeral-storage=1Gi --system-reserved=cpu=500m,memory=1Gi,ephemeral-storage=1Gi --eviction-hard=memory.available<1Gi,nodefs.available<10% ``` ### 2. Worker节点配置 ✅ ```yaml # Worker-A-1/A-2, Worker-B-1/B-2, Worker-C-1/C-2 配置 VM规格: CPU: 16核 ✅ 内存: 52GB 系统盘: 100GB SSD 数据盘: 900GB(Longhorn) 网络: WireGuard VPN (10.255.0.111-116) 资源预留: 系统预留: 1核 + 4GB kubelet预留: 1核 + 2GB 可分配: 14核 + 46GB 实际物理算力: 16核虚拟 / 2.375超配 ≈ 6.7核物理算力 性能特点: ✅ CPU竞争在合理范围 ✅ 支持稳定的生产负载 ✅ Pod调度精准可控 节点标签: topology.kubernetes.io/zone: cloud-a/b/c node.kubernetes.io/instance-type: worker-standard workload-type: production kubelet配置: --cpu-manager-policy=static # 关键Pod独占核心 --topology-manager-policy=best-effort --kube-reserved=cpu=1000m,memory=2Gi --system-reserved=cpu=1000m,memory=4Gi --max-pods=110 # 每个Worker最多110个Pod ``` ### 3. 公司边缘节点配置 ```yaml # Worker-Edge (公司) - 保持原配置 VM规格: CPU: 24核(增加,因为有足够物理资源) 内存: 64GB 系统盘: 100GB SSD 数据盘: 1.5TB 网络: 172.16.100.10/21 用途: - 开发环境(低优先级) - Harbor镜像本地缓存 - CI/CD测试 - 非关键业务 污点: location=on-prem:NoSchedule latency=high:PreferNoSchedule ``` --- ## 🔧 PVE虚拟机配置 ### CPU类型选择 ```bash # 云A/B/C PVE配置(推荐) CPU类型: host(透传物理CPU特性) CPU单元: 1024(默认权重) CPU限制: 不限制(让内核调度) # 高级选项 NUMA: 启用(提升大内存性能) CPU标志: +aes,+avx2(加密和向量计算加速) # 如果出现CPU窃取严重: CPU单元调整: Master: 2048(2倍权重,优先级高) Worker-1: 1024(标准权重) Worker-2: 1024(标准权重) ``` ### 内存配置 ```bash # Master节点 内存: 16GB 最小内存: 16GB(禁用气球驱动) Ballooning: 关闭(生产环境) # Worker节点 内存: 52GB 最小内存: 52GB Ballooning: 关闭 # 原因:K8s需要稳定的内存,不能被宿主机回收 ``` --- ## 🎯 K8s资源配额配置 ### 1. 命名空间资源限制 ```yaml # 生产命名空间 apiVersion: v1 kind: ResourceQuota metadata: name: prod-quota namespace: production spec: hard: requests.cpu: "40" # 最多请求40核 requests.memory: "180Gi" # 最多请求180G内存 limits.cpu: "80" # 最多限制80核(允许突发) limits.memory: "200Gi" pods: "400" # 最多400个Pod --- # 灰度命名空间 apiVersion: v1 kind: ResourceQuota metadata: name: gray-quota namespace: staging spec: hard: requests.cpu: "30" requests.memory: "120Gi" limits.cpu: "60" limits.memory: "150Gi" pods: "300" --- # 开发命名空间 apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: development spec: hard: requests.cpu: "20" requests.memory: "80Gi" limits.cpu: "40" limits.memory: "100Gi" pods: "200" ``` ### 2. LimitRange(强制每个Pod设置限制) ```yaml apiVersion: v1 kind: LimitRange metadata: name: default-limits namespace: production spec: limits: # Container级别 - type: Container default: cpu: "500m" # 默认limit memory: "512Mi" defaultRequest: cpu: "100m" # 默认request memory: "128Mi" max: cpu: "4" # 单容器最大4核 memory: "8Gi" min: cpu: "50m" memory: "64Mi" # Pod级别 - type: Pod max: cpu: "8" # 单Pod最大8核 memory: "16Gi" ``` ### 3. PodDisruptionBudget(保证可用性) ```yaml # 关键服务PDB apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: critical-service-pdb namespace: production spec: minAvailable: 2 # 至少保持2个副本运行 selector: matchLabels: app: critical-service tier: production ``` --- ## 📊 监控和告警 ### 1. CPU窃取时间监控 ```yaml # Prometheus告警规则 groups: - name: cpu-steal rules: - alert: HighCPUStealTime expr: rate(node_cpu_seconds_total{mode="steal"}[5m]) > 0.1 for: 5m labels: severity: warning annotations: summary: "节点 {{ $labels.instance }} CPU窃取时间过高" description: "CPU窃取时间 {{ $value | humanizePercentage }},可能虚拟化超配过高" - alert: CriticalCPUStealTime expr: rate(node_cpu_seconds_total{mode="steal"}[5m]) > 0.2 for: 2m labels: severity: critical annotations: summary: "节点 {{ $labels.instance }} CPU严重竞争" description: "CPU窃取时间 {{ $value | humanizePercentage }},需要立即调整配置" ``` ### 2. 节点压力监控 ```yaml - alert: NodeCPUPressure expr: | (1 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)) > 0.85 for: 10m labels: severity: warning annotations: summary: "节点 {{ $labels.instance }} CPU使用率持续过高" - alert: PodCPUThrottling expr: | sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod, namespace) > 0.1 for: 5m labels: severity: warning annotations: summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} CPU被限流" ``` --- ## 🚀 迁移步骤 ### 阶段1:测试环境验证(云C) ```bash # 1. 先在云C调整配置 # 停止云C所有VM qm stop 301 302 303 # 2. 修改CPU配置 qm set 301 -cores 6 # Master-3 qm set 302 -cores 16 # Worker-C-1 qm set 303 -cores 16 # Worker-C-2 # 3. 启动VM qm start 301 302 303 # 4. 验证K8s节点 kubectl get nodes kubectl top nodes # 5. 运行压力测试 kubectl run stress-test --image=polinux/stress --rm -it -- \ stress --cpu 4 --timeout 60s # 6. 监控CPU窃取时间 watch -n 1 'cat /proc/stat | grep "^cpu "' ``` ### 阶段2:灰度环境迁移(云B) ```bash # 1. 排空节点 kubectl drain k8s-worker-b-1 --ignore-daemonsets --delete-emptydir-data kubectl drain k8s-worker-b-2 --ignore-daemonsets --delete-emptydir-data # 2. 停止VM并调整 qm stop 201 202 203 qm set 201 -cores 6 qm set 202 -cores 16 qm set 203 -cores 16 qm start 201 202 203 # 3. 恢复节点 kubectl uncordon k8s-worker-b-1 kubectl uncordon k8s-worker-b-2 # 4. 验证业务 kubectl get pods -n staging -o wide ``` ### 阶段3:生产环境迁移(云A) ```bash # 滚动迁移,确保高可用 # 1. 先迁移Worker-A-2(备用节点) kubectl drain k8s-worker-a-2 --ignore-daemonsets qm stop 103 qm set 103 -cores 16 qm start 103 kubectl uncordon k8s-worker-a-2 # 2. 等待Pod重新调度完成 kubectl get pods --all-namespaces | grep -i pending # 3. 迁移Worker-A-1(主力节点) kubectl drain k8s-worker-a-1 --ignore-daemonsets qm stop 102 qm set 102 -cores 16 qm start 102 kubectl uncordon k8s-worker-a-1 # 4. 最后迁移Master-1(需要谨慎) # 确保etcd集群健康 kubectl exec -it -n kube-system etcd-k8s-master-1 -- etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ endpoint health qm stop 101 qm set 101 -cores 6 qm start 101 # 5. 验证etcd kubectl get cs ``` --- ## 📋 验证清单 ### 性能验证 ```bash # 1. CPU窃取时间检查 for node in k8s-master-1 k8s-worker-a-1 k8s-worker-a-2; do echo "=== $node ===" ssh $node "grep 'steal' /proc/stat" done # 2. etcd性能测试 kubectl exec -it -n kube-system etcd-k8s-master-1 -- sh -c ' ETCDCTL_API=3 etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/server.crt \ --key=/etc/kubernetes/pki/etcd/server.key \ check perf ' # 3. API Server延迟测试 kubectl get --raw /metrics | grep apiserver_request_duration_seconds # 4. 节点资源实际使用 kubectl top nodes kubectl describe node k8s-worker-a-1 | grep -A 10 "Allocated resources" ``` ### 稳定性验证 ```bash # 1. 运行7天压力测试 kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: stress-test namespace: default spec: containers: - name: stress image: polinux/stress command: ["stress"] args: ["--cpu", "2", "--timeout", "604800s"] # 7天 resources: requests: cpu: "2" memory: "1Gi" limits: cpu: "2" memory: "1Gi" EOF # 2. 监控CPU窃取率 # 正常: < 5% # 警告: 5-10% # 严重: > 10% ``` --- ## 🎯 总结 ### KtCloudGroup性能指标 ✅ | 指标 | **平衡方案(2.375:1)**<br>✅ KtCloudGroup标准 | |------|--------| | **超配比例** | **2.375:1** ✅ | | **CPU窃取率(预期)** | **3-5%** ✅ | | **etcd P99延迟** | **1-3ms** ✅ | | **API响应时间** | **15-25ms** ✅ | | **资源可预测性** | **高** ✅ | | **生产稳定性** | **低风险** ✅ | | **可支撑Pod** | **~700** ✅ | | **可支撑QPS** | **40000+** ✅ | ### 方案适用场景 | 业务场景 | 推荐方案 | 说明 | |---------|---------|------| | **电商、SaaS等常规业务** | **平衡方案(2.375:1)** ✅ | **KtCloudGroup标准配置** | | **金融、支付等关键业务** | 保守方案(1.875:1) | 极致稳定,CPU资源更充足 | --- **版本:v1.0** **更新时间:2025-01-22** **适用场景:基于AMD Ryzen 7700(8C16T)的K8s集群CPU优化**
arise
2025年11月22日 09:49
转发文档
收藏文档
‹‹
‹
5
/ 17
›
››
手机扫码
复制链接
手机扫一扫转发分享
复制链接
Markdown文件
PDF文档(打印)
分享
链接
类型
密码
更新密码