跳至主要內容

容器化推广

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。)