Kubernetes容器编排实战：从架构到优化

1. Kubernetes核心价值与架构解析

当容器数量从最初的几个增长到上百个时，手动管理就变成了运维人员的噩梦。我们团队在2018年就遇到了这样的困境：凌晨三点被报警叫醒处理容器崩溃，手动扩展服务应对流量高峰，发布新版本时战战兢兢...直到我们全面转向Kubernetes。

1.1 为什么Kubernetes成为容器编排的事实标准？

在传统容器管理方式中，我们面临六大核心痛点：

• 故障恢复：容器崩溃后需要人工介入重启
• 弹性伸缩：流量高峰时手动增减容器实例
• 版本更新：必须停服才能部署新版本
• 资源分配：容器间资源争用导致性能不稳定
• 服务发现：需要维护复杂的服务目录和DNS记录
• 存储管理：容器重启后数据丢失是常态

Kubernetes通过声明式API和控制器模式完美解决了这些问题。以我们线上电商平台为例，迁移到K8s后：

• 服务可用性从99.5%提升到99.99%
• 资源利用率提高40%以上
• 新版本发布时间从小时级缩短到分钟级

1.2 Kubernetes架构深度剖析

典型的K8s集群由控制平面(Control Plane)和工作节点(Worker Node)组成：

控制平面组件

• API Server：集群的"前门"，所有操作都通过REST API完成。我们建议生产环境配置至少3个API Server实例实现高可用。
• etcd：分布式键值存储，保存集群所有状态数据。建议使用SSD存储并定期备份，我们曾因etcd故障导致整个集群不可用。
• Controller Manager：运行各种控制器，确保实际状态与期望状态一致。比如Node Controller监控节点状态，Replication Controller维护Pod副本数。
• Scheduler：将Pod分配到合适节点。可以通过自定义调度器实现特殊调度逻辑，比如GPU资源调度。

工作节点组件

• Kubelet：节点上的"管家"，负责与API Server通信并管理容器。我们曾遇到因kubelet内存泄漏导致节点不可用的情况。
• Container Runtime：实际运行容器的引擎，如Docker、containerd等。生产环境推荐使用containerd，更轻量稳定。
• kube-proxy：维护节点网络规则，实现Service的负载均衡。性能敏感场景可以考虑替换为IPVS模式。

生产环境建议：控制平面组件应该部署在独立于工作节点的专用机器上，至少3个实例组成高可用集群。我们使用kubeadm工具初始化集群时，通过--control-plane-endpoint参数指定负载均衡器地址实现API Server高可用。

2. 开发环境搭建实战

2.1 Minikube单节点集群部署

对于本地开发和测试，Minikube是最佳选择。以下是我们团队的标准安装流程：

# macOS安装（需要预先安装Homebrew） brew install minikube docker # 启动集群（建议分配足够资源） minikube start --driver=docker \ --cpus=4 \ --memory=8192 \ --disk-size=50g \ --addons=ingress,metrics-server # 验证安装 minikube status kubectl get nodes # 启用Dashboard（开发环境有用，生产环境不建议） minikube dashboard

关键参数说明：

• --driver：指定底层驱动，docker最通用，也可用virtualbox、hyperkit等
• --cpus/memory：根据机器配置调整，建议至少4核8GB
• --addons：安装常用插件，ingress用于路由，metrics-server用于HPA

常见问题处理：

1. 启动时报错"Unable to start VM"：通常是因为虚拟化未开启，需进BIOS启用VT-x/AMD-v
2. Dashboard无法访问：检查minikube tunnel是否正常运行
3. 拉取镜像失败：配置国内镜像源或使用minikube ssh手动拉取

2.2 kubectl高效使用技巧

kubectl是与K8s交互的瑞士军刀，掌握这些技巧能极大提升效率：

