PaaS容器集群优化之路

1. 性能优化面对的挑战

• 微服务治理框架：为应用提供自动注册、发现、治理、隔离、调用分析等一系列分布式/微服务治理能力，屏蔽分布式系统的复杂度。
• 应用调度与资源管理框架：打通从应用建模、编排部署到资源调度、弹性伸缩、监控自愈的生命周期管理自动化。
• 应用开发流水线框架：打通从编写代码提交到自动编译打包、持续集成、自动部署上线的一系列CI/CD全流程自动化。
• 云中间件服务：应用云化所需的数据库、大数据、通信和应用中间件服务；通过服务集成管控可集成传统非云化的中间件能力。

• 源代码及开发组件多，100+ git repo，整体构建超过1天
• 运行架构复杂，全套安装完需要30+VM，200+进程
• 软件栈深，网络平面复杂
• 集群规模大，5k — 10k节点环境搭建非常困难
• 系统操作会经过分布式的多个组件，无法通过单一组件诊断发现系统瓶颈
• 无法追踪上千个处于不同层次的API的时延和吞吐
• 大部分开发人员专注于功能开发，无法意识到自己的代码可能造成性能问题

2. 优化分析

1. 控制子系统：控制指令的下发和运行(k8s)，例如创建pod
2. 业务流量子系统：容器网络(flannel)、负载均衡(ELB/kube-proxy)
3. 监控子系统：监控告警数据的采集(kafka, Hadoop)

• 应用软件包大小：400M
• 应用模板大小：10M
• 1000个节点，每个节点一个POD，一个实例
• 10种类型的软件包，依赖长度为3，10GB 网络
• 调度及资源管理 3VM

1. 控制子系统： Kubernetes调度速度 > 50 pods/s，仓库支持300并发下载，>40M/s
2. 数据子系统：overlay容器网络TCP收发性能损耗 <5%
3. 监控子系统：在上面这个场景中不涉及，但可以从别的场景大致告警处理能力100条/秒

3. 优化测试 & 工具

• 计数（对应收集器初始化方法NewCounter、NewCounterFunc、NewCounterVec，单一数值，数值一直递增，适合请求数量统计等）
• 测量（对应收集器初始化方法NewGauge、NewGaugeFunc、NewGaugeVec，单一数值，数值增减变动，适合CPU、Mem等的统计）
• 直方图测量（对应收集器初始化方法NewHistogram、NewHistogramVec，比较适合时长等的统计）
• 概要测量（对应收集器初始化方法NewSummary、NewSummaryVec，比较适合请求时延等的统计）

var (
// TODO(a-robinson): Add unit tests for the handling of these metrics once
// the upstream library supports it.
requestCounter = prometheus.NewCounterVec(
    prometheus.CounterOpts{
        Name: "apiserver_request_count",
        Help: "Counter of apiserver requests broken out for each verb, API resource, client, and HTTP response contentType and code.",
    },
    []string{"verb", "resource", "client", "contentType", "code"},
)
requestLatencies = prometheus.NewHistogramVec(
    prometheus.HistogramOpts{
        Name: "apiserver_request_latencies",
        Help: "Response latency distribution in microseconds for each verb, resource and client.",
        // Use buckets ranging from 125 ms to 8 seconds.
        Buckets: prometheus.ExponentialBuckets(125000, 2.0, 7),
    },
    []string{"verb", "resource"},
)
requestLatenciesSummary = prometheus.NewSummaryVec(
    prometheus.SummaryOpts{
        Name: "apiserver_request_latencies_summary",
        Help: "Response latency summary in microseconds for each verb and resource.",
        // Make the sliding window of 1h.
        MaxAge: time.Hour,
    },
    []string{"verb", "resource"},
)
) 

• 在Kubernetes调度过程中，各个状态Pod的数量，看哪一步是最卡的
  
  
• go pprof分析，哪些函数是最耗CPU的

4. 优化开发

5. 优化成果

6. 优化的优化

1. 测试寻找瓶颈点
2. 修改代码突破这个瓶颈点
3. 重新测试验证这段代码是否有效，是否需要改优化思路

• kubemark模拟器 ：社区项目，使用容器模拟虚拟机，在测试中模拟比达到1：20，也就是一台虚拟机可以模拟20台虚拟机对apiserver产生的压力。在测试过程当中，我们使用了500台虚拟机，模拟了10000节点的控制面行为。
• CI集成：提交PR后自动拉性能优化分支并开始快速构建
• CD集成：使用I层的快照机制，快速搭建集群并执行测试案例输出测试报告

在搭建完这套系统后，我们发现这个系统可以从源头上预防降低系统性能的代码合入主线。如果一项特性代码造成了性能下降，在CI的过程当中，功能开发者就能收到性能报告，这样开发者就能自助式的去查找自己代码的性能问题所在，减少性能工程师的介入。

原文发布时间为：2017-05-06

本文作者：难易

本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。

原文标题：PaaS容器集群优化之路