Community Progress k8s

1. 技术沙龙稿
Kubernetes 社区动态报告

3. CNCF Landscape

4. 项目分级
• Sandbox（沙箱）
• 主动申请，遵从 CNCF 行为准则和 IP 策略
• Incubating（孵化）
• 至少三个用户在生产环境中使用，质量和作用域达标
• 贡献者数量正常，贡献的提交与合并持续
• 未来愿景清晰，存在安全问题反馈流程
• 对于规范，至少有一个公开的参考实现
• Graduated（毕业）
• 稳定并在生产环境中成功应用
• 至少两个组织在贡献，达到并维护核心架构实践要求
• 完成独立或第三方安全审计且公开结果
• 明确定义项目治理和贡献流程
• 主仓库公开项目采纳者名单
• TOC 大多数成员投票同意毕业（大多数预期在两年内毕业）

6. 项目 状态 星数 类型 说明
CoreDNS 毕业
已毕业项目

7. CNCF技术图谱
• 服务管理
• 服务网格 Linkerd 和 Istio
• 中间件层
• 远程调用 gRPC、消息队列 NATS、消息分发 CloudEvents
• 数据层
• 对象文件存储 Rook、关系数据库 Vitess（基于开源 MySQL ） 、KV 数据库 TiKV
• 容器
• Containerd、容器网络接口 CNI、容器网络发现 CoreDNS ，容器网络Cilium
• 容器管理
• 容器编排Kubernetes、镜像仓库Harbor、镜像分发 DragonFly、 日志管理 Prometheus、安
全监控 Falco、kubearmor 等

8. 云原生带来的价值
• 使用容器替换现有人工智能、大数据的基础平台，通过容器更小粒度的资源划分、
更快的扩容速度、更灵活的任务调度，以及天然的计算与存储分离架构等特点，
助力人工智能、大数据在业务性能大幅 提升的同时，更好地控制成本。
• 华为云的 AI 容器、大数据容器，AWS 的深度学习容器等
• 云原生技术与边缘计算相结合，可以比较好的解决传统方案中轻量化、异构设备
管理、海量应用运维管理的难题
• AWS 的 GreenGrass、阿里云的 ACK@Edge ，华为云智能边缘平台 IEF等
• 云原生与高性能计算相结合
• 华为云的 云原生高性能计算解决方案、AWS 推出了可运行在容器平台的 Batch 服务

10. 阶段一：服务器
• 碎片化物理设备管理
• 软件与硬件割裂
• 以“设备”为中心
阶段一：云化
• 统一运化资源池
• 软件迁移上云
• 以“资源”为中心
阶段一：云原生化
• 统一云原生基础设施
• 软件云原生架构
• 以“应用”为中心
微服
务应
用
软件系统
硬件系统
软件系统
统一云资源管理
云原生平台
运营支
撑系统
数据库
CRM/E
RP
核心业
务系统
…
企业服
务总线
企业中间件平台
交换机 路由器
物理
机
物理
机
SAN
设备
NFS
设备
RAI
D阵
列
计算池化 网络池化 存储池化
块存储
文件存储
对象存储
VPC
ELB
虚拟机
虚拟机
虚拟机
运营
支撑
系统
CR
M/E
RP
云化
运维
系统
敏捷
开发
系统
核心
业务
系统
新型
业务
系统
…
云化数据库
轻量级服务
框架
云化中间件
平台
中间
件应
用
AI/大
数据
应用
边缘
/IoT
应用
…
云原生应用使能中心
多云/混合云/边云架构
云原生基础设施：以“应用”为中心
应用定义
算力
应用定义
网络
应用定义
存储
转变一：资源自动化
转变二：应用自动化
企业数字化转型的三个阶段

11. 计算 存储 网络
公有云 混合云 边缘云
基
础
设
施
容器（k8s） 多云管理 云边协同 批量调度 服务网格
云容器产品 镜像仓库 智能边缘平台 多云容器管理 云原生服务中心 云容器安全
全场景微服务
微服务应用管理｜服务网格｜分布式事务
云原生DevOps
Devops开发平台
融合集成
应用集成/设备接入
云中间件
分布式缓存｜分布式消息｜API网关｜
函数服务
云原生一站式AI开发平台
预制模型算法｜行业预制模型算法
全生命周期知识解决方案
知识获取｜建模｜管理｜应用
数据治理
ETL工具｜方法论
数据库
存算分离｜分布式｜多
模计算
企业安全治理体系
全生命周期数据保护｜安全专家团队
全流程DevSecOps
IDE集成安全插件｜安全门禁｜漏洞分析
安全级合规能力
合规认证｜平台及云服务内置合规能力
安全技术和产品
租户安全服务｜线上线下安全管理能力
数据湖
融合分析｜垮域协
同｜协同计算
云
原
生
应
用
赋
能
资源高效
应用敏捷 业务智能 安全可信
安
全
体
系
+
运
营
体
系
企业云原生架构

13. • 最新的 CNCF 调查报告
• 5.6M 开发人员以某种方式使用 Kubernetes（总数约 26.8M）

14. • Serverless 的发展趋势
• 过去几年其实没有变化（见右图）
• O’Reilly 分析发现，Serverless
内容的关注度下降了41%
来源：https://www.infoq.com/articles/k8s-cncf-survey-chasm

15. • Serverless 框架
• OpenWhisk/Knative
• Kubeless
• OpenFaaS
• Virtual Kubelet
这个数据不宜过度解读：
2021年的调查中，151 人回答
了这个问题，剩下的 1376 人
没有回答。