# 1. 自动补全（必须配置） echo 'source <(kubectl completion zsh)' >> ~/.zshrc # 2. 别名设置（长期使用建议配置） alias k=kubectl complete -F __start_kubectl k # 3. 上下文切换（多集群环境必备） kubectl config get-contexts # 查看所有上下文 kubectl config use-context minikube # 切换到minikube # 4. 高效查询技巧 kubectl get pods --sort-by='.status.containerStatuses[0].restartCount' # 按重启次数排序 kubectl get pods --field-selector=status.phase=Running # 只显示运行中Pod kubectl get events --sort-by='.lastTimestamp' # 按时间排序查看事件

生产经验：

• 使用-o wide查看更详细信息，如Pod所在节点
• --watch参数实时观察资源变化，如kubectl get pods -w
• describe命令比get显示更详细的资源状态和事件

3. 工作负载管理实战

3.1 Pod设计模式详解

Pod是K8s最小调度单元，实际应用中我们总结出几种常见模式：

单容器Pod

最简单的形式，90%场景适用：

apiVersion: v1 kind: Pod metadata: name: web-server spec: containers: - name: nginx image: nginx:1.21 ports: - containerPort: 80

边车(Sidecar)模式

主容器+辅助容器组合，我们常用于：

• 日志收集：主容器写日志，边车容器转发到ELK
• 服务网格：主容器处理业务，边车容器处理流量

spec: containers: - name: main-app image: myapp:latest volumeMounts: - name: logs mountPath: /var/log - name: log-agent image: fluentd:latest volumeMounts: - name: logs mountPath: /var/log

初始化容器(Init Container)

在主容器前运行的专用容器，我们用于：

• 数据库迁移
• 配置文件下载
• 依赖服务等待

spec: initContainers: - name: init-db image: busybox command: ['sh', '-c', 'until nslookup mysql; do echo waiting; sleep 2; done'] containers: - name: app image: myapp:latest

3.2 Deployment高级配置

Deployment是最常用的工作负载控制器，这些生产级配置值得关注：

apiVersion: apps/v1 kind: Deployment metadata: name: canary-deploy spec: replicas: 5 strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 # 最大可超出副本数 maxUnavailable: 0 # 更新时允许不可用数 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: affinity: podAntiAffinity: # 反亲和性避免单节点部署多个副本 preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: app operator: In values: - frontend topologyKey: kubernetes.io/hostname containers: - name: web image: nginx:1.21 readinessProbe: # 就绪探针必须配置 httpGet: path: /health port: 80 initialDelaySeconds: 5 periodSeconds: 5 resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi

关键配置说明：

1. maxUnavailable=0确保更新时不中断服务
2. Pod反亲和性避免单点故障
3. 资源限制防止容器占用过多资源
4. 就绪探针确保流量只打到准备好的Pod

4. 服务发现与网络策略

4.1 Service类型选择指南

Kubernetes Service有四种类型，根据使用场景选择：

ClusterIP（默认）

• 特点：集群内部分虚拟IP
• 适用场景：微服务间内部通信
• 示例配置：

apiVersion: v1 kind: Service metadata: name: internal-svc spec: selector: app: backend ports: - name: http port: 80 targetPort: 8080

NodePort

• 特点：通过节点端口暴露服务
• 适用场景：开发测试环境
• 注意：生产环境应配合Ingress使用

spec: type: NodePort ports: - port: 80 targetPort: 8080 nodePort: 30080 # 范围30000-32767

LoadBalancer

• 特点：云厂商提供的负载均衡器
• 适用场景：公有云生产环境
• 注意：会产生云服务费用

spec: type: LoadBalancer ports: - port: 80 targetPort: 8080

ExternalName

• 特点：CNAME别名
• 适用场景：集成外部服务

spec: type: ExternalName externalName: external.mysql.example.com

4.2 Ingress高级路由配置

Ingress是管理外部访问的核心API，这是我们的生产配置：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ecommerce-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: /$1 nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/proxy-body-size: "20m" spec: ingressClassName: nginx tls: - hosts: - shop.example.com secretName: example-tls rules: - host: shop.example.com http: paths: - path: /api/(.*) pathType: Prefix backend: service: name: api-service port: number: 8000 - path: /static/(.*) pathType: Prefix backend: service: name: static-service port: number: 80

