什么是 CPU Share?
CPU Share 是容器调度时进行 CPU 资源分配的一种方式，相对于集团之前使用的 CPU Set 而言。CPU Set 模式下会为一个 4C 的容器分配固定的“独占的” 4 个 CPU 核，容器中所有进程/任务只能跑在这 4 个核上（因此算力上限就这 4 核），同时其它容器中的进程/任务不能使用这 4 个核。
而 CPU Share 模式下一台 96 核的宿主机上一个 4C 容器绑定的 CPU 核数可能在 4 ~ 96 之间，取决这台宿主机上的资源分配情况及其它容器是否 CPU Share。目前一台宿主机上的所有 Share 容器都绑定相同的一批 CPU 核，容器中的进程/任务可以跑在所有这些核上，每个容器可使用的 CPU 资源通过与容器规格相对应的权重来分配。
为什么要做 CPU Share
优势：
- CPU 资源的分配可以更加精细化，原来 Set 模式下 CPU 资源的最小分配粒度是 1 核，而 Share 模式下可以做到 1/1000 核；
- 宿主机上所有 Share 容器共享 CPU 核，每个容器不用的 CPU 资源可以被其它容器/任务使用，有利于资源利用率提升；
- 可以更好的满足业务实时资源弹性需求，并且可能允许容器在短时间内使用超过容器规格的 CPU 资源来应对瞬间突发峰值；
需要注意：
- 因为 CPU Share 的资源共享特性，当宿主机整机 CPU 压力比较高时，请求达到时可能需要内核调度时间，可能对长尾延迟有影响。
- CPU Share是不会导致ip发生变化。
由于 CPU Share 在资源利用率和弹性资源调度上的优势，后续在非重点应用上大规模推进应用 Share 化应该是业界主流趋势。除极个别延迟特别敏感业务（Latency sensitive critical）外，绝大多数的在线延迟敏感通用业务（Latency sensitive general）都将切换为 Share 模式。
如何查看应用的进程/线程数
绝大多数在线应用的启动脚本中通过读取容器内可见的 CPU 核数( grep -c ‘cpu[0-9][0-9]*’ /proc/stat )来设置应用进程/线程数等，尤其是 Java 应用的 ParallelGCThreads 参数设置。由于 Share 容器绑定的 CPU 核可能远大于容器规格，因此需要读取容器内的 SIGMA_MAX_PROCESSORS_LIMIT 来作为相关设置的依据。
什么是 VPA
VPA(Vertical Pod Autoscaler，垂直弹性伸缩) 相对于 HPA(Horizontal Pod Autoscaler，水平弹性伸缩) 而言，HPA 通过增减应用的运行容器实例来提升资源利用率/应对峰值，而 VPA 则是通过增减单个容器实例所分得的资源(CPU/MEM)多少来提升资源利用率/应对峰值。由于 CPU Share 具备的共享和弹性特性，VPA 在 CPU Share 模式下更易实施且更安全。
VPA 根据应用资源画像调整容器 CPU 规格，同时保持 CPU 最大可用上限不变来弹性使用资源，容器将根据调整后规格进行计费，从而节省业务资源成本（后续随着应用水位的变化，也会自动往上调节，以寻找到最适合应用的资源配置）。当前阶段由于可用资源上限不变，并且平台设置了安全水位策略，风险较低，如有异常可在平台上执行一键回滚。
为什么要做 VPA
HPA 扩缩容器的方式链路较长，涉及应用启停、中间件等运维配置的变动等，对线上的影响比较大，但是在资源节省上也更彻底。另外，由于业务容灾部署的需要，应用保有最小容器数量有一定限制，可能远超应用真实的资源需求。
VPA可以对应用容器进行原地秒级资源伸缩，链路短，风险更低，业务基本无感，从而更好的做到资源利用率的提升。CPU Share 容器资源分配由 request 和 limit 两个值决定，request 是强保障的资源，limit 是最大可用到的资源上限，默认情况下 容器规格 == request == limit，VPA 通过资源画像得到应用推荐的 request 值，同时保持 limit 不变，因此 CPU Share 模式的 VPA 风险较低。
不过这里要注意！应用升配（比如 2c->3c）在当前宿主机剩余资源不足时会发生驱逐，驱逐会导致更换宿主机，进而更换ip和重启应用。