16. Docker 移除
• 移除原因
• 影响
• CNCF 报告 containerd 运行时的部署每年增长 500%【1】
• 镜像构建：Docker、Buildah、Buildkit、umoci、Kaniko
• 命令行工具：crictl、
• 运行时：containerd、cri-o、
【1】https://containerjournal.com/features/cncf-rise-in-emerging-open-source-tech-on-k8s/

17. Kubernetes 部署与使用
• 调查【1】发现，96% 的受访 IT 专业人员在使用或评估 Kubernetes，其中 79%
在使用托管形态的 Kubernetes 服务（EKS: 39%、AKS: 23%、AKE：17%）.
• Envoy 代理部署数量年增长 39%
• Fluentd 数据采集部署量年增长 53%
• Prometheus 监控部署量年增长 43%
• Serverless 部署量维持在 39% 不变；使用 Serverless 的用户中，74% 使用 AWS Lambda，
39% 使用 Azure Functions。
• 75% 受访者通过托管服务使用上述组件，年增长 24%
• 生产环境中管理 K8s 集群的主要挑战
• （1）技术复杂性、（2）安全性、（3）应对集群泛滥
• k8s 技术的采纳者中，77% 反映上线时间在 6 个月左右【2】，平均 4.5 个月。
• 43% 的组织中，Kubernetes 上运行最多的是数据分析和机器学习任务【2】
• 2021年其他常见负载为应用构建、Windows容器、分布式数据服务
【1】https://containerjournal.com/features/cncf-rise-in-emerging-open-source-tech-on-k8s/
【2】D2IQ, Kubernetes in the Enterprise Annual Report

18. • 运行数据分析或机器学习的组织中
• 41%的组织使用自己的本地、云或混合环境
• 35%使用来自大云的服务
• 35%使用类似Tableau或Cloudera这类工具
• 35%使用SaaS服务
• 34%使用一组工具，33%使用Kubernetes
• 81% 的组织在实现基于 Kubernetes 的边缘或IoT项目
• 其中61% 运行在生产环境中
• Kubernetes 边缘部署从 2020 年的 16% 上升到 2021 年的 23%
• 企业采用 Kubernetes 的目的
• 改进运维（35%）
• 实现敏捷（35%）
• 驱动新业务（34%）
• 提升客户体验（33%）
• 降低 IT 开销（32%）

19. • 企业 Kubernetes 部署形式
• 购买云端 SaaS 服务（44%）
• 使用 K8s 管理平台（37%）
• 使用公有云（37%）
• 在 Kubernetes 集群上部署应用的方式
• 打包部署（36%）
• 采用传统的 DevOps 工具部署（30%）
• 自动化部署（19%） -- 2020 年此项排第一
• 采用 Kubernetes 技术的 挑战
• 缺少 IT 资源（36%）
• 无法有效伸缩（34%）
• 较难跟上下层技术的快速演化（33%）

20. • 生产环境部署 Kubernetes 负载的挑战
• 安全性（30%）
• 生产环境的可靠性（30%）
• 故障排查（29%）
• Kubernetes 的复杂度不可低估
• 2020年，38% 的开发、架构人员感到心力交瘁，2021年，这一百分比为 23%
• 2020年，51% 的开发、架构人员希望换工作，2021年，这一百分比为22%
• 42% 的受访者反馈 Kubernetes 插件机制过于复杂
• 23% 认为外部插件很难集成；18% 在开发自用插件上投入巨大
• 在 Kubernetes 集群上部署 AI、ML 负载时，最大的挑战
• IT 资源（37%）
• 将数据模型从数据科学家的 notebook 迁移到生产环境（33%）
• 有效地 scale up（32%）

21. Kubernetes 社区提升对安全的重视
• SIG Security（2021年才开始正式启动运作）
• Issue #1: Create a periodically auto-refreshing list of fixed CVEs
• 定义Prow任务将CVE 的JSON数据整合，以Feed方式发布
• Issue #3: Artifact Vulnerability Scanning and Triage Policy
• 目标：自动扫描 Kubernetes 制品中的脆弱性，对识别的脆弱性进行私下分类，为下游提供
可使用的报告
• 内容：
• 使用snyk扫描脆弱性；发送邮件报告
• 基于SPDX为发行版构建过程增加生成 SBOM 能力
• 驱动端到端的脆弱性发现、分类、报告与解决

22. 供应链安全
• OpenSSF（Open Source Security Foundation）启动 Alpha-Omega 项目提升开
源软件的安全性，启动资金 $5M 来自微软和Google。

23. Future of Kubernetes
• VM metaphor
• 容器：冻结、封装应用依赖项，构造“随处可运行”的应用发行包
• K8s：运行时特征 -- 多副本、自动重启、自动扩缩、资源用量声明与控制等
• 未来如何？
• 开发者不再关心 K8s，应用服务的构造与运维将使用新的抽象
• Secret 的设计是有问题的且并不安全，基于 Secret 的密码、秘钥、证书都只能证明对方是
否知道某机密信息，并不能真的用来验证对方身份。建议使用OIDC机制，用 id-token 来验
证身份和鉴权。
• Ingress 用来将 HTTP 请求路由到负载资源，但这个设计本身缺陷很多，能力太简单。社区
正在构想 Ingress V2 API，让 Ingress 真正能够承担网关的责任。
• NetworkPolicy：需要 CNI 支持，并且一般仅基于 IP 地址判断，类似于防火墙的机制，过于
死板。服务网格有的能够拓展 OIDC 来执行 mTLS 认证。很多 Helm Chart 将 Ingress 封装
起来一起部署，将来迁移也会是个麻烦。应用层的路由还没有共识。
• 服务网格在跨集群、跨云的时候也有局限。

