云原生内容分享(五)：云原生落地最佳实践

目录

1. 上价值

2. 搭建底层环境

3. 业务推广

4. 风险控制和可靠性保障

5.核心能力全景图

6. 对比 KVM 的 FAQ

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

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

7.云原生实践总结 

企业落地云原生的目的

实践中使用到的 CNCF Landscape 项目

实践中遇到的问题&故障

---

1. 上价值

从虚拟机到 Kubernetes 转变的收益

1. 更高效的利用系统资源：虚拟化本身大概占用10%的宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。

2. 保证环境的一致性：环境不一致问题是容器镜像出现之前业界的通用问题，不利于业务的快速上线和稳定性。

3. 加快资源交付和扩缩容：虚拟机创建流程冗长，各种初始化和配置资源准备耗时长且容易出错，而容器秒级启动，声明式的配置，降低出错概率，并内置智能负载均衡器。

4. 强大的故障发现和自我修复能力：支持端口检查、url检查、脚本检查等多种健康检测方式，支持使用启动探针、就绪探针、存活探针，在应用出现问题时自动下线并重启。

5. 支持弹性伸缩：可根据容器的内存、CPU使用率，调用QPS等，进行自动的扩缩容。

2. 搭建底层环境

从稳定性、高可用性、可观测性、高性能和可运维性角度出发搭建底层环境

说明：已 Centos 操作系统的物理机为例

• 安装前准备

  • 常规操作：禁 swap、防火墙、SELINUX，更换 yum 源，安装依赖包，配置时间同步

  • 性能优化：内核升级（建议把rpm放到公司内部私有仓库），调节 CPU 性能模式，内核参数优化，性能压测（后面文章会详解系统压测方法）

  • 自动化 check：检查 hostname 是否符合 DNS 规范，检查 Service & Pod CIDR 是否与当前网段冲突，检查时间同步，检查外网连通性等

• 组件安装

  • Etcd ：建议外置，单独安装，5节点集群；参数优化，开启自动压缩，调整 raft 消息最大字节数，调整 etcd 最大容量；性能压测（使用benchmark & FIO 压测，后续详解）

  • Master 三大件：Apiserver、Controller Manager、Scheduler 5节点，参数优化，调整 apiserver 的流控 qps；性能压测（使用 kubemark + Clusterloader2 压测，后续详解）

  • Node 节点：kubelet，kube-proxy，CRI，CNI，CSI

  • 插件：kube-vip（保证 Apiserver的高可用性），nodelocaldns + coredns，Ingress （修改内核参数，提高并发能力）

• 可观测

  • 指标类：kube-prometheus + 开发 exporter --> 汇聚到 VictoriaMetrics

  • 日志类：ELK/Fluentd/Clickhouse

  • 事件类：kube-eventer

  • 链路类：OpenTelemetry

  • 可观测性大盘：Grafana（图表绘制）

• 安装后可用性验证测试

  • 集群状态检查、节点状态检查、部署 Pod 测试、服务访问测试、删除重启节点测试、拔测等

• DevOps

  • 运维平台支持：Deployment/Argo Rollout/Service/Ingress 对象的生命周期管理（申请、展示、扩缩容、销毁）

  • 发布平台支持：CI 支持编译推送镜像，Java/Nodejs/Go/Python Yaml文件模版；CD 支持滚动发布，灰度发布，启动日志查看，回滚

  • 堡垒机：支持容器登录，文件上传下载

3. 业务推广

策略：

a. 请喝奶茶

b. 先搞出个试点，最佳实践，然后 点--> 线 --> 面 推广

c. 上下齐力：从上到下，从下到上，一同发力

d. 风险控制：测试没问题，再上线，环境依次是，work --> test --> ut --> prod 灰度 --> prod 全量；做好回滚虚拟机的应急方案

e. 请喝奶茶

4. 风险控制和可靠性保障

根据上图具体要做的事情分为以下几个方面（具体方案后续文章会详解）

• 故障演练

  • Apiserver 高可用故障演练

  • Etcd 高可用故障演练

• 混沌工程

  • Pod 级别故障注入

    • OS层：Cpu、Mem（内存）、File（文件）、Disk（磁盘）、Process（进程）、Network（网络）

    • JVM 虚拟机：CodeCacheFilling 字节码填充、delay 延时、throwDeclaredException、threadfull、OutOfMemoryError、full-gc

  • Node 级别故障注入

    • OS层：同上

• 预案建设：

  • Etcd 备份恢复

  • Velero 备份恢复

  • Master 节点紧急扩容

  • Etcd 节点紧急扩容

  • 多集群故障迁移

