跳至主要內容

容器化推广

Clay云原生Kubernetes大约 7 分钟

容器化推广

方法论

一立二扩三优化四架构后五治理

完整落地整体规划

从虚拟机到Kubernetes转变的收益

主要收益如下：

  1. 更高效的利用系统资源：虚拟化本身大概占用10%的宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。
  2. 保证环境的一致性：环境不一致问题是容器镜像出现之前业界的通用问题，不利于业务的快速上线和稳定性。
  3. 加快资源交付和扩缩容：虚拟机创建流程冗长，各种初始化和配置资源准备耗时长且容易出错，而容器秒级启动，声明式的配置，降低出错概率，并内置智能负载均衡器。
  4. 强大的故障发现和自我修复能力：支持端口检查、url检查、脚本检查等多种健康检测方式，支持使用启动探针、就绪探针、存活探针，在应用出现问题时自动下线并重启。
  5. 支持弹性伸缩：可根据容器的内存、CPU使用率，调用QPS等，进行自动的扩缩容。

风险控制和可靠性保障

在整个风险管控链路中，我们分为指标、告警、工具、机制&措施和人员5个层面：

  1. 指标数据采集，从节点、集群、组件以及资源层面采集核心指标作为数据源。
  2. 风险推送，覆盖核心指标的多级、多维度的告警机制。
  3. 在工具支持上，通过主动、被动以及流程化等减少误操作风险。
  4. 机制保障上，打通测试、灰度验证、发布确认以及演练等降低疏忽大意的情况。
  5. 人是风险的根本，建立值班机制，确保问题的响应。

img

从故障预防、发现、恢复多个角度，保障可用性目标达成

可观测建设

  • 构建高可用的云原生监控系统
    • Prometheus 多副本
    • 使用 victoriametrics 进行持久化存储 和 统一查询入口
  • 多维度收集监控指标 metric/log/event/trace
  • 逐步演进到一体化监控方案（与公司现有监控体系融合）
  • 持久完善优化监控/告警项，系统性能

自动化建设

白屏化/容器平台建设

容器管理平台 (3)

阶段性能力矩阵规划

对比 KVM 的 FAQ

1）应用从 KVM 迁移到 容器 后，资源利用率为何发生变化？

  • 容器化后，CPU、MEM 使用率降低： 容器是一种轻量级的资源隔离技术，与传统的虚拟机相比，容器使用更少的资源。每个容器共享宿主机的操作系统内核，而不像虚拟机那样需要独立的操作系统和内核。这减少了操作系统内核的开销，使得容器能够更高效地利用CPU和内存资源。 虚拟机除了操作系统内核的开销外，还有各种 agent 的开销，zabbix-agent、filebeat-agent、hids-agent 等

  • 可用内存减少： 虚拟机 和 容器的计算方式不同，虚拟机中可用内存取值为：free 中的 available 字段，数据来源于/proc/meminfo，计算较为复杂，可简单理解为

    available = free_pages - total_reserved + pagecache + SReclaimable = free_pages - Σ(min((max(lowmem) + high_watermark), managed)) + （pagecache - min(pagecache / 2, wmark_low)）+ （SReclaimable - min(SReclaimable/2, wmark_low)）

    在容器中，没有类似虚拟机中 free 命令中 available 字段的直接计算方式，容器的内存管理方式与虚拟机有所不同，容器通常直接共享宿主机的内存资源，并且容器内的内存使用情况是由容器运行时管理的，而不是像虚拟机那样拥有自己的操作系统和内核。 容器的内存使用情况，可以参考内存使用率指标，数据来源于/sys/fs/cgroup/memory/kubepods/xxx/xxx，当使用率达到100%时，会发生OOM

2) 流量洪峰时，容器比虚拟RT长

RT 变长的原因是：容器发生 CPU 节流现象

什么是 CPU 节流？

CPU节流是一种资源调度的现象，当一个进程或任务需要的CPU资源超过了其分配的CPU配额时，操作系统或虚拟化管理程序会限制其对CPU的使用，从而导致其性能下降。这种限制是为了平衡系统中各个进程或任务之间的资源使用，防止某个进程过度使用CPU而影响其他进程的正常运行。

在Linux系统中，CPU节流通常是由CFS（Completely Fair Scheduler，完全公平调度器）实现的。CFS是Linux内核默认的调度器，用于公平地分配CPU时间片给各个运行中的进程和线程。当某个进程或任务的CPU使用超过了其分配的CPU配额时，CFS会根据其CPU Shares和CPU Quota等参数来限制其对CPU的使用，从而实现CPU节流。

容器和虚拟机在资源管理有一些区别

在 Kubernetes 中使用的是 cgroups 来管理资源分配与隔离，调度程序则选取了完全公平调度（CFS）中的强制上限（Ceiling Enforcement）open in new window，CFS会根据每个容器的CPU配置（如CPU Shares、CPU Periods和CPU Quota）来进行CPU时间片的分配和调度。容器之间共享宿主机的CPU核心。

虚拟机是完全隔离的虚拟化技术，每个虚拟机运行在自己的虚拟操作系统中，有自己独立的CPU调度器和资源管理。虚拟机的CPU资源由Hypervisor管理，每个虚拟机获得分配的CPU核心，资源隔离较为明确，不容易相互影响。

什么情况下会发生 CPU 节流？

  1. Pod 使用的 CPU 超过了 limit，会直接被限流。
  2. 容器内同时在 running 状态的进程/线程数太多，内核 CFS 调度周期内无法保证容器所在 cgroup 内所有进程都分到足够的时间片运行，部分进程会被限流。
  3. 内核态 CPU 占用过高也可能会影响到用户态任务执行，触发 cgroup 的 CPU throttle，有些内核态的任务是不可中断的，比如大量创建销毁进程，回收内存等任务，部分核陷入内核态过久，当切回用户态时发现该 CFS 调度周期时间所剩无几，部分进程也无法分到足够时间片从而被限流。

流量洪峰，属于 1 和 2 同时存在的情况

解决方案

已知情况，容器在大部分情况下，RT 要比虚拟机短

  1. 业务侧改造（建议）： 提前压测容器能承载的最大 QPS（RT较低的情况），根据 QPS 设置合理 HPA（自动弹性伸缩）规则，当容器平均 QPS，到达 阈值时，自动进行 扩容，使得容器 QPS 始终保持在阈值以下 提前压测容器能承载的最大 QPS（RT较低的情况），评估业务QPS可能达到的最大峰值，根据最大峰值计算确定容器的 Max数量，基于 HPA 定时任务规则，在业务活动时，自动提前扩容到Max 值
  2. 平台侧调研改造 目前已知的业界使用的方案： 使用 cpusets 进行应用CPU绑核，缺点：资源利用率较低 根据历史节流数据，推测出合理的 CPU limit 值，让开发改为推荐配置 升级内核到 5.14 以上，支持CPU Burst技术（调研中，在传统的 CPU Bandwidth Controller quota 和 period 基础上引入 burst 的概念。当容器的 CPU 使用低于 quota 时，可用于突发的 burst 资源累积下来；当容器的 CPU 使用超过 quota，允许使用累积的 burst 资源。最终达到的效果是将容器更长时间的平均 CPU 消耗限制在 quota 范围内，允许短时间内的 CPU 使用超过其 quota。）