24. • 未来如何？（续）
• K8s 应用的核心是 Deployment 资源，有时候会用 HPA 来实现按需扩缩容。
• HPA 的触发阈值一般为 CPU 利用率 70%，这就意味着设计上包含了 30% 的资源浪费。
• 之所以这么保守是因为从到达阈值到扩缩操作被触发并完成，一般需要几分钟。
• KEDA 可以改进这种扩缩能力，甚至可用于 FaaS，因而被视为 HPA v3。
• Knative 使用 Pod Sidecar 来监视事件速率，进而完成快速缩放；Knative 内置蓝绿部署和金丝雀
部署模式支持；这些实践使得用户更为聚焦 Knative 服务本身，不再关心 Deployment
• 其他针对场景的平台还有：用于AI 的 Kubeflow、用于 DevOps 的 kpack、Tekton、Cartographer
• K8s 的将来在于 CRD 及基于 CRD 所构建的抽象

25. Kubernetes 的下一步

27. CNCF 基础组件项目
项目 状态 星数 类型 说明
Kubernetes 毕业
etcd 毕业
containerd 毕业
helm 毕业
harbor 毕业
cri-o 孵化
dragonfly 孵化
grpc 孵化
？

29. CNCF 网络项目
项目 状态 星数 类型 说明
Cilium 孵化 11.7K 网络插件 基于eBPF的网络连接、安全和可观测性软件，支持L3/4、L7网络与安全。
CNI 孵化 4.1K 网络插件 Linux 容器的云原生网络接口，包括规范和 Go 库。
Antrea 沙箱 1.3K 网络插件 基于 OVS 的 k8s 网络插件，支持复杂策略，支持Windows节点。
Kube-OVN 沙箱 1.2K 网络插件 将基于 OVN 的网络虚拟化与 Kubernetes 集成，支持多集群、网络策略等。
CNI-Genie 沙箱 0.5K 网络插件 在部署时允许选择 Calico、Flannel、Romana 等网络，支持多种插件。
Submariner 沙箱 1.8K 网络插件 用于连接多个 k8s 集群的覆盖网络，与多种 CNI 网络驱动兼容。
BFE 沙箱 5.4K 负载均衡 百度开源的 7 层负载均衡器。
OpenELB 沙箱 1.0K 负载均衡 裸机、边缘和虚拟化环境下提供 LoadBalancer 类型的 k8s 服务。
K8GB 沙箱 0.4K 负载均衡 基于 CRD 的云原生负载均衡组件。
Emissary Ingress 孵化 3.7K Ingress 开源的 API 网关，基于 Envoy 代理实现。
Contour 孵化 3.1K Ingress 基于 Envoy 代理的 Ingress 控制器。
毕业

30. CNCF 服务网格项目
项目 状态 星数 类型 说明
Istio ？ 30.2K 服务网格 为服务提供连接、保护、控制和观测能力。
envoy 毕业 19.5K 服务代理 边缘、中间层、服务代理，由 lyft 开源。
Linkerd 毕业 8.4K 服务网格 轻量级、安全的服务网格，linkderd 2.x 是新版本。
Meshery 沙箱 1.3K 服务网格 为k8s、服务网格和负载提供生命周期、配置与性能管理能力。
Kuma 沙箱 2.7K 服务网格 跨可用区的服务网格，支持容器与虚拟机，基于 Envoy 构建。
Open Service
Mesh
沙箱 2.4K 服务网格 轻量级、可扩展、云原生服务网格，综合了其他服务网格的能力。
Service Mesh
Interface
沙箱 0.9K 服务网格 服务网格接口，定义公共标准。
Network
Service Mesh
沙箱 0.5K 服务网格 用于多云和混合云的服务网格，项目已基本停止维护。
SMP 沙箱 0.1K 服务网格 服务网格性能，对服务网格价值进行标准化。

31. 现代应用：
• 应用系统已经逐渐转向基于微服务架构的开发体系
• 微服务架构的应用系统是由多个小的独立的服务组成，通过轻量通信协议如 HTTP、gRPC、Kafka 等进行通
信
• 微服务架构下的服务天然具有动态变化的特点，结合容器化部署，时常会引起大规模的容器实例启动或重启。
对传统网络的挑战：
• 传统的 Linux 网络访问安全控制机制（如 iptables）是基于静态环境的 IP 地址和端口配置网络转发、过滤等
规则，但是 IP 地址在微服务架构下是不断变化的，非固定的。
• 出于安全目的，协议端口(例如 HTTP 传输的 TCP 端口 80)也不再固定用来区分应用系统。
• 为了匹配大规模容器实例快速变化的生命周期，传统网络技术需要维护成千上万的负载均衡规则和访问控制
规则，并且需要频率更新这些规则
• 没有可视化能力，要维护这些规则也是十分困难
• 容器的创建和销毁非常频繁，基于 IP 做身份关联的故障排除和安全审计等也很难实现
对传统网络的的可用性和性能都是极大的挑战
云原生下传统网络的挑战

32. • 不支持网络策略的overylay插件：flannel
• 支持网络策略插件：calico weave contiv
canal
• 支持多网卡：multas
基于ebpf的具备安全和可观测的cilium
云原生网络发展

33. 功能特性
• 取代kube-proxy
• 支持多集群互通
• 支持API级别网络策略，分布式防火墙
• 支持流量可视
• 支持网络加密
2019年初大约2000个star，到2021年的上万star，基于eBPF的cilium基本可以认为是目前社区的技术趋势
Cilium 发展现状