性能优化技巧：

1. 启用会话保持提高缓存命中率
2. 调整proxy-body-size适应大文件上传
3. 使用backend-protocol: "HTTPS"实现内部加密
4. 配置rate-limiting防止DDoS攻击

5. 存储与配置管理

5.1 持久化存储方案选型

K8s支持多种存储方案，根据数据特性选择：

存储类型	典型应用场景	性能	持久性	示例
emptyDir	临时缓存	高	低	/tmp
hostPath	单节点数据	高	中	日志收集
NFS	共享访问	中	高	内容管理系统
云存储(AWS EBS)	块存储	高	高	数据库
ConfigMap	配置文件	-	-	nginx.conf

生产环境MySQL StatefulSet示例：

apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: mysql replicas: 3 volumeClaimTemplates: - metadata: name: data spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "gp2" resources: requests: storage: 100Gi template: spec: containers: - name: mysql image: mysql:8.0 volumeMounts: - name: data mountPath: /var/lib/mysql

5.2 ConfigMap热更新策略

ConfigMap更新后如何让Pod感知变化？我们总结三种方案：

1. 滚动更新（推荐）：

kubectl rollout restart deployment/myapp

2. 文件监控重载：

spec: containers: - name: app image: myapp volumeMounts: - name: config mountPath: /etc/config lifecycle: postStart: exec: command: ["/bin/sh", "-c", "touch /etc/config/.reload"]

3. Sidecar通知：

spec: containers: - name: app image: myapp - name: config-watcher image: jimmidyson/configmap-reload args: ["--volume-dir=/etc/config", "--webhook-url=http://localhost:8080/reload"]

经验之谈：对于关键配置，建议采用方案1确保一致性。我们曾因方案3的延迟导致集群配置不一致。

6. 自动扩展与监控

6.1 HPA实战配置

HorizontalPodAutoscaler根据指标自动扩展Pod，这是我们的生产配置：

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: frontend-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: frontend minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: External external: metric: name: requests_per_second selector: matchLabels: app: frontend target: type: AverageValue averageValue: 500 behavior: scaleDown: stabilizationWindowSeconds: 300 policies: - type: Percent value: 10 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 60 policies: - type: Percent value: 100 periodSeconds: 15

关键参数解析：

1. stabilizationWindowSeconds：防止指标抖动导致频繁扩缩
2. scaleDown比scaleUp更保守，避免快速缩容后又需要扩容
3. 可以混合使用资源指标和自定义指标

6.2 监控体系搭建

生产级监控方案建议：

1. 指标收集：

   • Prometheus：采集K8s核心指标和应用指标
   • Node Exporter：节点级监控
   • kube-state-metrics：K8s对象状态监控

2. 可视化：

   • Grafana：仪表盘展示
   • 预置仪表盘ID：315（K8s集群）、6417（节点）

3. 告警：

   • Alertmanager：处理Prometheus告警
   • 关键告警规则：
     • Pod重启频繁（>5次/小时）
     • 节点CPU>80%持续5分钟
     • Pod内存OOM

部署命令：

# 使用Prometheus Operator快速部署 kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests/setup.yaml kubectl apply -f https://raw.githubusercontent.com/prometheus-operator/kube-prometheus/main/manifests/

7. 生产环境最佳实践

7.1 安全加固措施

1. Pod安全策略：

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted spec: privileged: false allowPrivilegeEscalation: false requiredDropCapabilities: - ALL runAsUser: rule: MustRunAsNonRoot seLinux: rule: RunAsAny volumes: - 'configMap' - 'emptyDir'

2. 网络策略（零信任模型）：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all spec: podSelector: {} policyTypes: - Ingress - Egress

3. RBAC最小权限：

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]

7.2 灾备方案设计

1. 集群级备份：

# 使用Velero备份整个集群 velero install \ --provider aws \ --bucket my-backups \ --secret-file ./credentials \ --use-volume-snapshots=false # 定时备份 velero schedule create daily-backup \ --schedule="0 3 * * *" \ --include-namespaces=production