• 性能评估

  • 物理机性能压测

  • Master 组件性能压测

  • Etcd 性能压测

  • 应用性能压测

• 容量评估

  • 建立集群资源池、和资源预留，用于应急

  • Node 资源预留 防止雪崩

  • Pod Limit Request 限制，CPU/MEM/磁盘大小

  • Pod Qos、优先级 按服务等级划分

  • HPA

• 安全评估

  • 开启 Apiserver 审计日志

  • 使用 RBAC 最新权限原则授权

  • 配置 PodDisruptionBudget （PDB）保护策略

  • API 通信使用强加密算法

  • 污点、亲和性隔离

• 自动化巡检

  • 核心指标主动巡检

• 监控告警

  • 新增 Node Problem Detector(NPD) 监控

  • 新增 tcp-exporter

  • 补全、优化监控告警项

  • 定义 Pod Tag中包涵 Appid 字段，使用 kube-state-metrics 将 Tag 暴露出去进行关联查询报警

• CD

  • 灰度发布

  • 回滚

5.核心能力全景图

云原生是一个快速发展的领域，我们应该积极关注社区动态，进行版本迭代和新工具的引入，提高稳定性，效益最大化。

6. 对比 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），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 同时存在的情况

解决方案

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

7.云原生实践总结 

企业落地云原生的目的

一句话概括：在保证稳定性的前提下，降本增效

目标拆解：

• 保障稳定性

  • 建设高可用性：基础组件（Master三大件/Etcd等）高可用、多机房、多集群、Pod 高可用

  • 持续进行风险治理：耦合度、故障发现、容量、容灾、变更及可运维性、安全性

  • 建设可观测性：Metrics、Logging、Tracing、Events、Chaos、Dashboard、Inspection

  • 故障演练：Apiserver 高可用故障演练、Etcd 高可用故障演练、双机房切换故障演练

  • 预案建设：Etcd 备份恢复、Velero 备份恢复、Master 节点紧急扩容、Etcd 节点紧急扩容、多集群故障迁移

  • 性能/容量评估：物理机性能压测、Master 组件性能压测、Etcd 性能压测、应用性能压测

• 节约成本

  • 推进无状态应用容器化

  • 推进无状态应用接入弹性伸缩

  • K8s 调度能力增强：预选、优选、重调度（使资源分配均匀、提高装箱率、提高资源使用率）

  • 持续进行应用容量治理：横向缩容（降副本数）、纵向缩容（降规格 CPU/MEM）

  • 建立资源画像：调度和容量治理依赖资源画像

• 提高效率（平台能力建设）

  • 自动化运维平台（面向开发）：容器生命周期管理、Ingress 生命周期管理、HPA 生命周期管理、扩缩容&升降配、容器资源预留、Java Dump & GCLog、屏蔽/恢复告警

  • 发布系统（面向开发）：Java/Nodejs/静态资源模版、自定义镜像、自定义模版、滚动发布、灰度发布、启动日志查看

  • 堡垒机（面向开发）：Web 终端、文件管理、日志审计

  • SRE 平台（面向运维）：集群安装、集群扩缩容、集群升级、插件安装、Ingress 节点扩缩容、Web Kubectl、集群自动化巡检、多集群迁移

总结为下图，拿走不谢

sre-k8s (2)

实践中使用到的 CNCF Landscape 项目

 

按用途和熟悉度分类：

	深度使用	轻度使用或测试环境试用	准备使用
调度与编排	Kubernetes、KEDA		Karmada、Volcano
协调与服务发现	etcd、CoreDNS
应用程序定义与镜像构建		Helm、KubeVirt、Operator Framework
持续集成与交付	Argo		OpenKruise
Service Mesh		Istio
云原生网络	Calico	Cilium
云原生存储		Rook、Longhorn
可观测性	Prometheus、VictoriaMetrics、Fluentd、Grafana、Chaosblade		OpenTelemetry
容器运行时	Docker	containerd
镜像仓库	JFrog Artifactory	Harbor	Dragonfly

实践中遇到的问题&故障

问题 ：

• 如何提高资源可见性？容器内 top free 命令看到的是宿主机资源使用情况

• 应用从 KVM 迁移到 容器 后，资源利用率为何发生变化？有增高的，有降低的

• 流量洪峰时，个别应用为啥容器比虚拟RT长？

• 新增 Ingress 后导致 RedirectUri 不一致？

• 自动注入service变量导致 Nodejs 负载变高？

• grpc 应用负载均衡问题，使用 service 和 Ingress 无效？

• 接入容器后，域名访问异常？

故障：

• Calico 异常重启？

• kubelet pleg ？

• Node 被清空？

• 什么？相同型号物理机 容器性能不如虚拟机？