34. • 网络跟服务网格融合
• 目前 Cilium 新版本已经开始尝试使用
eBPF+onenodeproxy 的方式实现服务网格
• 原因
• Istio 的 Sidecar 模式太重，占用资源太多，规模越大问
题越严重
• Sidecar 的模式复杂度高，问题排查困难
• 社区开始对 SideCar的模式进行争论
• 服务治理本身属于网络的范畴
• Cilium 的 L7 策略本身通过 Envoy 实现，再支持 Mesh
属于水到渠成的
• eBPF 本身可以对 ServiceMesh 的一些缺陷进行补充
技术判断：Envoy 作为 L7 代理在无法被取代，服务治理融入到
SDN 里面方向是正确的，未来的云原生网络必将同时具备网络+
安全+治理的能力
Cilium下一步发展

36. 项目 状态 星数 类型 说明
Rook 毕业 9.8K 块、对象、文件 支持Ceph和NFS的存储Operator
TiKV 毕业 11K KV数据库 PingCAP开源，支持事务
Longhorn 孵化 3.7K 块 Rancher开源，增量式快照与备份，跨集群灾备
CubeFS 沙箱 2.6K 文件、对象 JD.com 开源
K8up 沙箱 0.3K 备份 为PV卷提供备份，后端使用 S3 兼容存储
OpenEBS 沙箱 7.4K 容器存储（块、文件）
由MayaData开源，支持ZFS、LVM、Mayastor、cStor、Jiva、
Longhorn等
Piraeus 沙箱 03K 块，文件
LINBIT开源，管理LINSTOR集群，支持RAID、SAN、NAS或EBS，
支持多云。
Vitess 毕业 13.9K 数据库 针对 MySQL 的数据库集群系统
SCHEMAHERO 沙箱 0.6K 数据库 声明式的数据库 Schema 迁移方案
ORAS 沙箱 0.6K 镜像库 OCI 镜像库服务
Vineyard 沙箱 0.6K 数据库 内存数据管理器，零拷贝，只读，主要针对大数据和及其学习场景
CNCF 云原生存储、数据库项目

37. • 云原生架构下，大部分业务系统不会处理数据存储的逻辑，通常将数据存储和处理能力交给数据库来完成。
• 数据库云原生化，数据库实例运行在容器中，具备了快速部署，快速扩容的能力
• 云原生数据库采用存算分离的架构，存储能力交给更专业的存储系统完成，数据库只专注在数据库的业务逻辑
处理
云原生时代的有状态应用，大部分指的就是“云原生数据库”
交易型数据库（OLTP） 分析型数据库（OLAP）
业务特点：
• 常见的 OLTP 数据库有 MySQL，PostgreSQL 等，通常承载
的都是核心交易类业务，对存储系统的数据可靠性、性
能要求极高。
• 交易类业务本身对延迟非常敏感，存储系统的带宽越高、
延迟越低，OLTP 能提供的 TPS 越高。
• 每一套业务系统通常都会有 N 套独立的 OLTP 数据库作为
业务支撑。由于业务系统会频繁的进行部署以及扩容，
所以支撑 OLTP 的存储系统必须具备很高的敏捷性，可以
快速提供数据库对存储空间的需求，同时也要方便的进
行扩容等操作。
• 大部分 OLTP 数据库采用块存储系统作为数据存储系统，
因为块存储通常可以提供最佳的性能。
业务特点：
• OLAP 数据库主要用在数据分析场景，对存储系统的可靠性
以及延迟的要求都不像 OLTP 数据库那么高，但数据量大对
存储成本敏感。
• 为了支撑 OLAP 对存储成本的要求，存储系统通常采用 EC
技术，以降低数据存储的成本。文件接口难以支撑百亿级
别的文件数量，所以 OLAP 使用的存储系统一般采用S3存储
• OLAP 系统对敏捷性没有特殊的需求，一旦部署好后，最常
见的运维操作是扩容，并不会对数据库频繁的进行重新部
署和销毁操作。
云原生有状态应用对存储系统的要求

38. 业务侧：
• 随着云技术的成熟，越来越多的企业面临多云的需求：部分对数据安全
不敏感且具有大量网络流量的业务需要使用公有云服务，而对数据安全
性和服务稳定性要求较高的业务需要使用私有云服务。
• 公有云和私有云在产品设计理念上完全不同，产品的使用方式、运维方
式、服务质量、产品参数也完全不同。
• 不同的服务提供商之间也存在着巨大差异。多云的环境，对企业的运维
团队提出了巨大的挑战。
• 业务侧使用了云原生架构，但对于基础架构软件，目前还是由不同的云
厂商来提供，基础架构的运维人员需要为不同服务商提供的存储系统，
准备不同的运维方式，这极大的增加了运维人员的负担。
云原生存储系统特点：
• 原生存储系统可以良好的运行在各种不同服务商提供的公有云环境或私有云
环境，并且为运维人员提供相同接口和运维方式。云原生存储系统可以极大
的降低运维团队的负担。
• 提供了容器化部署、自动运维、声明式接口等特征，让用户可以采用和运维
其他云原生应用一样的方式对存储系统进行部署、运维和管理。
• 云原生存储还需要能够很好地和其他云原生基础设施配合，例如云原生数据
库，使得云原生数据库可以真正的在公有云和私有云都能够得到一致的用户
体验。
要求：
• 避免环境依赖
• 避免资源消耗过高
• 声明式运维方式
• 云原生生态
云原生存储不是存储的容器
化
云原生存储与云存储的关系：
• 云原生存储 本质相当于云存储UI，面向应用的申明式应
用层存储
• 分层存储，重用基础设施红利，不重新发明轮子，针对
新的负载类型部分存储形态上移
• 在控制平面实现效率，自治方面能力，最大化存储稳定
和安全
云原生存储的几个要素：
• 容量Size
• 性能IOPS, 吞吐，时延
• 可访问性，共享／独享
• IO可观测性
• QoS
• 多租户隔离
云原生存储的产生