2. 应用级恢复策略：

• 无状态应用：直接重建
• 有状态应用：定期快照+日志同步
• 关键配置：Git版本控制+ConfigMap备份

3. 多集群部署：

• 方案1：主动-备用（冷备）
• 方案2：双活（需要应用支持）
• 方案3：区域划分（如按用户地域路由）

8. 常见故障排查手册

8.1 诊断流程图

Pod异常 → kubectl describe pod → 检查Events → kubectl logs → 查看容器日志 → kubectl exec -it → 进入容器检查 节点异常 → kubectl describe node → 检查Conditions → journalctl -u kubelet → 查看kubelet日志 → free -h / top → 检查资源使用 网络问题 → kubectl run -it --rm debug --image=nicolaka/netshoot → curl -v http://service.namespace.svc.cluster.local → dig service.namespace.svc.cluster.local

8.2 典型问题解决方案

问题1：Pod一直处于Pending状态

• 可能原因：资源不足、节点选择器不匹配、污点限制
• 解决方案：

  kubectl describe pod <name> | grep -A 10 Events kubectl get nodes --show-labels kubectl describe node <node-name> | grep -i taint

问题2：服务无法访问

• 可能原因：Endpoint为空、网络策略阻止、端口不匹配
• 解决方案：

  kubectl get endpoints <service-name> kubectl run -it --rm test --image=busybox --restart=Never -- ping <service-name> kubectl get networkpolicy -A

问题3：镜像拉取失败

• 可能原因：认证错误、镜像不存在、网络问题
• 解决方案：

  kubectl describe pod <name> | grep -i pull minikube ssh docker pull <image> # 测试节点拉取 kubectl create secret docker-registry my-secret \ --docker-server=<registry> \ --docker-username=<user> \ --docker-password=<pass>

9. 性能优化指南

9.1 集群级优化

1. etcd调优：

   • 使用SSD磁盘，单独部署
   • 限制--max-request-bytes和--quota-backend-bytes
   • 定期碎片整理：etcdctl defrag

2. API Server优化：

   • 启用--enable-aggregator-routing
   • 配置--max-requests-inflight和--max-mutating-requests-inflight
   • 使用--target-ram-mb限制缓存大小

3. kubelet配置：

   • 设置--image-gc-high-threshold和--image-gc-low-threshold
   • 调整--kube-api-burst和--kube-api-qps
   • 启用--serialize-image-pulls

9.2 应用级优化

1. 资源请求/限制设置：

   resources: requests: cpu: 100m memory: 128Mi limits: cpu: 500m memory: 512Mi

   • 请求值影响调度，限制值影响运行
   • 建议设置限制值比请求值高20-50%

2. 亲和性配置：

   affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchLabels: app: frontend topologyKey: kubernetes.io/hostname

   • 避免单点故障
   • 提高缓存局部性

3. 镜像优化：

   • 使用多阶段构建减小镜像体积
   • 选择Alpine等轻量基础镜像
   • 合并RUN指令减少层数

10. 工具链推荐

10.1 开发调试工具

1. Lens IDE：功能最全的K8s IDE，支持多集群管理
2. k9s：终端UI工具，快速查看和操作资源
3. Octant：Web版可视化工具，适合初学者
4. Stern：多Pod日志聚合查看

   stern "app.*" --since 10m --tail 100

10.2 CI/CD集成

1. Argo CD：声明式GitOps工具

   kubectl create namespace argocd kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

2. Tekton：云原生CI/CD管道

   kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

3. Flux：持续交付控制器

   flux bootstrap github \ --owner=my-org \ --repository=my-repo \ --path=clusters/production \ --personal

10.3 扩展组件

1. Metrics Server：集群指标采集

   kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

2. Cluster Autoscaler：节点自动扩展

   spec: containers: - name: autoscaler image: k8s.gcr.io/autoscaling/cluster-autoscaler:v1.22.0 command: - ./cluster-autoscaler - --cloud-provider=aws - --nodes=1:10:my-asg-name