39. 两种思路
• 设计微服务组件把已有的分布式存储系统包装管理起来，使原来的分布式存储可以适配运
行在 Kubernetes 平台上，实现通过 Kubernetes 管理原有的分布式存储系统
• 重新针对云原生平台设计一个分布式存储，这个分布式存储系统组件是微服务化的，能够
复用 Kubernetes的 调度、故障恢复和编排等能力
开源的云原生产品

40. • 目前计算和网络都是以微服务的形式通过 k8s 统一编排管理的，即k8s既是计算和网络的消费者，
同时也是计算和网络的编排者和管理者。
• 存储则不一样，虽然k8s已经设计了PV/PVC机制来管理外部存储，但只是弄了一个标准接口集成，
存储本身还是通过独立的存储系统来管理，k8s 根本不知道底层存储是如何编排和调度的。
• CAS比较适合的场景：
• 工作负载需要本地存储
• 团队希望能够有效地将本地存储（包括磁盘或云卷）
转换为 k8s 工作负载所需的卷
• 性能是一个问题
• 架构的松耦合需要在存储层维护
• 希望保持小团队自治
• CAS只适合运行在k8s上的应用，目前业界
大部分还是为了使用localpv而已，这就要求
应用要自己维护数据高可用，其在架构上涉及
的是控制面的架构
存储也由kubernetes编排
https://www.cncf.io/blog/2020/09/22/container-attached-storage-is-cloud-native-storage-cas/
Container Attached Storage，容器存储的未来？

41. • 未来如何？（继续）
• 存储：不再使用持久卷
• PV 持久卷的大多数用途是缓存瞬态数据
• PV 卷的主要问题是将应用的关注点和存储关注点耦合，按 12-factors 方法学，支撑服务都应该是
通过网络挂接的。
• 在 PV 的设计思路下，用户需要使用 POSIX 文件系统接口来操作数据，访问控制也是基于 POSIX
模型，这些都不是为云而生的，因易用性不强，通常 PV 卷挂载后都是允许容器访问所有数据！
• 即便开发的是 Stateful 应用，也要使用 Stateless 服务，并且尽可能使用数据库或对象存储，将存
储管理交给基础设施维护人员
• 独立的对象存储可以使用访问令牌来单独完成认证与鉴权
• 在 Serverless 计算模式下，传统的磁盘存储越发不合时宜
• 社区在开发容器对象存储接口（COSI），使其成为 K8s 生态中的一阶成员

43. 项目 状态 星数 类型 说明
Prometheus 毕业 42.1K 监控 系统和服务监控系统，多维数据模型，PromQL查询，无存储依赖，时序数据…
Cortex 孵化 4.7K 监控 Prometheus 的可扩缩、高可用、多租户、持久化存储
OpenMetrics 孵化 1.7K 监控 为 Prometheus 的展示格式（Exposition Format）提供标准化
Thanos 孵化 10.3K 监控 对 Prometheus 的扩展，提供高可用的指标系统，存储容量不限
FONIO 沙箱 0.3K 安全 已更名为 ingraind，基于 RedBPF 构造的安全监控代理。
kuberhealthy 沙箱 1.4K 监控 集成监控，持续过程验证，自动为 Prometheus 生成度量指标
pixie 沙箱 3.2K 监控 集群、服务映射、资源、应用流量等高层概念检测，Pod状态、火焰图等支持
skooner 沙箱 0.9K 监控 Kubernetes Dashboard替代，监视集群、节点健康状况，提供实时图表
trickster 沙箱 1.7K 监控 HTTP 反向代理、缓存，提高时序数据的可视化面板渲染速度
fluentd 毕业 11.1K 日志 从多个数据源收集事件，将其写入文件、RDBMS、NoSQL、IaaS、Hadoop后端
OpenTelemetry 孵化 1.9K 监控
接收、处理和导出遥测数据，支持 Jaeger、Prometheus 数据格式；合并自
OpenTracing和 OpenCensus 两个项目，关注 API 和 SDK
Jaeger 毕业 15.6K 跟踪
分布式跟踪系统，来自 Uber。支持 OpenTracing标准。后端可用 Cassandra 和
ElasticSearch 等。
Cloud Custodian 沙箱 4.1K
自动
运维
管理公有云账号和资源的规则引擎，支持安全和成本管理。
CNCF 监控运维项目

44. 根据 CNCF 最近调研（2022/03/08）：
• Prometheus 占比 86%, OpenTelemetry 49%，Fluentd 46%，Jaeger 39%.
• 72% 的用户采用的工具少于 9 种，20%+ 的用户使用 10-15 种工具
• 64% 的用户选择自行安装自行维护，44% 使用公有云服务，40% 在本地安装且自行维护

46. 项目 状态 星数 类型 说明
Metal-3 沙箱 0.3K 裸机管理 通过 Operator 提供 BareMetalHost CRD，管理物理机。
tinkerbell 沙箱 0.6K 裸机管理 裸机部署服务，包括工作流、DHCP、元数据、BMC、命令行等。
KubeVirt 孵化 3.2K 虚拟机管理 通过 CRD 提供对 VM 资源的支持：启动、停止、删除等。
Knative 孵化 4.5K Serverless Kubernetes 原生 Serverless 容器支持：包含服务端、客户端、事件机制等。
OpenFunction 沙箱 0.6K Serverless 云原生的 FaaS 平台，包括转换、构建、服务、事件触发等能力。
virtual-kubelet 沙箱 3.4K Serverless
扩展 k8s 节点概念，接入 ACI、AWS Fargate、IoT Edge、Tensile Kube等。
主要目标是扩展对 Serverless 的支持。
severless-
workflow
沙箱 0.4K Severless
设计、运行基于 DSL 的工作流，针对 Serverless 场景。支持 Go、
Java、.NET、TypeScript、Python 语言。
krustlet 沙箱 2.8K WebAssembly 用基于 wasmtime 的运行时冒充 kubelet，支持 WebAssembly 负载。
WasmEdge 沙箱 3.0K WebAssembly WebAssembly 运行时，支持分布式的云原生、边缘应用。
wasmcloud 沙箱 0.5K WebAssembly 支持WebAssembly应用开发的平台，提供 actors 和 capability provider接口。
CNCF 中间件项目 -- 编排能力

47. CNCF 中间件项目 -- 应用管理
项目 状态 星数 类型 说明
KARMADA 沙箱 2.2K 多集群管理 跨多个 k8s 集群、云平台运行应用
KubeVela 沙箱 3.6K 多集群应用 基于 OAM 的抽象概念，提供与基础设施无关的、工作流驱动的应用管理。
OCM 沙箱 0.3K 多集群管理 RedHat 开源，基于 hub-agent 模型，管理多个集群（klusterlet）。
KEDA 孵化 4.5K 自动扩缩 事件驱动的自动扩缩服务组件，内建度量值服务。
Crossplane 孵化 5.1K 资源编排 声明式 API 编排任意资源，包括来自不同厂商的基础设施。现支持20家云厂商。
Volcano 孵化 2.3K 资源编排 批处理负载编排引擎，针对 ML/AI、大数据应用。
dapr 孵化 17.7K 微服务引擎
可移植、Serverless、事件驱动的运行时，用于构造云端、边端微服务。支持多
种语言或框架，内置事件处理、微服务状态管理能力。
OpenKruise 沙箱 3.1K 应用管理
CloneSet、Advanced StatefulSet、Advanced DaemonSet、BroadcastJob、
AdvancedCronJob、SidecarSet、WorkloadSpread、UnitedDeployment 等新
的资源类型。
fluid 沙箱 1.1K 大数据 针对 BigData/AI 应用的数据抽象与加速。
KubeDL 沙箱 0.3K 机器学习
支持训练和推理负载（TensorFlow、PyTorch、Mars等），自动调整容器配置，
版本化跟踪模型变更等。

48. 项目 状态 星数 类型 说明
cloudevents 孵化 3.4K 事件 描述事件数据格式的规范，在其上可支持AMQP、MQTT、NATS等诸多规范。
NATS 孵化 10.8K 消息流 平台中立的通信系统，目前支持40种客户端语言实现。
STRIMZI 沙箱 3.1K 消息流 支持在 K8s 上运行 Kafka 集群，安全性和易用性增强
Tremor 沙箱 0.6K 事件处理
实时事件处理引擎。原来设计替换 Logstash 或 Telegraf，后添加聚合、上卷、
ETL 和查询等能力。Rust 编写。
Pravega 沙箱 1.7K 流存储
用于流数据的分布式存储，主要关注性能、可持久性、弹性、一致性。Java编
写。
Brigade 沙箱 2.3K 事件处理 事件驱动的脚本平台，支持多种事件网关、事件源。
CNCF 流、事件处理项目

49. 现状：
• 云厂商提供了各式的中间件服务
• 客户业务与中间件绑定
• 客户的中间件还没有云原生化或者
说没有完全云原生化
发展中：
• 中间件云原生化，以operator的方
式运行在kubernetes平台上
• 以服务化的形式提供
• 开源已经提供了很多中间件的
operator，但是生产可用的不多，
如 vitness，CrunchyData
云原生化无法解决的问题：
• 应用依然和中间件绑定，应用开发者需要去维护中间件
• 云服务商提供的中间件导致客户迁移的时候增加风险和成本
云原生中间件

50. Dapr 是一个可移植的、事件驱动的运行
时，它使任何开发人员能够轻松构建出
弹性的、无状态和有状态的应用程序，
并可运行在云平台或边缘计算中，也支
持多种编程语言和开发框架。
Dapr的价值
• 应用与中间件解耦，不在与云服务商绑定
• 降低应用开发难度，提高应用开发效率
• 应用可以平滑迁移到任何云平台
定位：运行时
功能：为应用提供分布式能力简化开发
多语言：提供多语言 SDK
可移植：适合各种云场景
Any language, any framework, anywhere
Dapr 项目

51. 相同点
• 架构类似dapr亦使用sidecar的架构
• 功能有部分重叠
• 基于 mTLS 加密的服务间安全通信
• 服务到服务的度量指标收集
• 服务到服务分布式跟踪
• 故障重试恢复能力
区别
• Dapr 以开发人员为中心，提供了通过
名称进行服务发现和调用的方式，服务
网格则需处理网络概念，如 IP 和 DNS
地址
• Dapr 不提供路由或流量分配等关于流
量控制的功能
• 服务网格在网络级别运行，并跟踪服
务之间的网络调用
• Dapr 也可以通过服务调用来提供可观
察性 (跟踪和度量) ， Dapr 可以在 发
布/订阅 调用时，将相关的跟踪 Id 写入
CloudEvents 信封来达到此目的，在应
用程序中使用 Dapr 进行度量和跟踪比
使用“服务到服务调用”及“发布/订阅进
行通信”的服务网格更易扩展。
Dapr 与服务网格