3. Keda：基于事件的自动扩展

   kubectl apply -f https://github.com/kedacore/keda/releases/download/v2.6.1/keda-2.6.1.yaml

11. 版本升级策略

11.1 升级路径规划

Kubernetes版本支持策略：

• 每个版本支持约1年
• 最多支持3个次要版本
• 升级路径：v1.21 → v1.22 → v1.23

我们的升级检查清单：

1. 查看 发布说明 了解重大变更
2. 使用kubectl-convert检查API兼容性
3. 在测试环境验证工作负载
4. 备份etcd和关键资源
5. 先升级控制平面，再升级工作节点

11.2 使用kubeadm升级

控制平面升级步骤：

# 1. 升级kubeadm yum update -y kubeadm-1.22.0 # 2. 检查升级计划 kubeadm upgrade plan # 3. 升级控制平面 kubeadm upgrade apply v1.22.0 # 4. 升级kubelet和kubectl yum update -y kubelet-1.22.0 kubectl-1.22.0 systemctl restart kubelet

工作节点升级步骤（逐节点进行）：

# 1. 驱逐Pod kubectl drain <node> --ignore-daemonsets # 2. 升级kubeadm和kubelet yum update -y kubeadm-1.22.0 kubelet-1.22.0 # 3. 升级节点配置 kubeadm upgrade node # 4. 重启kubelet systemctl restart kubelet # 5. 取消隔离 kubectl uncordon <node>

12. 多集群管理方案

12.1 使用kubefed实现联邦集群

1. 安装kubefedctl：

wget https://github.com/kubernetes-sigs/kubefed/releases/download/v0.8.1/kubefedctl-0.8.1-linux-amd64.tgz tar -zxvf kubefedctl-0.8.1-linux-amd64.tgz mv kubefedctl /usr/local/bin/

2. 初始化控制平面：

kubefedctl join cluster1 \ --host-cluster-context=cluster1 \ --v=2 \ --kubefed-namespace=kube-federation-system

3. 部署跨集群应用：

apiVersion: types.kubefed.io/v1beta1 kind: FederatedDeployment metadata: name: frontend namespace: default spec: placement: clusters: - name: cluster1 - name: cluster2 template: spec: replicas: 3 selector: matchLabels: app: frontend template: metadata: labels: app: frontend spec: containers: - name: nginx image: nginx:1.21

12.2 集群网络互联方案

1. 方案对比：

方案	原理	复杂度	适用场景
Service Mesh	Sidecar代理	高	微服务架构
VPN隧道	加密隧道连接	中	混合云
云厂商对等连接	云服务商专线	低	同云多区域
Submariner	直接路由+加密	中	多集群服务发现

2. Submariner部署示例：

# 安装CLI工具 curl -Ls https://get.submariner.io | bash # 部署broker（在其中一个集群） subctl deploy-broker --kubeconfig cluster1.yaml # 加入集群 subctl join --kubeconfig cluster1.yaml broker-info.subm --clusterid cluster1 subctl join --kubeconfig cluster2.yaml broker-info.subm --clusterid cluster2 # 验证连接 subctl show all --kubeconfig cluster1.yaml

13. 成本优化实践

13.1 资源利用率提升

1. 使用Vertical Pod Autoscaler：

apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: frontend-vpa spec: targetRef: apiVersion: "apps/v1" kind: Deployment name: frontend updatePolicy: updateMode: "Auto" resourcePolicy: containerPolicies: - containerName: "*" minAllowed: cpu: 100m memory: 128Mi maxAllowed: cpu: 2 memory: 4Gi

2. 节点资源回收：

• 设置Pod优先级和抢占
• 配置Pod QoS等级（Guaranteed > Burstable > BestEffort）
• 使用kube-reserved和system-reserved保留系统资源

13.2 集群规模优化

1. 使用节点池：

• 按工作负载类型划分：CPU优化型、内存优化型、GPU节点
• 自动伸缩不活跃节点池

2. Spot实例策略：