52. 1. Dapr+Serverless
Dapr 一方面将开发和部署进行了解耦，让开发者和运维团队可以通过关注点分离简化系统复杂性；
一方面可以将短生命周期、无状态的 Serverless 应用逻辑，与数据库连接池管理这样的长期运行，
有状态的中间件访问能力进行解耦，提升了 Serverless 应用的可伸缩性和运行效率。
2. WebAssembly 和 Dapr 相结合，来实现可移植、强隔离、轻量化的微服务应用架构？
3. 应用与具体的中间件解耦合，使业务架构的可扩展性更好，开发更敏捷
前提和困难：API 标准化
Dapr 技术的趋势和价值

54. CNCF DevOps 项目
项目 状态 星数 类型 说明
Operator
Framework 孵化 5.6K Operator 基于 Go、Helm、Ansible 开发 Operator 的框架，与 kubebuilder 集成。
krator 沙箱 0.1K Operator Rust 状态机 Operator
kube-rs 沙箱 1.4K Operator Rust Operator 开发库，含客户端和控制器。
KUDO 沙箱 1.0K Operator Kubernetes Universal Declarative Operator. 声明式 YAML 构建 Operator。
CDK 沙箱 2.9K Operator 使用用户自选语言开发 k8s 应用的 SDK。
Argo 孵化 11K CI/CD 工作流引擎及 CD 引擎，声明式定义应用配置与环境，版本驱动的部署。
flux 孵化 6.8K GitOps 已升级至 flux2（3.2K），基于 GitOps 的 CD 解决方案。
flagger 孵化 3.6K CI/CD 渐进式交付，支持金丝雀、A/B 测试和蓝绿部署。
OpenGitOps 沙箱 0.2K GitOps 为 GitOps 提供厂商中立的、原则优先的定义，制定标准，支持互操作性。
keptn 沙箱 1.3K GitOps 事件驱动的应用生命周期编排，包括持续交付与自动运维。

55. 项目 状态 星数 类型 说明
buildpack 孵化 1.6K 开发工具 用来构造遵从 Platform Interface Spec 的云原生应用的 CLI.
backstage 孵化 16.3K 开发工具 用来构造开发者门户的开放平台，提供集中式的软件目录。
devfile 沙箱 0.1K 开发工具 云原生应用配置管理，Config as Code，提供仓库用于分享、发布。
Nocalhost 沙箱 1.2K 开发工具 开发环境 IDE 扩展，开发时立即生效。
Telepresence 沙箱 4.9K 开发工具 针对远程 k8s 或 OpenShift 集群的本地开发环境。
Porter 沙箱 3.2K 开发环境 基于 Helm 构建的 PaaS 环境，为 DevOps 提供支持。
ArtifactHUB 沙箱 0.8K 制品仓库 用来发现、安装和发布 k8s 软件包与配置的仓库。
Chaos Mesh 孵化 4.8K 混沌工程 混沌工程平台，提供 Operator 和仪表板，向应用和 k8s 插入噪声。
Litmus 孵化 2.7K 混沌工程 混沌工程平台，以云原生的方式实施混沌工程，主要针对 SRE 和开发人员。
ChaosBlade 沙箱 4.6K 混沌工程 阿里云开源的混沌实验注入工具。
Sealer 沙箱 1.4K 应用发布 阿里云开源的应用封装与发布工具
CNCF DevOps 项目

57. CNCF 边缘计算项目
项目 状态 星数 类型 说明
KubeEdge 孵化 4.9K 边缘平台 华为、阿里为主；支持云边网络、应用部署、元数据同步，支持MQTT。
Akri 沙箱 0.7K 资源接口 将异构的硬件暴露为 k8s 上的资源，支持基于此类硬件调度负载
OpenYurt 沙箱 1.2K 边缘编排 在不可靠网络环境下完成云边应用编排、设备管理、边缘节点自治等。
SuperEdge 沙箱 0.8K 边缘编排 跨多个边缘区域管理计算资源和容器应用，支持边缘自治、网络隧道
K3S 沙箱 19.8K 边缘平台 轻量级 k8s 发行版，所有可执行文件位于同一二进制中，< 100MB

59. CNCF 安全&合规项目
项目 状态 星数 类型 说明
Open Policy Agent
(OPA) 毕业 6.6K 策略引擎 基于声明式语言（Rego）编写与实施访问控制策略。
Keyverno 沙箱 2.3K 策略引擎 通过准入控制或后台扫描验证、修改、生成配置。以 CRD 方式呈现。
SPIFFE 孵化 1.0K 秘钥管理
分布式环境下的标识控制面，为负载管理改进的 X.509 证书，不再需要应用层
面身份认证或网络层面 ACL 配置。
SPIRE 孵化 1.1K 秘钥管理 SPIFFE 的参考实现，发放和刷新 SVID，管理秘钥和证书的轮换与负载加密。
Athenz 沙箱 0.7K 秘钥管理 X.509 证书身份验证和访问控制，可用于集中式和分布式架构。
cert-manager 沙箱 8.8K 秘钥管理 为 k8s 提供 TLS 证书生成和管理服务。
Teller 沙箱 0.9K Secret管理 主要针对命令行的 Secret 管理工具
Falco 孵化 4.8K 运行时安全
Sysdg 捐献，内核级别的事件监控，可与 Prometheus 及很多其他工具集成。
提供内核模块、eBPF 模块等多种安装方式。
kubearmor 沙箱 0.4K 运行时安全
支持多种 LSM（AppArmor、SELinux、BPF-LSM），提供KVMService以支持
虚拟机。
dex 沙箱 7.0K 身份认证 联邦式驱动，用于连接 OpenID 服务，完成身份认证。

60. CNCF 安全&合规项目
项目 状态 星数 类型 说明
TUF 毕业 1.3K 供应链安全 TUF 提供规范和 Python 参考实现，在软件更新过程中防范供应链攻击。
in-toto 孵化 0.5K 供应链安全 对供应链中各步骤执行鉴权和审计，基于 Python 实现。
notary 孵化 2.8K 供应链安全 客户/服务器架构方案，在服务器端发布签名的软件交付件。基于 TUF。
Inclavare 沙箱 0.5K 机密计算 云原生的机密计算运行时，容器化 TEE 实现。
PARSEC 沙箱 0.3K 机密计算 硬件安全（TPM、HSM）、加密服务的抽象 API。
keylime 沙箱 0.2K 可信计算 远程启动证明、运行时完整性度量。
Confidential
Containers
沙箱 30 可信计算 远程启动证明，部署机密容器运行时，Rust编写。
Curiefense 沙箱 0.4K WAF 网站、服务、API 层防护，包括 SQL、命令注入、XSS、ATO、DDoS 等。

61. • 技术的进步，网络环境变得更加
复杂，传统基于边界的安全防护
机制，如防火墙等，在云原生的
场景下很难面面俱到
• 云原生带来的开发和部署的敏捷
性使安全风险增大
• 需要更细力度的识别和保护工作
负载，满足云原生应应用快速扩
展、弹性伸缩的特性以及不断变
化的外界环境威胁
• 在应用安全生命周期中采用更自
动化和安全的架构设计（零信任）
• 在实施安全策略的过程中要在安
全与效率间取得平衡
云原生安全的背景

62. 开发
在应用程序生命周
期的早期引入安全
工具，通过安全测
试尽早识别合规问
题和错误配置等，
尽早发现安全问题
需要流程配合，通
过在研发流程中设
置安全闸，要求安
全问题在流入下一
环节前被处置解决
分发
软件生产周期流水线
中产生的工件（典型
如容器镜像），需要
进行持续的自动扫描
和更新来确保安全，
防止漏洞、恶意软件、
不安全的编码和其他
不安全的行为。在完
成这些检查后，更重
要的是对产品进行加
密签名，以确保产品
的完整性及不可抵赖
性
部署
在整个开发和集成发
布阶段，应对候选工
作负载的安全性进行
实时和持续的验证，
如，对签名的工件进
行校验，确保容器镜
像安全和运行时安全，
并可验证主机的适用
性。安全工作负载的
监控能力，应以可信
的方式监控日志和可
用指标，与工作负载
一同部署来完善整体
的安全性。
运行时
只有经过批准的进
程能在容器命名空
间内运行
禁止并报告未经授
权的资源访问
监控网络流量以检
测恶意的活动
将系统安全集成在整个生命周期中以及在运行时环境中，来实现针对未经授权访问的保护，
安全左移 、增强 DevOps，流水线的前、中、后各环节对所有组件进行持续、适当的检查。
云原生安全实施的几个阶段

63. 开发/分发/部署的安全流程

64. 计算
• 只读操作系统（容器操作系统）
• 可信平台模块（TPM）或
vTPM 作为硬件信任的基础
• 安全容器
• 编排系统
• 运行时检测
访问
身份和访问管理
凭据管理
网络
• 拒绝服务 (DoS) 和
分布式拒绝服务
(DDoS)
• 非法访问
• 基于身份和标签
的网络访问
存储
存储栈(编排，缓存，数据服
务)
存储加密
持久卷保护
组件仓库
运行时安全

65. 运行时
Falco
KubeArmor
网络
Cilium
ServiceMesh
镜像扫描
Trivy
编排
OPA (Gatekeeper)
Kyverno（策略引擎）
CIS 安全基线
基本想法
• k8s 发行版基本要具备通过 CIS 安全基线的能力，引入策略引擎方便配置管理
• Cilium+KubeArmor 实现运行时和网络的安全能力
• 引入零信任的概念，实现安全的动态评估跟 Cilium 或 KubeArmor 实现联动
• 镜像扫描提供规则即可
现阶段需要关注的容器安全部分

67. 容器化究竟给我们带来了什么？
• 容器化本质
• 利用操作系统级虚拟化，构造弱隔离环境，（与虚拟化相比）提高资源利用率
• 通过镜像打包方式，实现应用依赖自包含，
• “一次构造、随处运行”：对应于“静态链接的可执行文件”
• 增量式迭代，持续集成与部署（CI/CD），乃至 DevOps、GitOps
• 启动速度快
• 适合构造快速扩缩的服务
• 对于厂商
• 需要管理的实体在物理机、虚拟机之外，多了容器
• 和虚拟机一样，容器需要编排，目前事实标准是 Kubernetes
• 放牛式负载管理，工业化流水线思路，主要支持无状态服务
• 声明式 API，通过后台控制器用不透明（不可控）的方式完成状态趋近和收敛
• 只负责容器实体编排（core），周边组件全开放可扩展（杂草丛生）
• 自动扩缩仍然很复杂，要形成高效回路
• 对于最终用户

68. • 软件发布周期
• Daily
• Weekly
• Monthly
• Quarterly
• Ad Hoc
CNCF 的被调查群体：80%至少
每个月发布一个新版本。

69. 参考
• LWKD（Last Week in Kubernetes Development）
• https://buttondown.email/LastWeekInKubernetes