apiVersion: apps/v1 kind: Deployment metadata: name: worker spec: replicas: 10 template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: lifecycle operator: In values: - spot tolerations: - key: "spot" operator: "Exists" effect: "NoSchedule"

3. HPA与Cluster Autoscaler联动：

• HPA调整Pod数量
• 当Pending Pod出现时，Cluster Autoscaler扩容节点
• 节点利用率低于阈值时自动缩容

14. 新兴技术集成

14.1 服务网格(Service Mesh)

1. Istio核心功能：

• 流量管理（金丝雀发布、A/B测试）
• 安全（mTLS、RBAC）
• 可观测性（指标、日志、追踪）

2. 安装精简版：

istioctl install --set profile=demo -y kubectl label namespace default istio-injection=enabled

3. 金丝雀发布示例：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: frontend spec: hosts: - frontend.example.com http: - route: - destination: host: frontend subset: v1 weight: 90 - destination: host: frontend subset: v2 weight: 10

14.2 无服务器(Serverless)

1. Knative Serving：

kubectl apply -f https://github.com/knative/serving/releases/download/v0.26.0/serving-crds.yaml kubectl apply -f https://github.com/knative/serving/releases/download/v0.26.0/serving-core.yaml

2. 部署无服务器应用：

apiVersion: serving.knative.dev/v1 kind: Service metadata: name: hello spec: template: spec: containers: - image: gcr.io/knative-samples/helloworld-go env: - name: TARGET value: "World"

3. 自动伸缩特性：

• 支持缩容到零
• 基于请求的自动扩展(KPA)
• 并发数和请求超时配置

15. 团队协作规范

15.1 开发流程标准化

1. 环境隔离策略：

• 命名空间按功能划分：dev、staging、production
• 资源配额限制：

  apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota spec: hard: pods: "20" requests.cpu: "10" requests.memory: 20Gi

2. GitOps工作流：

• 代码仓库结构：

  clusters/ production/ frontend/ deployment.yaml backend/ deployment.yaml staging/

• Argo CD同步策略：

  apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: production spec: destination: namespace: production server: https://kubernetes.default.svc source: path: clusters/production repoURL: [e-mail]:my-org/infrastructure.git targetRevision: HEAD syncPolicy: automated: prune: true selfHeal: true

15.2 知识共享机制

1. 标准化文档：

• 架构决策记录(ADR)
• Runbook（应急手册）
• 故障复盘报告

2. 工具支持：

• 使用Kubernetes注解记录运维信息：

  metadata: annotations: owner: [e-mail] runbook: https://wiki.example.com/runbook/frontend sla: "99.9"

• 通过CRD扩展团队规范：

  apiVersion: team.example.com/v1 kind: Application metadata: name: frontend spec: owners: - email: [e-mail] slack: "@team-a" dependencies: - name: redis version: "6.2" monitoring: dashboard: "https://grafana.example.com/d/frontend"

16. 性能基准测试

16.1 测试工具与方法

1. 集群基准测试工具：

• kubemark：模拟大规模集群
• clusterloader2：K8s官方负载测试工具
• Locust：HTTP负载测试

2. 测试场景设计：

apiVersion: batch/v1 kind: Job metadata: name: load-test spec: completions: 10 parallelism: 5 template: spec: containers: - name: locust image: locustio/locust args: ["-f", "test.py", "--host", "http://frontend"] volumeMounts: - name: test-script mountPath: /home/locust volumes: - name: test-script configMap: name: load-test-script restartPolicy: Never

3. 关键指标采集：

• API Server延迟：apiserver_request_duration_seconds
• etcd写入延迟：etcd_disk_wal_fsync_duration_seconds
• 调度器性能：scheduler_scheduling_duration_seconds

16.2 优化效果对比

我们生产集群优化前后的关键指标对比：

指标	优化前	优化后	提升幅度
API Server P99延迟	850ms	120ms	85%
Pod启动时间(50节点)	8.2s	3.5s	57%
最大并发部署数	200 Pods/s